[tor-dev] Tor BSD underperformance (was [Tor-BSD] Recognizing Randomness Exhaustion)

[Libertas]

I just ran ktrace/kdump (used for observing system calls) on the Tor
process of my exit node, which relays about 800 KB/s. It listed >400,000
calls to gettimeofday(). The list was swamped with them.

I think I remember reading somewhere that that sort of system call is
way slower in OpenBSD than Linux. Could this be related to the issue?
I've found a lot of similarly mysterious slowdowns related to *BSD
gettimeofday() on other projects' bug trackers, but nothing definitive.

As you've likely noticed, although I started this discussion I'm very
new to system-level performance tuning. Let me know if I'm not making
sense, or if there's something else I should be focusing on.

On 12/31/2014 10:37 PM, Yawning Angel wrote:
> On Thu, 1 Jan 2015 14:19:08 +1100
> teor <teor2345 at gmail.com> wrote:
>> On 1 Jan 2015, at 07:39 , Greg Troxel <gdt at lexort.com> wrote:
>>
>> Tor 0.2.6.2-alpha (just in the process of being released) has some
>> changes to queuing behaviour using the KIST algorithm. 
>>
>> The KIST algorithm keeps the queues inside tor, and makes
>> prioritisation decisions from there, rather than writing as much as
>> possible to the OS TCP queues. I'm not sure how functional it is on
>> *BSDs, but Nick Mathewson should be able to comment on that. (I've
>> cc'd tor-dev and Nick.)
> 
> I don't think we merged that branch yet, since it's not ready for
> general use.  Additionally, it's not currently functional on the
> *BSDs.  The KIST code last I checked only is used under Linux.  While
> the full portability story is in #12890 it looks roughly like:
> 
>  * Linux - Supported.
>  * Windows - Possible, needs code in tor.
>  * Darwin - Possible, uses interfaces marked as undocumented/internal.
>  * FreeBSD - Requires a trivial kernel patch (interface is there,
>    information exposed is incomplete).
>  * Other BSDs - Requires a kernel patch, which is more involved than
>    the FreeBSD one (implementing the required interface vs exposing
>    more information).  The patch is still trivial for anyone that's
>    familiar with the TCP/IP code.
> 
> I don't think we should be in the business of maintaining kernel
> patches either, so I'm not sure what the right thing to do would be for
> non-Darwin *BSD.
> 
> Regards,
> 
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-------------- 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.torproject.org/pipermail/tor-dev/attachments/20141231/19ea6acc/attachment.sig>