On Wed, Jan 22, 2014 at 01:02:29PM -0500, starlight.2014q1@binnacle.cx wrote:
Also keep in mind that what the bandwidth authorities actually measure is not total capacity but spare stream capacity (by downloading large files through at least 5 different two hop circuits times for each relay).
Wait... So if I understand this correctly the bandwidth number is the difference between the actual bandwidth of the node and the actively utilized bandwidth?
No. The bandwidth number is how much attention clients should give the relay. That is, it's a weighting that clients use when selecting relays, and they select a given relay proportional to its bandwidth weight.
I looked high-and-low for a proper definition of the value
This is where the consensus weight is described: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1634
The consensus weight is computed using a) the relay's self-advertised bandwidth in its descriptor: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l389 b) the ratios of bandwidth weights for various types of relays: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2137 and c) the result of the active measurements from the bandwidth authorities: https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAutho... https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAutho...
However I must complain that the consensus bandwidth does not say much about the relative health of a relay. Does a good (ungamable) way exist to show the bandwidth capacity of relays along with the available capacity?
Ungameable is a much harder requirement. See e.g. http://freehaven.net/anonbib/#eigenspeed but Eigenspeed does not do well at assessing the speed of fast relays, since it's hard to design a system where relays can accurately assess the speed of faster relays.
--Roger