[tor-relays] Raspberry Pi Relay Node Performance and future Plans on Documentation and more

[Nick Mathewson]

On Mon, Aug 12, 2013 at 4:34 AM, Gordon Morehouse <gordon at morehouse.me> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> I still have the really weird circuit creation storms going on.  I'm
> trying to figure out how to *eliminate* the possibility with some kind
> of iptables throttling, but limiting SYNs to 4 per second bursting to
> 10 didn't do anything at all.
>
> I know about the MaxAdvertisedBandwidth trick but it seems like a hacky
> workaround to me.  I'd rather just advertise the bandwidth I have and
> either be able to handle it or, if possible, gracefully degrade during
> a storm, if I can detect it, by throttling circuit creation requests
> or TCP SYNs or whatever does the job.

Circuit creation happens within the Tor protocol.  How many circuit
creation requests you get at once is a function of how much bandwidth
you appear to have.  How many you can handle is a function of how fast
your CPU is, and how fast your crypto implementation is.

You can decrease how much bandwidth you appear to have with
"MaxAdvertisedBandwidth", but you already knew that.

One thing that you should try is seeing whether the latest 0.2.4.x
release does any better for you.  In particular, I'd recommend trying
the just-released 0.2.4.16-rc, with openssl 1.0.1e, and make sure that
openssl 1.0.1e was built with the -enable-ec_nistp_64_gcc_128 option
if possible.  (I see you're already using 1.0.1e, but it doesn't
appear to have been built with that option.)

Using 0.2.4.x should let Tor use a faster circuit extension handshake
to clients that support it.  It will also have Tor use an improved
algorithm for deciding how long is too long for a circuit queue.
Instead of limiting the queue to a fixed number, it limits the size of
the queue based on the expected time to clear it.

(Another thing to look at would be the output of ./src/test/bench in
the 0.2.4.x package.)



yrs,
-- 
Nick