#34303: Find out why onion service measurements have gotten slower -------------------------------+-------------------------------- Reporter: karsten | Owner: karsten Type: defect | Status: accepted Priority: Medium | Milestone: Component: Metrics/Onionperf | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: Sponsor59-must -------------------------------+-------------------------------- Changes (by karsten):
* owner: metrics-team => karsten * status: new => accepted Comment: Okay, I think I know what the issue is: Tor stopped cannibalizing circuits which do not have a current guard as their first hop in 0.3.3.2-alpha (#24469). While this seems useful in the common case, it affects us badly, because we're setting `"UseEntryGuards 0"` to avoid using guards at all. Here are the latest measurement results with various Tor versions to narrow down the issue: [[Image(onionperf-2020-05-28.png, 700px)]] Some observations: - There are two classes of measurement results here which we can distinguish very clearly at the median. Things get less clear towards the worst-case measurements, but that's likely due to the small number of measurements. - Versions until 0.3.3.1-alpha (brown line) fall into the "fast" class, versions starting at 0.3.3.2-alpha (dark gray) fall into the "slow" class. - Version 0.4.4.0-alpha-dev (cyan) is current master with the patch below to undo the #24469 change. It falls into the "fast" class. While it looks like it's the fastest of all measurements, I doubt that it's any different from the other "fast" measurements in the worst case. Here's the patch to current master that I used for measurements: {{{ diff --git a/src/core/or/circuitlist.c b/src/core/or/circuitlist.c index 4c37ef8b41..35057c5176 100644 --- a/src/core/or/circuitlist.c +++ b/src/core/or/circuitlist.c @@ -1946,7 +1946,8 @@ circuit_find_to_cannibalize(uint8_t purpose_to_produce, extend_info_t *info, * that the Guard was removed from the samepled set after the circuit * was created so avoid using it. */ if (!entry_guard_could_succeed(circ->guard_state)) { - goto next; + /* Commented out this bugfix of #24469 to work around bug #34303. + goto next*/; } if ((!need_uptime || circ->build_state->need_uptime) && }}} It would be nice to get this analysis confirmed by a network team person. If this is indeed the issue, I think we'll need to change Tor to only apply this check if `"UseEntryGuards 1"` is set. This doesn't only affect us, it also affects other users who run Tor without guards for whatever reasons. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34303#comment:15> 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