boost asio: boost::asio::deadline_timer blocking ?
Using boost asio 1.47, suse linux 11.3, gcc 4.5 I am using boost::asio::deadline_timer, where the timer fires every second. When the timer expires, I check responses from the clients. I use the same timer to check when I have reach the minute boundary, so that server can do some other work. Now 99.9% of the time this works perfectly. However occasionally the timer does not fire every second, in fact it can delay/block for several minutes! This is what I use: timer_.expires_from_now( boost::posix_time::seconds( 1 ) ); timer_.async_wait( server_->io_service_.wrap( boost::bind( &NodeTreeTraverser::traverse,this,boost::asio::placeholders::error ) ) ); When I run strace on the process I see: epoll_wait(4, {{EPOLLIN, {u32=15957244, u64=15957244}}}, 128, 4294967295) = 1 timerfd_settime(5, 0, {it_interval={0, 0}, it_value={16, 944525000}}, {it_interval={16048400, 15957984}, it_value={140733847085872, 6025966}}) = 0 timerfd_settime(5, 0, {it_interval={0, 0}, it_value={0, 999992000}}, {it_interval={15958092, 6011901}, it_value={17195917584, 140733847086024}}) = 0 I have several questions: o Are there known problems with boost::asio::deadline_timer accuracy I realise I need soft real time, with one minute resolution. o Should I have two separate timers, one 1 second & for 1 minute o Is using timer_.expires_at(...) more reliable, I assume this affects how it configures timerfd_settime o Now I suspect this issue may be related to slow disk system Could a slow disk system affect timerfd_settime system call, since it is based on file descriptors. o Are there any well known asio based design patterns/idioms for ensuring reliable timer resolutions Any help appreciated. Ta, Avi
Using boost asio 1.47, suse linux 11.3, gcc 4.5 I am using boost::asio::deadline_timer, where the timer fires every second. When the timer expires, I check responses from the clients. I use the same timer to check when I have reach the minute boundary, so that server can do some other work.
Now 99.9% of the time this works perfectly. However occasionally the timer does not fire every second, in fact it can delay/block for several minutes!
FWIW, I'm using asio:deadline_timer's quite intensively with different resolutions (from tens of ms to tens of sec), and never encountered such an issue. Typically, in my application there're a few tens of timers associated with several io_services (io_service-per-cpu approach) with different deadlines, and all of them fire as expected. Check that you never block any completion-handler (timed locks, time-consuming processing etc). Besides, try upgrading to the most recent asio (see revision history: http://www.boost.org/doc/libs/1_52_0/doc/html/boost_asio/history.html) By the way, is it possible that the above 0.1% happens when the system time gets updated (eg. due to NTP synchronization)? If yes, see my comments below.
o Are there known problems with boost::asio::deadline_timer accuracy I realise I need soft real time, with one minute resolution.
At these resolutions there shouldn't be any problem. It has monotonicity issues, which are solved in 1.49 by steady_timer, but if you don't update the system-time it shouldn't affect you. (See the following: http://permalink.gmane.org/gmane.comp.lib.boost.asio.user/5183)
o Should I have two separate timers, one 1 second & for 1 minute
After the timer expires and the completion handler gets called, you can re-set the same timer with any other deadline.
o Is using timer_.expires_at(...) more reliable, I assume this affects how it configures timerfd_settime
As far as I can see, expires_from_now() is implemented in terms of expires_at(), so there's no any difference. Igor'.
participants (2)
-
Avi Bahra -
Igor R