unintended consequence of geographically distributed bandwidth servers: higher vote instability
The manner in which ticket legacy/trac#24674 (moved) was implemented has caused Torflow voting to become increasing unstable.
IIUC Torflow switches from one configured bandwidth server to the next in succession, but does not maintain separate sets of measurement data for each server. Thus if a scan is performed against a server in fast region such as central Europe and next in a slow region such as South America, new slow measurements are compared against the fast average bandwidth established in the preceding cycle, and vice-versa.
The moria1 scanner appears to recently have commenced operating with multiple servers configured while the maatuska scanner remains configured with one server. A recent synchronous pair of scan results from the two illustrates this problem and is attached. Moria1 results show much higher variance in pid_delta values than maatuska results: sorted by slice from highest down
moria1 pid_delta variances:
scanner1: 2.35 2.32 1.01 1.32 0.65 0.79 0.76 0.51 1.12 0.43 scanner2: 0.97 0.94
maatuska pid_delta variances:
scanner1: 0.31 0.42 0.41 0.41 0.26 0.27 0.38 0.49 0.28 0.36 0.34 scanner2: 0.42 0.36 0.46
At a minimum SBWS should address this issue by segregating measurment data by scanner.
For the present my opinion is that Torflow configurations should be reverted to one-server-per scanner to reduce vote instability and restore it to what it was before ticket legacy/trac#24674 (moved) was implemented.