#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]: > 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? You could pretty easily have your Tor client keep an ORConn open, by leaving an unused circuit on it (e.g. put it in purpose 'controller' on the client side, unless you're using that special purpose in onionperf already). Then subsequent circuit builds on the circuit will reuse that already open conn. You'd want to have a way to recognize when circuits were requested where the ORConn had to be (re)built (e.g. because it's the first circuit or because something happened to the old ORConn), so you can annotate results from those circuits differently. But that would be one way to leave UseEntryGuards at 0 while getting mostly circuits that didn't need to wait for a new ORConn. That leads to another performance research question for the onionperf folks. Because ORConns are backbone long-lived TCP connections, their throughput takes a while to ramp back up (in terms of TCP windows, slow start, etc) if they haven't sent traffic lately. Are ORConns for an "active" Tor client, using their guard at this moment, better off because the ORConn is already "warm"? Or does this factor not matter much compared to other issues like network latency, the tiny amount of bandwidth needed for circuit building, etc? And this reminds me of a different issue I was thinking about, based on the above graphs. Sometimes two relays won't have an existing ORConn connection between them, and so establishing a circuit between the two will take longer than it would otherwise. So I would expect a much more subtle bimodal distribution for the second hop and the third hop as well, where every so often it takes a lot longer than it should, because those relays need to reconnect to each other. But on the plus side, *this* difference is one that real-world Tor clients will experience too, in the same way as onionperf. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34257#comment:20> 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