Date: Wed, 11 Jul 2012 09:36:38 -0500 From: Paul Albrecht <albrecht@glccom.com> To: Harti Brandt <harti@freebsd.org>, Peter Jeremy <peter@rulingia.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: kqueue timer timeout period Message-ID: <1342017398.5984.18.camel@albrecht-desktop> In-Reply-To: <alpine.BSF.2.00.1207111029560.68527@KNOP-BEAGLE.kn.op.dlr.de> References: <1341932588.6997.6.camel@albrecht-desktop> <20120711075044.GA10224@server.rulingia.com> <alpine.BSF.2.00.1207111029560.68527@KNOP-BEAGLE.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2012-07-11 at 03:36 -0500, Harti Brandt wrote: > 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? > I don't think it has anything to do with realtime either. I've been using gentoo linux to run my application using timerfd_create/read for 20 millisecond timing without any problems. > harti -- Paul Albrecht
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1342017398.5984.18.camel>