[metrics-bugs] #34257 [Metrics/Onionperf]: Analyze unusual distribution of time to extend to first hop in circuit

[Tor Bug Tracker & Wiki]

#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 karsten):

 Agreed, arma and dennis.jackson. What we're seeing here is the delay for
 establishing the OR connection. Here's a graph of time to extend to first
 hop in circuit as a function of whether the OR connection was already
 connected at the time of launching the circuit:

 [[Image(onionperf-circuit-extend-2020-06-01.png​, 700px)]]

 The blue and red lines look way different for all OnionPerf instances.

 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. When the consensus
 finally made it through the control port, all queued events arrive in
 short succession, and we note down the same timestamp for all of them. We
 need to keep this in mind when we rely on event timestamps in the future.
 There's a difference between (a) Tor formatting and sending an event, (b)
 Stem receiving and parsing it, and (c) OnionPerf logging it to disk.

 So, what do we do after learning this? Should we work harder on tickets
 like #33399 to avoid setting `UseEntryGuards 0` and to get more realistic
 measurements in the future?

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