Home/ Questions/Q 6078297
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T10:49:01+00:00

In trying to build a very latency sensitive application, that needs to send 100s

  • 0

In trying to build a very latency sensitive application, that needs to send 100s of messages a seconds, each message having the time field, we wanted to consider optimizing gettimeofday.
Out first thought was rdtsc based optimization. Any thoughts ? Any other pointers ?
Required accurancy of the time value returned is in milliseconds, but it isn’t a big deal if the value is occasionally out of sync with the receiver for 1-2 milliseconds.
Trying to do better than the 62 nanoseconds gettimeofday takes

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Have you actually benchmarked, and found gettimeofday to be unacceptably slow?

    At the rate of 100 messages a second, you have 10ms of CPU time per message. If you have multiple cores, assuming it can be fully parallelized, you can easily increase that by 4-6x – that’s 40-60ms per message! The cost of gettimeofday is unlikely to be anywhere near 10ms – I’d suspect it to be more like 1-10 microseconds (on my system, microbenchmarking it gives about 1 microsecond per call – try it for yourself). Your optimization efforts would be better spent elsewhere.

    While using the TSC is a reasonable idea, modern Linux already has a userspace TSC-based gettimeofday – where possible, the vdso will pull in an implementation of gettimeofday that applies an offset (read from a shared kernel-user memory segment) to rdtsc‘s value, thus computing the time of day without entering the kernel. However, some CPU models don’t have a TSC synchronized between different cores or different packages, and so this can end up being disabled. If you want high performance timing, you might first want to consider finding a CPU model that does have a synchronized TSC.

    That said, if you’re willing to sacrifice a significant amount of resolution (your timing will only be accurate to the last tick, meaning it could be off by tens of milliseconds), you could use CLOCK_MONOTONIC_COARSE or CLOCK_REALTIME_COARSE with clock_gettime. This is also implemented with the vdso as well, and guaranteed not to call into the kernel (for recent kernels and glibc).

    • 0