[tor-bugs] #27337 [Core Tor/sbws]: Round relay bandwidths in bandwidth files
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Aug 27 13:44:00 UTC 2018
#27337: Round relay bandwidths in bandwidth files
---------------------------+-------------------------------------
Reporter: teor | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: sbws 1.0 (MVP must)
Component: Core Tor/sbws | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: #27108 | Points:
Reviewer: | Sponsor:
---------------------------+-------------------------------------
Comment (by juga):
Replying to [ticket:27337 teor]:
> Torflow rounds raw bandwidths to 3 significant figures, and increases 0
bandwidths to 1:
>
>
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n62
ah, i've being wondering why that
> === Rounding ===
>
> sbws must round to 3 (or fewer) significant figures, so that consensus
diffs are still efficient.
>
> I suggest 2 significant figures, because the largest error is 5% at
1.5*10^n^ (for example: (105-100)/100 = 5%).
ok, will implement this
> Bandwidth authorities already vary from each other by 25-50%:
> https://trac.torproject.org/projects/tor/ticket/25459#comment:5
>
> And network load varies each day (from what I remember, my guards and
exits used to vary by at least 10% every day).
>
> === Avoiding Zeroes ===
>
> I think sbws should also increase 0 bandwidths to 1.
hmm, which one of the bandwidth values?. So far the we round all decimal
values and take max(value, 1). The only bandwidth that can still be 0 is
the descriptor observed bandwidth, that's it's also rounded and take min 1
after it's multiplied by the ratio. Should the descriptor observed
bandwidth be at least 1 before multiplying by the ratio?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27337#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list