Messages in this thread | | | From | Lucas De Marchi <> | Date | Wed, 4 Mar 2015 12:19:58 -0300 | Subject | Re: timerfd waking up before timer really expires |
| |
On Wed, Mar 4, 2015 at 5:06 AM, Clemens Ladisch <clemens@ladisch.de> wrote: > Lucas De Marchi wrote: >> I was debugging my application and noticed that a timerfd event was being >> triggered *before* the timer expires. >> >> I reduced the scope of the program to test a single timerfd and measure the >> difference in the result of clock_gettime() between two reads. >> >> loop_time_fd = setup_timerfd(interval, 0); >> do { >> read(loop_time_fd, &events, sizeof(events)); >> ... = now_usec(); >> } while (1); >> >> For whatever interval I configure and 10000 iterations, what I'm seeing in the >> elapsed vector are values like >> >> interval +- 70usec > > Let us assume that the timer itself is perfectly accurate, and that all > wakeups of your program are immediately when the timerfd becomes ready, > except for one iteration, where there is a scheduling delay. Then the > measured interval before this delayed wakeup is longer, while the > measured interval after this wakeup is shorter by the same amount. > > To detect early wakeups, you must not check whether the interval between > two consecutive wakeups is too short, but whether the interval between > a wakeup and the time when the timerfd was actually started is shorter > than N × the timer interval.
oohh, /me blushes...
That makes perfect sense since I'm not re-arming the timer for another period and instead timerfd is doing it for me. If fixed it in my code and then for 10k iterations and an interval of 1ms I have (number-of-occurrences time): 9959 1000 9 1001 12 1002 5 1003 5 1004 2 1005 1 1009 2 1010 1 1012 1 1016 1 1018 1 1024 1 1027
None with < 1ms and max latency of 27us.
Thanks
-- Lucas De Marchi
| |