-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
root@tor:/ # cat /proc/cpuinfo | grep aes cat: /proc/cpuinfo: No such file or directory
According to a stackoverflow page [2], you can look for hints indicating the existence of AES-NI support in "sysctl hw" and /var/run/dmesg.boot
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 675 _tor 2 20 0 130M 126M sbwait 567:31 7.96% tor Uses maximum 10-12% of the available CPU. Uses maximum 150 - 160 MB of RAM. (~15%)
okay, so CPU doesn't seem to be a bottleneck, as expected.
You could try downloading a large (some 100 MBs) file from a fast server via wget to see whether you can saturate your downstream.
here is one I am freebie hired to maintain: 6C36F9ACBA57AC9C10DBC39D330CFA337522E72B
It is an Exit relay. I am not sure, maybe Tor is designed in a way that Exits are strongly preferred for Exit connections, so they get less traffic for HSDir/V2Dir requests or for being a Rendezvous Point or Introduction Point for Hidden Services. That is mostly speculation on my part though. I never had any Exit relays on my own. Probably the Tor Path Specification [3] has the answer to that question.
Your relay seems to be the only one in that /16 subnet, so that wouldn't be a reason for less-than-normal traffic.
[2] http://stackoverflow.com/questions/4083848/what-is-the-equivalent-of-proc-cp...
[3] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=path-spec.t...