Opened 2 months ago

Last modified 8 weeks ago

#28447 new defect

improve new SBWS rounding to exhibit uniform percent deltas

Reported by: starlight Owned by:
Priority: Medium Milestone: sbws: unspecified
Component: Core Tor/sbws Version: sbws: 1.0.0
Severity: Normal Keywords:
Cc: pastly, juga Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


In ticket #27337 bandwidth vote rounding was changed from Torflow's three significant decimal digits to two places in order to reduce inconsequential consensus diff updates. The change is a good one except that the resulting distribution of values exhibits large unevenness of relative value changes, an effect which with was much smaller with three digit rounding. To obtain the same benefit with an uniform change distribution, rounding constructed on a natural log scale should be applied. For example instead of

100000 -> 110000 +10.0%
 40000 ->  41000  +2.5%

the proper way to accomplish this is to round by taking the natural log of the value, round that to the nearest 1/20th for uniform 5% steps and then raise e by the result:

100000 rounds to  98716
105000 rounds to 103777
98716 -> 103777 +5.1%

40000 rounds to 40135
42000 rounds to 42193
40135 -> 42193 +5.1%

1100 rounds to 1096
1050 rounds to 1043
1043 -> 1096 +5.1%

The overall goal of SBWS is improved consensus construction and while the importance of this refinement can be debated, it is clearly beneficial, is easy to implement and therefore a reasonable adjustment at this early stage of testing deployment.

Child Tickets

Change History (8)

comment:1 Changed 2 months ago by teor

Version: sbws: unspecifiedsbws: 1.0.0

I'm not convinced that tor relay bandwidths need the smooth steps you're asking for:

We will probably end up implementing proposal 276 (#27689), which will smooth the steps to approximately the level you're asking for, but in a way that is more compressible:

comment:2 Changed 2 months ago by teor

In sbws 1.0, our priority is to match torflow, rather than making significant changes to the bandwidth measurement system.

So it is also possible that we won't implement any smoothing in sbws 1.0. Instead, we'll fix the rounding so it actually rounds 3 significant figures, which will match torflow (#28442).

comment:3 Changed 2 months ago by starlight

The idea is a simple, elegant refinement. I sense a bit of "not invented here" reactivness. Motive is apply an obvious and straightforward enhancement without overthinking, such that future improvements in other areas of the system are enabled rather than degraded. No significant difference in the degree to which log scale values will compress--each increment is distinct, singular and repeated. While some may find trailing zeros in decimal numbers aesthetically pleasing, log scale increments do not lack for appeal.

Holding off on making changes to rounding until the new scanner is fully deployed is reasonable enough.

comment:4 Changed 2 months ago by teor

Milestone: sbws 1.1

comment:5 Changed 8 weeks ago by teor

Milestone: sbws 1.1sbws 1.2

Milestone renamed

comment:6 Changed 8 weeks ago by teor

Milestone: sbws 1.2sbws: 1.2.x

Milestone renamed

comment:7 Changed 8 weeks ago by teor

Milestone: sbws: 1.2.xsbws: 1.2.x-final

Milestone renamed

comment:8 Changed 8 weeks ago by teor

Milestone: sbws: 1.2.x-finalsbws: unspecified

Milestone renamed

Note: See TracTickets for help on using tickets.