Do you think it might help to restart tor every 24 hours or so using cron Dan - or would that adversely affect the network too much/not actually help?
In my experience, setting the bandwidth advertising options does
nothing to stop the "storms" of circuit creation requests. It *will*
affect the *average* bandwidth used by your relay, but every once in a
while, I'll still get circuit-creation storms that completely overwhelm
my RPi and knock it offline (I'm talking continuous 3Mbps bandwidth use
for several hours when MaxAdvertisedBandwidth is 200 kbps). It seems
from past discussions on the mailing list, this is still an unresolved
issue.
On Mon 14 Oct 2013 04:43:50 PM EDT, Chris Whittleston wrote:
> Thanks Logforme - yeah I was trying that before I sent the first email
> in this chain, but maybe I didn't go low enough with the advertised
> bandwidth. When the 0.2.4 compilation is done (it's still chugging
> along) I'll try going lower and see if it helps.
>
> Chris
>
>
> On 14 October 2013 21:38, Logforme <m7527@abc.se
> <mailto:m7527@abc.se>> wrote:
>
> On 2013-10-14 22:01, Chris Whittleston wrote:
> > I see - so I'll probably still see the problem with a huge number of
> > circuits being created after I've finished building 0.2.4. Is there
> > any way to limit this, I'm guessing reducing the bandwidth wouldn't
> > actually help? I guess I'll look into how much further I can
> overclock
> > the CPU...
> Only option that I know of is to reduce the bandwidth you advertise to
> the network. The more bandwidth you advertise the more circuits
> the tor
> network will throw at your relay. The following flags in the torrc
> file
> can be used (with my current understanding of them):
> BandwidthRate : The max bandwidth you provide over a long period
> of time
> BandwidthBurst : The max bandwidth you provide over a short period
> of time
> MaxAdvertisedBandwidth : The max bandwidth you tell the tor
> network about
> So you can set BandwidthRate to the real max you want to provide and
> then set MaxAdvertisedBandwidth to a number low enough to prevent
> circuit overload.
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@lists.torproject.org
> <mailto:tor-relays@lists.torproject.org>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
>
>
> --
> *Dr Chris Whittleston 栗主*
> Department of Chemistry
> University of Cambridge
> Lensfield Road, Cambridge, CB2 1EW
> Email: csw34@cam.ac.uk <mailto:csw34@cam.ac.uk>
> Tel: +44 (0)1223 336423
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
--
http://disman.tl
OpenPGP key: http://disman.tl/pgp.asc
Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays