On Tue, Apr 21, 2015 at 2:53 PM, Andrius Bentkus <[email protected]> wrote: >> That doesn't have to be the case. Libuv would only use the timerfd >> when sub-millisecond precision is needed, and only in one-shot mode. > > The thing now is that if I create a timer with 1ms precision it will get > called ~930 times and not 1k(+-1) times. I think the nano second precision > is needed even if we only want precise millisecond precision. (look at the > node script i provided in the beginning of the discussion). The drift really > flat lines only at 5-6 ms (the % off is then to small to calculate based on > milli > seconds) > > I haven't run into an issue yet where I really need those 1k calls a second > ... but it would nice to have?
If I understand you correctly, you'd still get that drift with high-precision timers as long as you don't compensate for callback overhead. The timer fires every millisecond but wall clock time spent inside libuv and the callback causes it to shift. Without compensation, you are limited to 1000 / (1+overhead) events/second. Also, circling back to timer slack: with ~930 events, you stand to accumulate up to 930 * 50 / 1000 = 46.5 ms of slack. >> A potential drawback is that libuv, upon returning from epoll_wait(), >> may have to scan the events list for the timerfd first. If a number >> of normal callbacks run first, a high-resolution timer isn't much >> good. > > We feed the timerfd as the first into the epoll_event array and then it > is immediately always the first one when we are checking for the events? > Doesn't save us from scanning the entire event list? There is no way to control where in the ready list the kernel puts the timerfd. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
