From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 14:36:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4563106566B; Wed, 11 Jul 2012 14:36:54 +0000 (UTC) (envelope-from paul@glccom.com) Received: from exchange.glccom.com (exchange.glccom.com [209.152.99.146]) by mx1.freebsd.org (Postfix) with ESMTP id 7BDC48FC18; Wed, 11 Jul 2012 14:36:54 +0000 (UTC) Received: from [192.168.10.27] (192.168.10.27) by exchange.glccom.com (192.168.10.5) with Microsoft SMTP Server id 8.3.83.0; Wed, 11 Jul 2012 09:27:40 -0500 From: Paul Albrecht To: Harti Brandt , Peter Jeremy , "freebsd-hackers@freebsd.org" In-Reply-To: References: <1341932588.6997.6.camel@albrecht-desktop> <20120711075044.GA10224@server.rulingia.com> Content-Type: text/plain Date: Wed, 11 Jul 2012 09:36:38 -0500 Message-ID: <1342017398.5984.18.camel@albrecht-desktop> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 14:36:54 -0000 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 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