boost deadline_timer shift 10 milliseconds

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
        {

        }
    }

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.