Fwd: [tor-dev] gettimeofday() Syscall Issues
kostikbel at gmail.com
Fri Jan 2 17:25:01 UTC 2015
On Fri, Jan 02, 2015 at 09:09:34AM -0500, grarpamp wrote:
> Some recent FreeBSD related questions in this app area.
What is the question ?
As a background, I can repeat that FreeBSD implements syscall-less
gettimeofday() and clock_gettime() for x86 machines which have
usable RDTSC. The selection of the timecounter can be verified
by sysctl kern.timecounter.hardware, and enabled by default fast
gettimeofday(2) can be checked by sysctl kern.timecounter.fast_gettime.
On some Nehalem machine, I see it doing ~30M calls/sec with enabled
fast_gettime, and ~6.25M calls/sec with disabled fast_gettime. This is
measured on 2.8GHz Core i7 930 with src/tools/tools/syscall_timing.
Check your timecounter hardware. Since it was noted that the tests
were done in VM, check the quality of RDTSC emulation in your hypervisor.
> ---------- Forwarded message ----------
> From: Yawning Angel <yawning at schwanenlied.me>
> Date: Fri, Jan 2, 2015 at 5:20 AM
> Subject: Re: [tor-dev] gettimeofday() Syscall Issues
> To: tor-dev at lists.torproject.org
> On Thu, 01 Jan 2015 23:42:42 -0500
> Libertas <libertas at mykolab.com> wrote:
> > The first two account for the bulk of the calls, as they are in the
> > core data relaying logic.
> > Ultimately, the problem seems to be that the caching is very weak. At
> > most, only half of the calls to tor_gettimeofday_cached_monotonic()
> > use the cache. It appears in the vomiting print statements that
> > loading a single simple HTML page
> > (http://www.openbsd.org/faq/ports/guide.html to be exact) will cause
> > >30 gettimeofday() syscalls. You can imagine how that would
> > >accumulate for an exit carrying 800 KB/s if the caching
> > doesn't improve much with additional circuits.
> So while optimization is cool and all, I'm not seeing why this
> specifically is the underlying issue.
> Each cell can contain 498 bytes of user payload. Looking at things
> simplistically this is 800 KiB/s -> 1644 cells/sec, leaving you with
> approximately 608 microseconds of processing time per cell.
> On my i5-4250U box, gettimeofday() takes 22 ns on Linux, and 2441 ns on
> FreeBSD. I'm not sure how accurate the FreeBSD results are as it was
> in a VirtualBox VM (getpid() on the same VM takes 124 ns). If someone
> has a OpenBSD box they should benchmark gettimeofday() and see how long
> the call takes.
> Taking the FreeBSD case (since we know that tor works fine on Linux), a
> single gettimeofday() call takes approximately, 0.39% of the per-cell
> processing budget.
> For reference (assuming gettimeofday() in *BSD really is this shit
> performance wise), 7000 calls to gettimeofday() is 17.09 ms worth of
> The clock code in tor does need love, so I wouldn't object to cleanup,
> but I'm not sure it's in the state where it's causing the massive
> performance degradation that you are seeing.
> Yawning Angel
> tor-dev mailing list
> tor-dev at lists.torproject.org
> freebsd-performance at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-performance-unsubscribe at freebsd.org"
More information about the freebsd-performance