Re: [tor-bugs] #7157 [Tor]: "Low circuit success rate %u/%u for guard %s=%s."

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#7157: "Low circuit success rate %u/%u for guard %s=%s."
-----------------------------------------+----------------------------------
 Reporter:  arma                         |          Owner:                    
     Type:  enhancement                  |         Status:  needs_review      
 Priority:  normal                       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                          |        Version:                    
 Keywords:  tor-client, MikePerry201210  |         Parent:                    
   Points:                               |   Actualpoints:  8                 
-----------------------------------------+----------------------------------

Comment(by nickm):

 >In my testing, any amount of integer truncation eventually led to the
 accumulation of enough roundoff error for us to either overcount or
 undercount. It was only a matter of time for larger values.
 >
 >I commented the scale_factor and mult_factor functions to be more clear
 about the fact that we only scale if there is no integer truncation, and
 that this means we should be careful when changing those parameters.

 Hm. I am still not comfortable about this.  Can we think about what this
 implies for possible values for those scaling factors? It seems possible
 (though unlikely) to wind up with a sequence of events in which we can
 *never* scale downwards, even with scale_factor == 2.  If you're worried
 about integer roundoff, mightn't the answer be instead to make sure that
 the scale threshold is high, and to perform rounding rather than
 truncating division?

 > This discrepancy turns out to be due to the hidden service cases in that
 function. There is no discrepancy for normal exit circuits.. It also is
 likely the source of potentially deeper issues with proper timeout usage
 for hidden service circuits...

 Ouch.  So I'm assuming this is in "don't merge it right now" state then?
 Could there be some way to re-think the design so that we *can't*
 overcount/undercount?  Perhaps to have a flag that's set the first time we
 count something or render it uncountable, so we can't double-count it?  Or
 is this not an overcounting/undercounting thing?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7157#comment:9>
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