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

Re: Regulating bandwidth

Hash: RIPEMD160

    This is what I'm currently doing. Rate limits are currently high,
and run out after about 3 hours, as I noted before. Still, if I could
halve the rate and double the effective time limit, I could serve more
people. My limit is 3mbps down/384k up right now in theory for my K-bull.


- ---

Frivolous lawsuits. Unlawful government seizures. What's YOUR defense?
Protect your assets, keep what you earn, and generate more income at the
same time!
Visit http://www.mpassetprotection.com/ today.

On 05/25/2007 12:47 PM, Michael_google gmail_Gersten wrote:
> May I strongly suggest keeping your bandwidth as high as you can
> afford, even if it means the limit runs out early?
> Right now the two biggest limits on Tor's speed is transmission speed
> and CPU overhead. I'm realizing that there's no CPU limit -- there's
> no "Only let N incoming routes exist" config parameter. And lowering
> the transmission speed will only reduce Tor's speed.
> Can we get a "CPU limit" / "Only let N incoming connections" parameter?
> On 5/25/07, Roger Dingledine <arma@xxxxxxx> wrote:
>> On Fri, May 25, 2007 at 10:59:07AM -0700, Andrew Del Vecchio wrote:
>> > What's the best way to ensure that Tor spreads bandwidth more or
>> less
>> > evenly over a AccountingMax period? Currently, my 1GB of allocation
>> > gets eaten up over the first three hours or so of operation.
>> Currently we recommend that you manually set your BandwidthRate so
>> your accounting quota is expected to be exhausted halfway through your
>> accounting period.
>> See the last paragraph of
>> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#Hibernation
>> for details.
>> > I could
>> > set the rate limits lower, but is there currently a way for Tor to
>> > make inteligent decisions based on the average load? In other words,
>> > in an ideal world, Tor would determine the average load, and
>> normalize
>> > it over the 24 hour AccountingMax period, giving the average rate as
>> > the upper bandwidth rate during the day. This average would move
>> a bit
>> > over time, but always aim for AccountingMax over the course of the
>> > average day.
>> I wouldn't object to a config option AccountingBandwidthAuto or the
>> like that does what you describe. This would save people from
>> needing to
>> do that calculation. In fact, the naive implementation could be really
>> easy -- it could just take the AccountingMax and accounting period and
>> do the math. But it could also try to get smarter, as you say.
>> So, feel free to submit a patch. :)
>> --Roger
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org