#34257: Analyze unusual distribution of time to extend to first hop in circuit
 Reporter:  karsten            |          Owner:  metrics-team
     Type:  defect             |         Status:  new
 Priority:  Medium             |      Milestone:
Component:  Metrics/Onionperf  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:                     |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:  Sponsor59-must

Comment (by arma):

 Replying to [comment:17 karsten]:
 > One minor remark on the red lines in op-ab-2020-04-26 and op-
 hk-2020-04-05: It looks like the fastest 5% of first circuit hops are
 build almost instanteously, despite not having an OR connection around.
 This is an artefact of how we're logging events. What happens here is that
 the Tor client just received a new consensus that it shares with us in
 full via the control port. However, that takes some time, and all
 subsequent events are queued behind the consensus.

 Is the timing matters that much here, I wonder if it would be good to have
 two controller connections, each listening for different events? If the
 time-critical ones are small, hearing them on their own control channel
 might be helpful. I'll grant that it is more moving pieces though, so
 might not be worth the added complexity.

 Another option is that Tor should put timestamps in the events where you
 care about high-resolution timing.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34257#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
tor-bugs mailing list

Reply via email to