Libertas,

As I wrote to you earlier today, IPredator on Linux complained of similar issues with excessive calls to time() under the Linux 3.x kernel series, but not 2.6.

Let's track these issues in https://trac.torproject.org/projects/tor/ticket/14056 as they appear to be quite similar.

I'd like to get a sense of how many calls per second this represents. (400,000 would seem to be 100 to 1000 per second, unless you were debugging for a long while.)

I'd also like to know which function(s)/call stack(s) these calls are being made from.

I wonder if TIME_IS_FAST is being defined as 1 in any of these Linux or BSD builds. This

If TIME_IS_FAST is not defined (the default), we could change these calls to approx_time(), which is much faster. And in that case there should only be around 1 call to time() each second, which is clearly not the behaviour that either Libertas or IPredator are seeing.

Libertas, can you search your tor binary or tor debug symbols for the function "approx_time"? grep will do this for you, or strings, or perhaps gdb if you feel like doing it the hard way.

I'll add these questions to trac ticket #14056 as well.

Libertas wrote:

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.

...

<snip>