[tor-bugs] #16020 [Onionoo]: new field: measured flag

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jul 7 13:01:57 UTC 2015


#16020: new field: measured flag
-----------------------------+-----------------
     Reporter:  cypherpunks  |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------

Comment (by leeroy):

 Karsten, implementing last_measured is actually trivial. Onionoo already
 parses consensus so the time for parsing is already used. Unmeasured is
 just another piece of data in the weight line so last_measured is based on
 the last time it was missing. It's trivial because it only requires
 comparing the timestamp stored (and can be done without string comparison
 using a hash if needed). It's up to you if it should be implemented
 though.

 A node can have consensus weight without being measured. In which case I
 don't see how this could possibly help for debugging. Either the BWAuth's
 are experiencing a known problem (and the problem is easy to identify), or
 not (and the field does nothing to help). On the other hand an operator
 can use the weights history document to see changes in bandwidth weight
 (besides other goodness) in hourly intervals.

 It's only if they're new, or reset, and expect a BWAuth scan, to have a
 problem in obtaining consensus weight. It's also not a future guarantee to
 be able to get per BWAuth data. Consensus is computed on meeting the
 threshold number of measurements. From BWAuth tickets dedicated BWAuths
 scan certain percentiles. '''So measurements may be the same BWAuth, not
 unique.''' In this case you would be parsing votes just to get the
 different view of bandwidth, from the same BWAuth, at different DirAuth.

 But if you're still determined to do this I would propose an optimization.
 Only parse the current vote, don't parse archives. As a comparison,
 parsing current consensus takes ~880ms while parsing current votes takes
 11s.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16020#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list