[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