[metrics-team] non-stacked exit and guard capacity graphs

Karsten Loesing karsten at torproject.org
Tue Jan 7 15:56:44 UTC 2020


On 2020-01-05 03:45, nusenu wrote:
> Hi,

Hi nusenu!

> would it be possible to add non-stacked graph versions of
> this graph:
> https://metrics.torproject.org/bandwidth-flags.html
> 
> one graph per:
> - all exit capacity
> - all guard-only capacity
> - neither guard nor exit
> 
> That would help make it easier to see their capacity over time.

Maybe.

Let's do an experiment. Tell me one or two time frames for which you
believe that non-stacked graphs would work better than stacked ones, and
I'll make these graphs manually. Then we decide together whether it's
worth adding these graphs or graph parameters. I actually don't know the
answer myself, and I'm curious myself!

> thanks for considering it!
> nusenu

Note that my main concern about adding more graphs or graph parameters
is not coding effort. It's about usability. If we make graphs more
configurable, we'll have to make sure that people actually understand
these configuration options. And if we simply add more graphs with the
same data in a different form we make it harder for users to find the
graphs that we think matter most.

Also note that the main audience of these graphs are people who cannot
make their own graphs, which I believe doesn't include you. If your main
reason for making this feature request is having a better graph for
yourself and for "debugging" the network, I'd rather help you write an R
script that you can run locally. Of course, if we conclude that having
these new graphs or graph parameter would be beneficial for other users,
let's consider making these changes for everyone. But let's do the
experiment first!

All the best,
Karsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20200107/884bdab3/attachment.sig>


More information about the metrics-team mailing list