#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): Neat stuff. I haven't looked into all the data, but here are some first- thought theories, to make sure you've considered them: (1) When you're establishing the first hop of the circuit, you might need to establish a TCP connection and ORConn with the first relay. That process is a lot of extra round-trips -- first to do TCP, then to do TLS, then to do Tor's v3 handshake with netinfo cells and so on. In fact, you might even see the bimodal distributions that Dennis points out, where a few circuits build quickly because there's already an underlying ORConn in place, and most of them build slowly because you need to set up the ORConn too. 100ms latency to the guard, amplified by n round-trips, could make a real difference. That's part of why we build preemptive circuits, because it means building preemptive ORConns too. (2) Guards might be overloaded with CREATE cells, causing them to respond more slowly to circuit create attempts than other relays do. This overload might happen because they have a higher consensus weight than other relays (which is what helped get them the Guard flag), and thus attract more users. (2a) Alternatively, another difference for guards is that they have to handle many more TLS handshakes because they get direct connections from clients. We've somewhat-recently changed the parameters for when we expire these TLS conns (#17592, 0.3.1.1-alpha, prop#251). Maybe these more frequent TLS conns are using enough of their CPU that they are worse at handling CREATE cells. In theory the CREATE cells are handled in worker threads though, so there shouldn't be direct competition. But maybe they're not tuned well, so the worker threads don't keep up well when the main thread is distracted. I don't think (2) or (2a) look like good explanations though, because they should be happening to the dutch onionperf too. But (1) looks plausible. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34257#comment:14> 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