Monitor dirauth running sbws in production
We will start running sbws in dirauths. We commented that we will do it one by one. As teor commented, we should monitor network performance and consensus weight. This ticket is intended to track any issues.
Activity
changed milestone to %sbws: 1.1.x-final
To check that the bandwidth measurements do not get worst:
- Total bandwidth should not be smaller: https://metrics.torproject.org/bandwidth.html
- Time to download files should not be bigger: https://metrics.torproject.org/torperf.html
- Total consensus weights across bwauths: https://metrics.torproject.org/totalcw.html
Edit: add total consensus weights
-
- First vote using sbws data: https://collector.torproject.org/recent/relay-descriptors/votes/2018-11-02-10-00-00-vote-23D15D965BC35114467363C165C4F724B64B4F66-435B8FD5C4666E08DFD63946334687AB2297F3D8
- First consensus using sbws data: https://collector.torproject.org/recent/relay-descriptors/consensuses/2018-11-02-10-00-00-consensus
-
Current number of relays measured by each bwauth: https://consensus-health.torproject.org/#bwauthstatus
Tom, will you add longclaw to the bwauth graphs? (so we can see if longclaw's measured relays count remains the lowest or increases over time) https://consensus-health.torproject.org/graphs.html#bwauthgraphs
-
I created #28355 (moved) for the notification about longclaw measuring less relays.
-
In "BWAuth Measured Relays, Past 14 Days" https://consensus-health.torproject.org/graphs.html#bwauthgraphs, longclaw started going down because of it didn't have raw measurements for the 5th and the 6th. It should go up again in some hours.
Edit: typo
longclaw BW scanner started printed broken vote sets with under 1700 relays as of the time of this entry
https://lists.torproject.org/pipermail/tor-consensus-health/2018-November/009378.html
-
After several days, most of the circuits timeout. Opened #28639 (moved) for this.
