[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1206 [Tor Relay]: Fluxe3 is not a guard
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs