[Tor-BSD] Recognizing Randomness Exhaustion

[Libertas]

I've tuned PF parameters in the past, but it doesn't seem to be the
issue. My current pfctl and netstat -m outputs suggest that there are
more than enough available resources and no reported failures.

I remember someone on tor-bsd at list.nycbug.org suggesting that it could
be at least partially due to PF being slower than other OS's firewalls.

However, we're now finding that a profusion of gettimeofday() syscalls
may be the issue. It was independently discovered by the operator of
IPredator, the highest-bandwidth Tor relay:

	https://ipredator.se/guide/torserver#performance

My 800 KB/s exit node had up to 7,000 gettimeofday() calls a second,
along with hundreds of clock_gettime() calls.

Because IPredator runs Linux, he used vsyscalls to speed things up.
We'll probably need to find something more creative, like using our time
caching more.

We're working on it with this ticket:

	https://trac.torproject.org/projects/tor/ticket/14056

On 01/01/2015 10:45 PM, Richard Johnson wrote:
> It can also be pf-state-hungry. Further, each upstream peer Tor node, and each 
> client on a Tor entry node, will probably be a pf src.
> 
> Packets being dropped and circuits failing when the pf default limits topped 
> out would naturally present to the tor bandwidth authorities as network 
> congestion.
> 
> In my case, I'm now fairly certain my relays usage grew to the point where 
> they were allocation-bound in pf. The host was still using the pf defaults 
> until recently.
> 
> Since increasing the pf limits, I'm seeing better throughput. The "current 
> entries" from pfctl -si currently reach 35k instead of hitting the default 
> limit of 10k. Also, state inserts and removals are up to 50/s from 29/s, and 
> matches are topping 56/s instead of 30/s. As well, the pfctl -si "memory could 
> not be allocated" counter remains a reassuring 0 instead of increasing at 
> 0.9/s. Additionally, netstat -m counters for pf* have a reassuring 0 in the 
> failure column of the memory resource pool stats. Finally, Tor network traffic 
> seems to have started climbing.
> 
> I increased the limits thusly, since the host does nothing but Tor and unbound 
> for Tor DNS.
> 
> | # don't choke on lots of circuits (default is states 10000,
> | # src-nodes 10000, frags 1536)
> | set limit { states 100000, src-nodes 100000, frags 8000, \