-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi devs,
I was reminded by Harmony that I said a while back [0] that I would announce new Onionoo versions on this list and not only in private message to Harmony for including them in the next TWN issue. Oops.
So, version 2.4 added a new "effective_family" field to details documents, listing all the relays with which the relay in question is in an effective, mutual family relationship. The main goal here is to make it easier to detect misconfigured relay families. This can be relay operators or friendly people watching over the Tor network and reminding relay operators to fix their configurations. [1]
The new version 2.5 that I deployed this week adds the optional "measured" field to details documents. The main idea behind this new field is that relay operators and Tor network debuggers can now figure out easily whether a relay is affected by not being measured by a sufficient number of bandwidth authorities and as a result has lower usage than it could handle. This field is not yet displayed by the Onionoo clients Atlas or Globe, but it's accessible via Onionoo's API [2]. More details are on ticket #16020 [3].
All the best, Karsten
[0] onionoo-announce@ posting from April 27, 2015
[1] https://lists.torproject.org/pipermail/tor-news/2015-August/000109.html
[2] https://onionoo.torproject.org/protocol.html#details
[3] https://trac.torproject.org/projects/tor/ticket/16020
On Wed, Aug 19, 2015 at 02:27:10PM +0200, Karsten Loesing wrote:
The new version 2.5 that I deployed this week adds the optional "measured" field to details documents. The main idea behind this new field is that relay operators and Tor network debuggers can now figure out easily whether a relay is affected by not being measured by a sufficient number of bandwidth authorities and as a result has lower usage than it could handle. This field is not yet displayed by the Onionoo clients Atlas or Globe, but it's accessible via Onionoo's API [2]. More details are on ticket #16020 [3].
Onionoo is great. Here are a couple of graphs that have to do with the "Measured" flag.
The first one is a CDF of consensus weight (which maps to e.g. the probability of using a relay in a circuit). Check out the big rise at a consensus weight of 20. That's caused by the default bandwidth setting of 20 KB/s when a relay is unmeasured: https://gitweb.torproject.org/tor.git/tree/src/or/dirvote.h?id=tor-0.2.6.10#... /** Default bandwidth to clip unmeasured bandwidths to using method >= * MIN_METHOD_TO_CLIP_UNMEASURED_BW. (This is not a consensus method; do not * get confused with the above macros.) */ #define DEFAULT_MAX_UNMEASURED_BW_KB 20
The second graph shows the age of all currently running relays (first seen date) with the consensus weight. The unmeasured relays are colored differently. See how they all fall on the 20 KB/s line.
Hi,
was there a specific reason for reverting the tpo instance back to version 2.3? (since 2015-09-27 07:00)
thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 27/09/15 14:45, nusenu wrote:
Hi,
was there a specific reason for reverting the tpo instance back to version 2.3? (since 2015-09-27 07:00)
Oops, that's by mistake. The host was restarted and still had 2.3 written in its crontab @reboot line. I just changed that to 2.6. It might be that some documents will miss the new fields added after 2.3, but I hope that will resolve itself over the next days. If you're observing any problems with this, please let me know and I'll take a look.
thanks!
Thanks for the report!
All the best, Karsten
-
David Fifield -
Karsten Loesing -
nusenu