Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8145 closed defect (implemented)

Need minimum bandwidths for Fast threshold

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Somebody has signed up a few hundred relays on Amazon with bandwidths of 1. This has driven moria1 to say:
Feb 04 00:50:02.020 [info] Cutoffs: For Stable, 404881 sec uptime, 242577 sec MTBF. For Fast: 1 bytes/sec. For Guard: WFU 95.962%, time-known 110475 sec, and bandwidth 71680 or 58291 bytes/sec. We have enough stability data.

There should be some threshold for Fast below which we just don't give the Fast flag. Same with Guard probably?

Child Tickets

Change History (6)

comment:1 in reply to:  description Changed 7 years ago by nickm

Status: newneeds_review

This is already something the authorities could tweak with the FastFlagMinThreshold networkstatus parameter.

My "bug8146_etc" branch has a patch in 317d16de04ef9f2fa827b3bea2d858069a721e24 which raises the minimum minimum value there from 0 to 4096, chosen more or less arbitrarily. :/

comment:2 Changed 7 years ago by nickm

61995d3e2cd7631df1fc (same branch) has a more sledgehammery fix, which ignores _all_ low bandwidths when computing those flags.

comment:3 Changed 7 years ago by arma

Hm. 61995d3e2cd7 will take the Fast flag away from more relays -- right now we mark the bottom 1/8 as not Fast, and that includes the 0-bandwidth ones. If we don't count the 0-bandwidth ones, then more (faster) relays will fall into the bottom 1/8.

...thus raising the threshold for the Fast flag higher, which in #1854 we speculate might be a good idea. Fine with me to try.

comment:4 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

ok; merging

comment:5 in reply to:  3 Changed 7 years ago by arma

Replying to arma:

Hm. 61995d3e2cd7 will take the Fast flag away from more relays -- right now we mark the bottom 1/8 as not Fast, and that includes the 0-bandwidth ones. If we don't count the 0-bandwidth ones, then more (faster) relays will fall into the bottom 1/8.

...thus raising the threshold for the Fast flag higher, which in #1854 we speculate might be a good idea. Fine with me to try.

While I'm happy to raise the threshold for the Fast flag, it also has the effect of raising the threshold for the Guard flag. And that makes me sad.

comment:6 in reply to:  description Changed 7 years ago by arma

Replying to arma:

Feb 04 00:50:02.020 [info] Cutoffs: For Stable, 404881 sec uptime, 242577 sec MTBF. For Fast: 1 bytes/sec. For Guard: WFU 95.962%, time-known 110475 sec, and bandwidth 71680 or 58291 bytes/sec. We have enough stability data.

Compare to today's line:
Feb 04 18:50:01.796 [info] dirserv_compute_performance_thresholds(): Cutoffs: For Stable, 647629 sec uptime, 150943 sec MTBF. For Fast: 40960 bytes/sec. For Guard: WFU 94.523%, time-known 691200 sec, and bandwidth 174080 or 159613 bytes/sec. We have enough stability data.

Note: See TracTickets for help on using tickets.