HPET timer accuracy for interrupts

Latest response


I am developing an application in RHEL 7.1/7.2 to generate interrupts at the user specified duration (Eg: 100 micro seconds) on intel board.
For this, i am using HPET timers in Intel board using the sample code(attached).

Using sample program attached we have run as ./exe 2500 1
Means for every 400 usec 1 packet shall be generated for the duration of 1 second. (2500*400usec=1 second)

Netwrok speed 1000 Mbps

Testing Methodology Steps: For 100 microseconds interrupts to be generated.

UDP packet to be send to external system (RHEL OS).
Using Hpet timer generate interrupt.

We are timestamping the time in external system of first received udp packet and subsequent packet.
The difference between the packets is drifting gradually downwards and upwards..

For example:
1st udp packet received in external system at time 10000 usec
hpet interrupt takes 100 usec
2nd udp packet recevived in external system at time 10140 usec.

Difference is = 10140-10000 = 140usec

We have logged the values in log file by storing in buffers after completion of transmission.

We have tested for 17,83,020 packets
Results : >160 usec (2284 packets)
<80 usec (10758 packets)

The delay is randomly increasing or decresing..

Can anyone help me to restrict the delay to a certain range. For 100 usec acceptable Delay range is 100+/-20 usec.


Is HPET timer will generate interrupts with constant delay or random delay at user space???
We have observed it is generating interrupts at random delay.

Is there anyway to acheive the delay of 100+/-20 micro seconds. Please help me to acheive above accuracy.

Krishna Reddy



The exact details of this aren't my usual area. I'm not familiar with signal handlers and I've never written for the HPET before, I've only ever written this as a timer callback (i.e. timer_create (CLOCK_REALTIME) and signal(SIGALRM, timer_callback);) but I do know that achieving sub-millisecond timing accuracy even on one standalone system is very difficult. Once you introduce packet transmit and receive, you'll get even more variety in latency.

If you haven't done so, we have a wealth of system tuning suggestions you can try to see if things improve in the RHEL 7 Realtime product documentation:

These include isolating the CPUs running your process out of the scheduler with isolcpus, tick behaviour with nohz, CPU sleep states, Transparent Huge Pages, process scheduling, NIC coalesce settings, and much more. Our tuned adaptive tuning daemon provides a latency-performance profile to help get you pointed in the right direction, users are encouraged to write a more precise profile based off ours.