Date: Wed, 11 Jul 2012 10:36:27 +0200 From: Harti Brandt <hartmut.brandt@dlr.de> To: Peter Jeremy <peter@rulingia.com> Cc: freebsd-hackers@freebsd.org, Paul Albrecht <albrecht@glccom.com> Subject: Re: kqueue timer timeout period Message-ID: <alpine.BSF.2.00.1207111029560.68527@KNOP-BEAGLE.kn.op.dlr.de> In-Reply-To: <20120711075044.GA10224@server.rulingia.com> References: <1341932588.6997.6.camel@albrecht-desktop> <20120711075044.GA10224@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Jul 2012, Peter Jeremy wrote: PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht <albrecht@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1207111029560.68527>