Anyone know what caused bastet's loss of grip on reality?
600 IPredator 440 xenoidRelay 300 PrivacyRepublic0001 270 ExitNinja 260 DipulseIT2 240 hyacinthinus 230 PIAzrhexit 230 Unnamed 220 volatile 210 Chenjesu 210 drazisil 210 exit3 210 radieschen 200 Spigen 200 TotorBE2 200 tagos
On 9 Mar 2019, at 13:36, starlight.2018q2@binnacle.cx wrote:
Anyone know what caused bastet's loss of grip on reality?
600 IPredator 440 xenoidRelay 300 PrivacyRepublic0001 270 ExitNinja 260 DipulseIT2 240 hyacinthinus 230 PIAzrhexit 230 Unnamed 220 volatile 210 Chenjesu 210 drazisil 210 exit3 210 radieschen 200 Spigen 200 TotorBE2 200 tagos
It's probably a bug in the scaling in the dev version of sbws, or the machine that sbws is running on is very slow:
bandwidth-file-headers timestamp=1552095292 version=1.2.0 destinations_countries=HK,ZZ,US earliest_bandwidth=2019-03-04T01:35:26 file_created=2019-03-09T01:35:03 generator_started=2019-03-09T00:00:59 latest_bandwidth=2019-03-09T01:34:52 minimum_number_eligible_relays=3970 minimum_percent_eligible_relays=60 number_consensus_relays=6616 number_eligible_relays=6247 percent_eligible_relays=94 scanner_country=US software=sbws software_version=1.0.3-dev0
http://204.13.164.118/tor/status-vote/current/authority
No need to stress. Medians are designed to ignore outlying values like this. We'll get it fixed soon.
T
Hi,
On 9 Mar 2019, at 14:04, teor teor@riseup.net wrote:
It's probably a bug in the scaling in the dev version of sbws
It is a kilobyte-to-byte scaling bug: https://trac.torproject.org/projects/tor/ticket/29707
No need to stress. Medians are designed to ignore outlying values like this. We'll get it fixed soon.
If you scroll down these graphs, you can see that bastet is below the median for almost all relays: https://consensus-health.torproject.org/graphs.html#bwauthgraphs
The change is too recent to be in the metrics graphs: https://metrics.torproject.org/totalcw.html
T
tor-relays@lists.torproject.org