Re: Regulating bandwidth

[Andrew Del Vecchio <firefox-gen@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Mike,
    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.

~Andrew

- ---

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
>>
>>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGV1yBgwZR2XMkZmQRA39oAJ0X3QJSrIJgBTbW4R93pxTvRiHSnwCdHuV1
2DHOJakOxybzZkXPkQ2IBjw=
=HF41
-----END PGP SIGNATURE-----