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

Re: [tor-bugs] #1789 [Tor Relay]: Wake-up from Hibernation Occurs Day 1 Each Month

#1789: Wake-up from Hibernation Occurs Day 1 Each Month
---------------------------------+------------------------------------------
 Reporter:  BarkerJr             |        Type:  defect   
   Status:  new                  |    Priority:  minor    
Milestone:  Tor: 0.2.2.x-final   |   Component:  Tor Relay
  Version:  Tor: 0.2.2.14-alpha  |    Keywords:           
   Parent:                       |  
---------------------------------+------------------------------------------

Comment(by mwenge):

 Replying to [comment:14 arma]:
 > My first thought is that our calculation for when to wake up is wrong.
 Notice how we never go into hard hibernation, just soft. Also notice how
 we aren't waking up at exactly midnight on day 1 -- we start a few hours
 in, like we think we're leaving 99% of the period available because last
 month we only used 99% of our bandwidth, which means this month we should
 wake up way earlier to make sure to use all of it.

 When you have a AccountingMax of 200GB your soft limit is 190GB, and the
 last set of spam stats show this is the threshold the router hit around
 the 7th. However it never reached its hard limit, and its hard to think of
 a router with such an AccountingMax that could, because hitting the soft
 limit means you don't open new connections - just maintain old ones. The
 router's traffic dropped off and it read another 2GB or so. At that rate
 it would not have reached its AccountingMax for the month.

 So if you're correct that the next accounting interval is based on the
 rate at which you reached your hard limit rather than your soft one then
 all large capacity routers must have this problem. My reading of the code
 is that you are right: n_seconds_active_in_interval appears to be the
 total time for which we were reading/writing bytes and that, together with
 the bytes read/written, is used to calculate our expected bandwidth usage.

 So it looks like Tor needs to tune the 'soft limit is 95% of
 AccountingMax' rule to tolerate servers that specify a high capacity.

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