#33947: Compare sbws and Torflow
---------------------------------------------+-----------------------------
Reporter: juga | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: sbws:
| 1.1.x-final
Component: Core Tor/sbws | Version: sbws: 1.1.0
Severity: Normal | Resolution:
Keywords: sbws-roadmap, GeorgKoppen202005 | Actual Points:
Parent ID: #33121 | Points:
Reviewer: | Sponsor:
---------------------------------------------+-----------------------------
Comment (by juga):
Following the previous reasoning and data, i implemented other function to
find over/under-weighted relays.
I created a modified version of the previous function.
I attach a new csv file and comment in this ticket due to repeated data
and comments.
This is what i found:
Overweighted relays (#33350)
----------------------------
- maatuska was still overweighting 346 relays while sbws ony 3
- the 3 sbws cases are due to mising the descriptor average bandwidth
- all the maatuska cases are missing descriptor observed bandwidth except
for one relay that have higher conensus and observed bandwidth than
longclaw, probably cause the stored descriptor was old
Reasons why i think this happend:
- maatuska version was not updating correctly descriptors (#30733, #33570)
what was making skip scaling for many relays that were still included in
the bandwidth file to vote (#33832, this would be solved by a commit in
#33832)
- rounding before limiting to the maximum was probably a problem too
(would be solved by a commit in #33832 too)
- these errors were accumulating until we got more torflows cause final
bandwidth depends on the previous consensus bandwidth
Underweighted relays (#33775)
-----------------------------
https://trac.torproject.org/projects/tor/ticket/33775
- maatuska was still underweighting 70 relays while longclaw none
- it seems that the consensus bandwidth maatuska has for those relays is
lower than sbws
Reasons:
- maybe cause using exits with low capacity (#33009)
- again not updating often/correctly descriptors and keeping previous low
values
- and making them accumulate
Regarding the total consenus weight, it can be seen here now all bwauths
are close: https://metrics.torproject.org/totalcw.png?start=2019-12-18
There is no code to review but someone should check whether my reasoning
makes sense ;)
From the list of things to check in this ticket, it would be still missing
#33198
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33947#comment:3>
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
