Subject: Re: timing issue
To: None <netbsd-users@netbsd.org>
From: Chuck Swiger <cswiger@mac.com>
List: netbsd-users
Date: 11/19/2006 00:05:59
Christian Biere wrote:
> Jonathan A. Kollasch wrote:
>> On Sat, Nov 18, 2006 at 05:16:32AM +0100, lists@badzong.com wrote:
>>> Why is netbsd so inaccurate and is there a more precise system call or a
>>> workaround?
> 
>> Because FreeBSD 6.1 has timecounters. NetBSD 3.1 does not. You really want
>> to test this on netbsd-4 or -current, as timecounters were added since
>> the 3.x branches.
> 
> I think someone else wrote it but I can confirm it as well that the behaviour
> on -current is the same. This might not be the case for everyone of course.
> However, it seems you can't sleep less than about 15 ms.

What does everybody have their scheduler quantum set to (kern.hz or maybe 
kern.clockrate sysctl?) set to?

If HZ=100, it's possibly reasonable for the process to not be able to sleep 
and have the kernel return to the process in less than one quantum, aka 10 ms. 
  It might be the case that setting the scheduler to HZ=1000 will 
significantly improve the observed latency for this test.

Also, the OP might want to alter your code to try to sleep for enough time to 
get synced with realtime, and see how close you can get to waking up every 
second on the second.  Otherwise, perhaps consider the following:

   http://www.pkix.net/~chuck/Timer.py

[ You might want to pipe the output to a file to avoid delays caused by 
drawing to the screen; search for main() and change the stuff immediately 
after that for simple tweaking.  I can get +/- 1 ms with HZ=1000 on MacOS X & 
FreeBSD. ]

-- 
-Chuck