On Sun, Aug 4, 2013 at 9:24 PM, Gordon Morehouse <[email protected]> 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 > [email protected] > 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! _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
