<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Libertas --<br>
    <br>
    <div class="moz-cite-prefix">On 01/02/15 00:23, Libertas wrote:<br>
    </div>
    <blockquote cite="mid:54A62B69.3030803@mykolab.com" type="cite">
      <pre wrap="">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 <a class="moz-txt-link-abbreviated" href="mailto:tor-bsd@list.nycbug.org">tor-bsd@list.nycbug.org</a> 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:

        <a class="moz-txt-link-freetext" href="https://ipredator.se/guide/torserver#performance">https://ipredator.se/guide/torserver#performance</a>

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:

        <a class="moz-txt-link-freetext" href="https://trac.torproject.org/projects/tor/ticket/14056">https://trac.torproject.org/projects/tor/ticket/14056</a>
</pre>
    </blockquote>
    <br>
    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:<br>
    <br>
    ---<br>
    <strong>Please do not top post</strong>
    <blockquote>
      <p>
        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.<br>
      </p>
    </blockquote>
    ---<br>
    <br>
    However, I am glad to see the list being so active; don't interpret
    this message as an injunction to stop posting altogether.<br>
    <br>
    ~Brian<br>
    <br>
    <blockquote cite="mid:54A62B69.3030803@mykolab.com" type="cite">
      <pre wrap="">
On 01/01/2015 10:45 PM, Richard Johnson wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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, \
</pre>
      </blockquote>
      <pre wrap="">_______________________________________________
Tor-BSD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tor-BSD@lists.nycbug.org">Tor-BSD@lists.nycbug.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nycbug.org/mailman/listinfo/tor-bsd">http://lists.nycbug.org/mailman/listinfo/tor-bsd</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>