[tor-bugs] #1206 [Tor Relay]: Fluxe3 is not a guard
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Fri Sep 3 22:23:21 UTC 2010
#1206: Fluxe3 is not a guard
--------------------------------+-------------------------------------------
Reporter: Sebastian | Type: defect
Status: new | Priority: minor
Milestone: Tor: 0.2.2.x-final | Component: Tor Relay
Version: 0.2.2.6-alpha | Resolution: None
Keywords: | Parent:
--------------------------------+-------------------------------------------
Comment(by arma):
Replying to [comment:5 nickm]:
> So, the right solution here may be to lower the WFU threshold, or
increase the decay factor on the weighting so that older time counts even
less. Can somebody with an authority tell me what the current wfu
thresholds are?
Sep 03 16:50:01.094 [info] Cutoffs: For Stable, 247593 sec uptime, 589401
sec MTBF. For Fast: 20480 bytes/sec. For Guard: WFU 98.000%, time-known
680372 sec, and bandwidth 71680 or 102400 bytes/sec. We have enough
stability data.
Sep 03 17:50:01.121 [info] Cutoffs: For Stable, 266189 sec uptime, 635182
sec MTBF. For Fast: 20480 bytes/sec. For Guard: WFU 98.000%, time-known
691200 sec, and bandwidth 76800 or 102400 bytes/sec. We have enough
stability data.
moria1's wfu threshold has been 98% for the past weeks. Presumably ever
since Mike lowered this constant:
#define WFU_TO_GUARANTEE_GUARD (0.98)
See also
{{{
guard_wfu = median_double(wfus, n_familiar);
if (guard_wfu > WFU_TO_GUARANTEE_GUARD)
guard_wfu = WFU_TO_GUARANTEE_GUARD;
}}}
So it looks like the median WFU is over 98%, and the guarantee cuts it
down to 98%?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1206#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list