[drewg123]

Another option is to reduce usage of gettimeofday() when possible. It is not always free.

Roughly 10 years ago, when I was the driver author for one of the first full-speed 10GbE NICs, we'd get complaints from customers that were sure our NIC could not do 10Gbs, as iperf showed it was limited to 3Gb/s or less. I would ask them to re-try with netperf, and they'd see full bandwidth. I eventually figured out that the complaints were coming from customers running distros without the vdso stuff, and/or running other OSes which (at the time) didn't support that (Mac OS, FreeBSD). It turns out that the difference was that iperf would call gettimeofday() around every socket write to measure bandwidth. But netperf would just issue gettimeofday calls at the start and the end of the benchmark, so iperf was effectively gettimeofday bound. Ugh.

[tedunangst]

> Another option is to reduce usage of gettimeofday() when possible. It is not always free.

haha, it's amazing how much software is written that basically does something ridiculous like "while (gettimeofday()) clock_gettime();".

[adrianN]

I found the articles on your blog about that topic quite interesting.

[vidarh]

Syscalls in general far too often gets treated as if they're as cheap as function calls, with people often never profiling to see just how much they can affect throughput.

Apart from gettimeofday() other "favourites" of mine that people are often blind to include apps that do lots of unnecessary stat-ing of files, as well as tiny read()/write()'s instead of buffering in userspace.

[LanceH]

Maybe you could set up some caching.

[drewg123]

Caching is basically what the vdso things do. In my recollection, they basically grab a good time from the kernel occasionally, and then use userspace accessible things like rdtsc() to offset from that authoritative timestamp. So it turns millions of syscalls into one.

[sly010]

For time?

[coldtea]

Yes, for time too. For one, if you don't need over second precision, they why have some of your servers e.g. ask for the current time thousands of times per second? There are ways to get a soft expiration that don't involve asking for the time.

[kccqzy]

In case someone is interested in a concrete example, I first learned about caching time by discovering this package in my dependencies: https://hackage.haskell.org/package/auto-update

Its README basically says instead of having every web request result in a call to get current time, it instead creates a green thread that runs every second, updating a mutable pointer that stores the current time.

[monktastic1]

Yeah, with a TTL, and on each round you just check the time to see if it's expired.

[throwaway2048]

yeah just call gettimeofday() to see if it expired yet.

[OJFord]

Obviously you don't use clock-TTL.

[LanceH]

Sorry, I couldn't resist.