Re: [tor-talk] Tentative results of analysis of data on metrics.torproject.org

[krishna e bera <keb@xxxxxxxxxxxxxx>]

On 14-09-03 10:25 PM, Roger Dingledine wrote:
> On Wed, Sep 03, 2014 at 04:10:13PM -0700, Virgil Griffith wrote:
>> https://docs.google.com/document/d/1SaBK664SchhZOP9XBsB8KK63k4xlmMTlkhfF28f2204/pub
> [...]
> - Figure 3 is a bit weird. Our bandwidth-per-relay stat is a function of
> how many total relays we have, but not really a function of the growth
> in total relays. So if for example we added a bunch of fast relays,
> but we also added even more slow relays, then this graph would show
> that bandwidth-per-relay isn't growing. So I guess the question is:
> what conclusions should we draw from Figure 3? If it levels off or goes
> down in the future, does that indicate a bad thing in any way?
> 
> Or said a different way, maybe we should be graphing the mean bandwidth
> of the fastest k relays in the network? That's sort of what we had in
> mind with
> https://metrics.torproject.org/bandwidth.html#advbwdist-relay
> and it better shows the growth in capacity of the network, in a way
> that wouldn't be dragged down by adding a whole bunch of fast relays
> (which people use) but also adding a whole bunch of slow ones (which
> people don't use).

What about using the mean bandwidth of relays flagged as "Fast"?
Or are these metrics analyses used to establish the "Fast-speed"
threshold value itself, as defined in the Tor directory spec?


> Which leads to: we want something that takes into account Tor's
> "clients choose relays proportional to their bandwidth" load balancing.
> From your transition text between Figure 3 and Figure 4 it looks
> like you're trying to use bandwidth-per-relay as a stand-in for
> expected-bandwidth-for-the-client, which I think it isn't because clients
> don't select relays uniformly.

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk