[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
-----------------------------------------+----------------------------------
Comment(by mikeperry):
Replying to [comment:9 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?
Hrmm.. I'm pretty sure rounding will only reduce the error.. It can still
accumulate.. Bleh. I'm not seeing any clear way forward here, save for
switching everything to floating point. :/
> > 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?
Yeah, so the discrepancy I'm talking about wrt hidden services is not for
the defense. It's for the informational "You've had these many failures
count as timeouts" part of the log. The issue is in how
circuit_expire_building deals with CBT. It's probably actually a separate
bug.
The actual success counts are already enforced with such a state flag.
However, yeah, I'm still testing with this branch. Don't merge it just
yet.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7157#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