On Wed, 11 Jul 2012, Peter Jeremy wrote: PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht <albre...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
