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

Bill Waggoner ctgreybeard at gmail.com
Mon Aug 5 01:36:58 UTC 2013


On Sun, Aug 4, 2013 at 9:24 PM, Gordon Morehouse <gordon at morehouse.me> wrote:
> Michael Berlin:
>> The logged throughput is also consistent with what I saw with the console
>> traffic monitor "nload" (suggested command line options for nicer units and
>> less refreshes: nload -u K -U G -t 3000). I guess, I saw even higher peaks
>> there. Monitoring everything with "arm" is also nice but far too CPU
>> intensive.
>
> A quick thought - can we pull together data on tor monitoring utilities
> and then figure out the best bang for armhf CPU buck?
>
> 'nload' is good, but doesn't tell me much about *tor's* condition (other
> than it's probably not dead if there's still traffic flowing).  It'd be
> nice to have some notion of circuits open, circuit creation rate, and
> tor's memory and CPU usage all on one screen, like 'arm', but lighter.
>
> I agree about 'arm', BTW.  I use it for tuning on my x86-based relays,
> but it's buggy and it is really too heavy for the Pi's CPU.  Maybe I
> should try to see if I can get 'arm' to run under PyPy[1] - I wonder if
> PyPy is faster on armhf like it can be on x86 and amd64.
>
> [1] http://pypy.org/
>
> Best,
> -Gordon
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

In case you are wondering if anyone is following this, please
continue! I have an aging Mac Mini that's running a Tor relay and one
day it's going to go belly-up. I have an RPi that I could easily
re-purpose to replace my relay. And while the Mini is low-powered the
Pi is lower still so any tuning advice will be appreciated!

Thanks!


More information about the tor-relays mailing list