Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Dec 2002 10:06:16 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Stijn Hoop <stijn@win.tue.nl>
Cc:        Mike Silbersack <silby@silby.com>, freebsd-hackers@freebsd.org
Subject:   Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
Message-ID:  <3DEE4418.868B4936@mindspring.com>
References:  <20021202151816.GJ83264@pcwin002.win.tue.nl> <20021202114019.R31106-100000@patrocles.silby.com> <20021204113154.GA205@pcwin002.win.tue.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
Stijn Hoop wrote:
> On Mon, Dec 02, 2002 at 11:49:03AM -0600, Mike Silbersack wrote:
> > The time select() takes should be directly related to your system's hz
> > setting.  The default for FreeBSD is 100, which means that the interrupt
> > timer will fire every 10ms.  If you want to play with that, edit
> > /etc/sysctl.conf and set kern.hz="1000", which should give you 1 ms
> > accuracy.
> 
> With the mentioned change of /etc/sysctl.conf to /boot/loader.conf, I am
> indeed seeing much better times on this 'benchmark'. See attached log. Not
> only the _select_sleep method benefits from this. What are the reasons *not*
> to do this?

Increased context switch overhead.


> > As to why Linux may appear "better"... I believe that Linux defaults to
> > hz=100, but that the default switched to hz=1000 sometime in the recent
> > past.
> 
> And why don't we do the same? (I suspect this is related to the question
> above :)

Increased context switch overhead.


> > To answer your final question:  Sleep accuracy doesn't matter to most
> > applications, but I'm sure counterexamples could be found.
> 
> Such as emulators :)

Actually, for the case you are talking about, your emulator should
be using aggregate instead of discrete timeouts, and you would not
be having a problem.  It's not useful to do 100 1ms timeouts to
achieve a  100ms timeout, when you can ask for a single 100ms
timeout.  I would count this as a bug in your emulator.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DEE4418.868B4936>