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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
