Date: Wed, 2 Apr 1997 20:35:10 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: joe@pavilion.net (Josef Karthauser) Subject: Re: Internal clock Message-ID: <19970402203510.RR52594@uriah.heep.sax.de> In-Reply-To: <19970402123111.58518@pavilion.net>; from Josef Karthauser on Apr 2, 1997 12:31:11 %2B0100 References: <3340C326.6150@cybernet.com> <19970401151947.61221@pavilion.net> <19970401203429.XR37988@uriah.heep.sax.de> <19970402123111.58518@pavilion.net>
next in thread | previous in thread | raw e-mail | index | archive | help
As Josef Karthauser wrote:
> > RTFM clocks(7).
>
> I have read this, although I still wasn't too clear about the above.
> The fact that a system clock ticks in useconds doesn't mean that there's
> going to be an interrupt every usec.
You haven't read very carefully? :-)
o The scheduling clock. This is a real clock with frequency that
happens to be 100. It isn't available to applications.
o The statistics clock. This is a real clock with frequency that
happens to be 128. It isn't directly available to applications.
So this explains the basic clock tick rates. There are exceptions,
for example if profiling is active (tick rate 1024), or if a kernel
device driver like pcaudio(4) (man page yet to be written by Søren :)
raises the clock rate to 16000.
The resolution for gettimeofday(2) is much higher than the tick rate
of the scheduling clock since the values are interpolated.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970402203510.RR52594>