Timer resolution is half what it should be. #126
Comments
|
Could it be: http://dpc.pw/mioco/mioco/fn.sleep.html "Warning: When issued inside of mioco, the precision of this call (and other time based functionality) is limited by mio event loop settings. Any small value of time_ms will effectively be rounded up to mio_orig::EventLoop::timer_tick_ms()." ? |
|
Default |
|
I think it's a combination of the above and #31 |
|
Ah, that's it. I checked the docs for Timer, but not sleep >_< So it looks like the only way to have arbitrary precision timers is using |
|
Actually, perhaps this should be kept open as a documentation issue? |
|
You can create a Mioco instance with arbitrary settings using http://dpc.pw/mioco/mioco/struct.Mioco.html#method.new_configured
Also, I'm keeping this issue open as there is still something wrong. default tick is 100ms, while in mioco the timer is firing in 200ms. |
|
Also, I should fix the documentation, yes. |
|
Yeah, the precision seems to be half of what it should be, setting As for the arbitrary precision thing, I was just reading the mio code wrong, I though EventLoop::io_poll would time out on every tick, rather than just on those with timers set, which would make large timers with high precision expensive... It's too early for this :3 |
lhallam
changed the title
|
A 100ms timer using mioco: (https://gist.github.com/xalri/c3ff520c2a0da24eb1b446e9fa3b64b2) A 100ms timer using just mio: (https://gist.github.com/xalri/6dd14b0ddcbec85778be9e54845839e5) So, if I'm reading it right, in the mioco timer mio inserts the timeout in the slot past where you would expect it to be?.. I'll have another look in the morning, I'm sure I can figure this one out. |
|
I did some similiar analysis, and for whatever reason even when mioco is calling If you have time, please try to figure out this one, I appreciate any help, since I'm very short on time. :) |
|
Any findings? I might look into it during weekend. |
This might be part of it, there's an offset between the eventloop starting and the timer being set, mio rounds up to 2 ticks, otherwise it would be firing early. So it would make sense for the first timer to fire after 200ms, but then:
.. it doesn't fire for 300ms. Mio just seems to skip the tick with the timeout. https://github.com/carllerche/mio/blob/master/src/timer.rs#L202 At the end of the first https://github.com/carllerche/mio/blob/master/src/timer.rs#L69 (called by https://github.com/carllerche/mio/blob/master/src/event_loop.rs#L320) let nxt = self.start + (self.tick + 1) * self.tick_ms;.. this gives the time at the end of self.tick, skipping the actual time it should trigger. I tried changing tick_to so that it wouldn't advance |
Well that was easy, all you need is the offset between creating and starting the event loop: #[macro_use] extern crate log;
extern crate mio;
mod logger;
use std::time::Duration;
use std::thread;
struct Timer;
impl mio::Handler for Timer{
type Timeout = ();
type Message = ();
fn timeout(&mut self, evl: &mut mio::EventLoop<Timer>, t: ()){
info!("got timeout");
evl.timeout((),Duration::from_millis(100));
}
}
fn main() {
logger::init().unwrap();
info!("starting timer");
let mut event_loop = mio::EventLoop::new().unwrap();
std::thread::sleep_ms(10);
event_loop.timeout((),Duration::from_millis(100));
event_loop.run(&mut Timer{});
}The first timer takes 300ms, the rest 200ms. So am I missing something or is this a bug in mio? |
|
Last time I checked it looked like a mio bug, yes, but I wanted to double check before blaming mio. :D Could you report and explain it to mio authors? They are really nice people too. :) |
This is a strange one. Timers seem to work in 200ms intervals, between 1 and 200ms it's always rounded up to 200ms, after that it's the closest 200ms interval.
Here's a test comparing
std::thread::sleep_msandmioco::sleep_ms(which uses timers):And the results in a table:
I'm looking into this, I'll post if I find anything interesting ^^
The text was updated successfully, but these errors were encountered: