boost deadline_timer shift 10 milliseconds

Question

Have anyone encounter that the deadline_timer call the next callback function with 10 millisecond later constantly? Is it expected?

The OS is centos 6 and boost version is 1.54.

e.g.

Aug 14 16:36:01.697
Aug 14 16:36:02.706
Aug 14 16:36:03.716
Aug 14 16:36:04.726
Aug 14 16:36:05.736
Aug 14 16:36:06.746
Aug 14 16:36:07.756
Aug 14 16:36:08.766
Aug 14 16:36:09.776
Aug 14 16:36:10.786
Aug 14 16:36:11.796
Aug 14 16:36:12.806
Aug 14 16:36:13.816
Aug 14 16:36:14.826
Aug 14 16:36:15.836
Aug 14 16:36:16.846
Aug 14 16:36:17.856

the code looks like below

// std::unique_ptr<boost::asio::deadline_timer> m_poTimer;

void timerExpired(const boost::system::error_code& oError)
    {
        if (!oError)
        {
            m_poTimer->expires_from_now(boost::posix_time::millisec(1000));
            m_poTimer->async_wait(std::bind(&timerExpired, this, std::placeholders::_1));
        }
        else
        {

        }
    }

Depending on operating system and underlying timer used, they may fire the event a short time after the expiration of the timer. For example, from [the `setitimer` manual page](http://man7.org/linux/man-pages/man2/setitimer.2.html): "Timers will never expire before the requested time, but may expire some (short) time afterward, which depends on the system timer resolution and on the system load". — Some programmer dude, Aug 14 '15 at 09:02
No not really. In fact, it's actually almost impossible to have exact and precise timers on a general purpose operating systems, even on powerful and fast computers of today. There's always going to be a small delay, unless you want to risk the timer firing early instead. — Some programmer dude, Aug 14 '15 at 09:09
But it is kind of strange that the there is constantly 10 ms delay. and I try to set the period from 1000 ms to 990 ms. Then I got the exact 1 second delay — Michael D, Aug 14 '15 at 09:13
Clock resolution? The time it takes to preempt some other process for yours? The time it takes for Boost to propagate the event? Maybe the time isn't exactly 10ms, but sometimes it could be 9.8ms and sometimes 10.2ms, and it just averages out at 10ms? Unless you study the whole stack from your process down through Boost and the kernel to the hardware, there's really no way of saying exactly why. — Some programmer dude, Aug 14 '15 at 09:19
Where is your [**testcase**](http://stackoverflow.com/help/mvce)?? — Lightness Races in Orbit, Aug 14 '15 at 10:00
@LightnessRacesinOrbit that dead link is the reason I prefer SSCCE :) Easier to get right — sehe, Aug 16 '15 at 20:17

score 1 · Answer 1 · edited May 23 '17 at 12:14

Like any application-layer timer on a general purpose time-shared operating system, it is fundamentally impossible to guarantee execution after a precise time. Your OS is constantly context-switching between processes and threads, usually with around 5-10ms resolution, and your code has no way of interrupting the CPU for immediate execution without something to wake it up and check the timer in the first place.

All application-layer timers are for "at least t" and there's nothing you can do about that.

I concede surprise that you have such a reliable and repeatable pattern, but either:

this is a factor of your environment (which we can't speak to), or
this is a factor of the library (for which I can see no evidence), or
this is a factor of your code (which we can't tell because you did not present a testcase), or
this is simply an anomaly created by the above facts, and you can't do anything about it.

boost deadline_timer shift 10 milliseconds

1 Answers1

Linked