[tor-relays] big spike in cpu usage

[Matt Joyce]

On 08/04/13 18:41, Andreas Krey wrote:
> On Mon, 08 Apr 2013 08:47:56 +0000, Sebastian Hahn wrote:
> ...
>> Now, it's entirely possible I'm missing something big here; or that the
>> code changed and now does something different; or that it used to do
>> something different, etc. Andreas, can you please explain more?
> At least the original change explains different:
>
> +--- ReleaseNotes -----
> | 
> Changes in version 0.0.2pre20 - 2004-01-30
> | ...
> | 
> |     - I've split the TotalBandwidth option into BandwidthRate (how many
> |       bytes per second you want to allow, long-term) and
> |       BandwidthBurst (how many bytes you will allow at once before the cap
> |       kicks in).  This better token bucket approach lets you, say, set
> |       BandwidthRate to 10KB/s and BandwidthBurst to 10MB, allowing good
> |       performance while not exceeding your monthly bandwidth quota.
> +---------------------
>
> ..which is pretty much my usage scenario, just with smaller numbers.
>
> And the code looks likewise. We have the global_*_buckets that are
> initialized from *BandwidthBurst, and get incremented regularly by
> *BandwidthRate (divide by increment frequency; TokenBucketRefillInterval)
> and then capped to the *BandwidthBurst.
>
> Thus *BandwidthBurst ist the total amount of unused traffic we can
> save up to later fire with more than *BandwidthRate. No 'per second'.
>
> (The interesting part is that the global_*_bucket are ints;
>  much more than the 1 GB default could behave strangely.)
>
> Andreas
>
Wouldn't using the AccountingMax and AccountingStart configuration
options be more suitable if the objective is to enforce a bandwidth
limitation over timeframes of a day/week/month instead of trying to do
it this way which limits burst durations, using the accounting options
it would seem to me that it's more flexable to the needs of the network
as the accounting options were designed for this purpose.

In particular I note the following (src tor manpage) emphasis is mine:

AccountingMax N bytes|KBytes|MBytes|GBytes|TBytes
Never send more than the specified number of bytes in a given accounting
period, or receive more than that number in the period. For example,
with AccountingMax set to 1 GByte, a server could send 900 MBytes and
receive 800 MBytes and continue running. It will only hibernate once one
of the two reaches 1 GByte. When the number of bytes gets low, Tor will
stop accepting new connections and circuits. When the number of bytes is
exhausted, Tor will hibernate until some time in the next accounting
period. To prevent all servers from waking at the same time, Tor will
also wait until a random point in each period before waking up. If you
have bandwidth cost issues, ***enabling hibernation is preferable to
setting a low bandwidth, since it provides users with a collection of
fast servers that are up some of the time, which is more useful than a
set of slow servers that are always "available".***

AccountingStart day|week|month [day] HH:MM
Specify how long accounting periods last. If month is given, each
accounting period runs from the time HH:MM on the dayth day of one month
to the same day and time of the next. (The day must be between 1 and
28.) If week is given, each accounting period runs from the time HH:MM
of the dayth day of one week to the same day and time of the next week,
with Monday as day 1 and Sunday as day 7. If day is given, each
accounting period runs from the time HH:MM each day to the same time on
the next day. All times are local, and given in 24-hour time. (Default:
"month 1 0:00")


Essentially this way you can give tor a "budget" for the month for
example to not to exceed but there are no constraints on when or how
long it can burst thus while capacity remains in your package subject to
the limits you have set the network can use the capacity whenever it is
required by the needs of the network.  Before using this however do
check whether your provider counts upload download or both, if they
count both you would need to set AccountingMax to half the stated value
in order to ensure you remain bellow the limit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20130412/4902810f/attachment.pgp>