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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
