[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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                 
-----------------------------------------+----------------------------------
Changes (by mikeperry):

  * keywords:  tor-client => tor-client, MikePerry201210
  * status:  needs_revision => needs_review
  * type:  defect => enhancement
  * actualpoints:  => 8


Comment:

 Replying to [comment:3 nickm]:
 > quick review:
 >
 >   * I have a hard time understanding why the code does "%" in
 "((mult_factor * foo) % scale_factor) == 0". I guess that you're trying to
 avoid integer truncation, but won't this prevent scaling entirely?
 Suppose scale_factor is 100. It seems to me that unless first_hops and
 circuit_successes are both divisible by 100 at the same time, they'll
 never get scaled.  Can't we just reserve scaling for when the values are
 "big enough" that integer truncation won't matter?

 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.

 >   * The "your guard %s=%s" code should probably get refactored to use
 the same format as node_describe , and probably to be an independent
 function.

 I looked at node_describe and router_describe, and they seemed overkill
 for this. Both functions output a bunch of info we simply do not have
 available for entry_guard_t (since we might not have a node_t or a
 routerinfo_t for the guard).. Effectively I'd be writing a custom utility
 function just to do "%s=%s" in this case, which seemed silly.


 Everything else you mentioned has been pushed to that branch. I'll try to
 test a build with this code and #3443 soon.

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