#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
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
