#30733: SBWS is using max advertised bandwidth from 5 day old descriptors -----------------------------------+----------------------------------- Reporter: starlight | Owner: (none) Type: defect | Status: new Priority: Very High | Milestone: sbws: 1.1.x-final Component: Core Tor/sbws | Version: sbws: 1.1.0 Severity: Critical | Resolution: Keywords: sbws-majority-blocker | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: -----------------------------------+----------------------------------- Changes (by teor):
* severity: Normal => Critical * priority: Medium => Very High * milestone: => sbws: 1.1.x-final * keywords: => sbws-majority-blocker Old description: > See attached files. Relay powerlay lowered max advertised bandwidth late > 5/23. SBWS longclaw never recognized the change. SBWS bastet saw the > value but was started after the change. Torflow recognized the change > instantly. > > Have observed that SBWS, when it makes note of max advertised bandwidth, > averages the value. This value should not be averaged, the current value > whatever it is apples. New description: See attached files. Relay powerlay lowered max advertised bandwidth late 5/23. SBWS longclaw ~~never recognized the change~~ only recognised the change after 5 days. SBWS bastet saw the value but was started after the change. Torflow recognized the change instantly. ~~ Have observed that SBWS, when it makes note of max advertised bandwidth, averages the value. This value should not be averaged, the current value whatever it is apples. ~~ -- Comment: Hi, when you log bugs like this, please show us: * the full torflow and sbws bandwidth file lines, * the exact lines that show the bug, and * the relevant values in your torrc. Explain these bugs like we don't know what you're talking about. If you don't provide good explanations, we don't know how serious the bug is. So we leave it for days or weeks until we have time to look at the details. Here's a detailed explanation for this bug: The MaxAdvertisedBandwidth was changed around 2019-05-23 00:30? to a lower value. longclaw is running sbws. It shows no bandwidth change on 05-23, but does show a bandwidth change on 05-28, 5 days after the change. (sbws results expire after 5 days.) {{{ bw=56000 desc_bw_avg=1073741824 time=2019-05-22T18:46:34 bw=62000 desc_bw_avg=1073741824 time=2019-05-24T00:58:14 }}} {{{ bw=62000 desc_bw_avg=1073741824 time=2019-05-27T20:17:40 bw=47000 desc_bw_avg=1073741824 time=2019-05-29T02:18:34 }}} bastet and maatuska were running torflow. They change immediately, or after a few hours: bastet: {{{ bw=131000 updated_at=2019-05-23T00:42:57 pid_bw=86361445 bw=38300 updated_at=2019-05-23T17:05:28 pid_bw=86361445 }}} maatuska: {{{ bw=98300 updated_at=2019-05-21T02:33:18 pid_bw=91584752 bw=76700 updated_at=2019-05-23T06:07:45 pid_bw=91584752 Or possibly bw=79000 updated_at=2019-05-23T06:07:45 pid_bw=91584752 bw=65900 updated_at=2019-05-25T00:35:22 pid_bw=91584752 }}} bastet then switched to sbws, which appears to have picked up the MaxAdvertisedBandwidth value straight away: {{{ bw=48700 updated_at=2019-05-25T09:47:17 pid_bw=86361445 bw=58000 desc_bw_avg=36700160 time=2019-05-27T23:51:27 }}} This bug blocks deployment of sbws to more than half the bandwidth authorities. We might be able to diagnose this bug better when we know the answers to these questions: * What was the MaxAdvertisedBandwidth value before and after the change? * What was the exact time of the change? * Do torflow and sbws report times in UTC? * What are the full sbws bandwidth file lines around the time of the change, and 5 days after the change? * Do we need to add more diagnostics to sbws relay lines? -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30733#comment:4> 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