From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 11 08:38:01 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 C43AD1065670 for ; Wed, 11 Jul 2012 08:38:01 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5640D8FC18 for ; Wed, 11 Jul 2012 08:38:01 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge01.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 10:36:05 +0200 Received: from KNOP-BEAGLE.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 10:36:06 +0200 Date: Wed, 11 Jul 2012 10:36:27 +0200 From: Harti Brandt X-X-Sender: brandt_h@KNOP-BEAGLE.kn.op.dlr.de To: Peter Jeremy In-Reply-To: <20120711075044.GA10224@server.rulingia.com> Message-ID: References: <1341932588.6997.6.camel@albrecht-desktop> <20120711075044.GA10224@server.rulingia.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [129.247.178.136] Cc: freebsd-hackers@freebsd.org, Paul Albrecht Subject: Re: kqueue timer timeout period X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt 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 08:38:01 -0000 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? harti