kqueue timer timeout period

[Harti Brandt]

On Wed, 11 Jul 2012, Peter Jeremy wrote:

PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht <albrecht at glccom.com> wrote:
PJ>>I have a question about the kqueue timer timeout period ... what's data
PJ>>supposed to be? I thought it was supposed to be the period in
PJ>>milliseconds, but I seem to off by one.
PJ>>
PJ>>For example, if I set date (the timeout period) to 20 milliseconds, I
PJ>>often wait 21 milliseconds which is very undesirable for my application.
PJ>
PJ>FreeBSD is not a real-time OS.  The timeouts specified in various
PJ>syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll())
PJ>specify minimum timeouts.  Once the timeout (rounded up to the next
PJ>tick) has expired, the process will be placed back into the queue
PJ>of processes eligible to be run by the scheduler - which may impose
PJ>a further arbitrary delay.
PJ>
PJ>Periodic timers are somewhat better behaved:  Scheduler delays only
PJ>impact process scheduling after the timeout expires and the average
PJ>rate should be very close to that requested.

While it is certainly true that FreeBSD is not a real-time OS, this does 
not explain the timer problems. 2 or 3 month ago I did a simple test with 
select and poll: I observed a systematic error of about 3-5% of the 
waiting time. So when you wait for 20ms, you may get 21ms (if running with 
a low HZ value) because of rounding. But if you wait for 100s, you get 103 
or even 105s on a completly idle machine (all services disabled).

I think that this is not a problem with beeing non-realtime, but a problem 
with time-keeping. Shouldn't it be possible to do this better?

harti