[Tor-BSD] Recognizing Randomness Exhaustion

[Brian Callahan]

Hi Libertas --

On 01/02/15 00:23, Libertas wrote:
> 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

I can't speak for the misc list, but please do not top-post on nycbug
lists. It makes it much more difficult to follow along with the
conversation, and is also mentioned explicitly in our rules:

---
*Please do not top post*

    Top Posting refers to responding to a message from the top of the
    response email. While this is often the convention for many email
    discussions and is also the default for most end-user mail
    applications, it is inconvenient for the many who follow the list
    with text-based mail user agents (MUAs), such as Pine and Mutt. When
    responding to a message, please begin your response at the bottom of
    the message or below the first part you want to comment on and work
    your way down.

---

However, I am glad to see the list being so active; don't interpret this
message as an injunction to stop posting altogether.

~Brian

> 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, \
> _______________________________________________
> Tor-BSD mailing list
> Tor-BSD at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/tor-bsd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150102/d82b57a1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150102/d82b57a1/attachment-0001.bin>