Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Nov 2000 19:56:55 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Joerg Micheel <joerg@cs.waikato.ac.nz>
Cc:        Zhiui Zhang <zzhang@cs.binghamton.edu>, freebsd-hackers@freebsd.org, arch@freebsd.org
Subject:   Re: granularity of gettimeofday() 
Message-ID:  <2017.973277815@critter>
In-Reply-To: Your message of "Sat, 04 Nov 2000 07:27:39 %2B1300." <20001104072739.K26626@cs.waikato.ac.nz> 

next in thread | previous in thread | raw e-mail | index | archive | help

Cc'ed to arch because of it's hopefully informative contents.

In message <20001104072739.K26626@cs.waikato.ac.nz>, Joerg Micheel writes:
>On Fri, Nov 03, 2000 at 07:21:21PM +0100, Poul-Henning Kamp wrote:
>> The long answer is: FreeBSD can deliver time with a resolution of
>> 1/2^32 nanosecond = 232.8E-21 seconds.   The actual resolution is
>> much worse, because the hardware usually doesn't provide any better
>> than about a nanosecond at best these days.  On certain hardware
>> only about a microsecond of actual resolution is available.
>
>Why could't gettimeofday be tuned to provide nanosecond resolution
>in reality, with the assistance of the TSC register ? 

You get access to the nanosecond resolution timestamps in 
userland with the clock_gettime(3) API.

>I understand
>this does not work on a 486, but that's not the platform people
>ask for such a resolution. With every celeron today exceeding 300
>MHz, 3 nanoseconds is a reality. Of course, there will be syscall
>overhead, understood.

I guess I need to explain it much more carefully:

We're can, and usually do, MUCH better than gettimeofday(), it all
depends on what hardware is available.

FreeBSD uses an abstraction called a "timecounter".  A timecounter
is a binary counter running at a fixed frequency.

Currently the following pieces of hardware can be timecounters
on the i386 platform:

	The CPU's TSC
		Frequency as fast as your CPU, ie, up to above a 
		GHz these days.  Resolution of timestamps will
		be 1/CPU clock, ie down to below 1 nanosecond.

	The i8254 on the motherboard.
		Runs at 1193182 Hz.  Resolution of timestamps will
		be 838 nanoseconds.

	The PIIX on newer chipsets
		Runs at 3579545 Hz.  Resolution will be 279 nsec.

	The loran timecounter.
		5 MHz, 200nsec.

	The xrpu timecounter.
		100 MHz, 10nsec.  This one can timestamp external
		events without interrupt jitter, ie: +/- 10nsec
		phasenoise on the timestamp.

Internal to the kernel, timestamps are operated on in a resolution
of nanoseconds with 32bit fractions, ie 232E-21 (= a 4 billionth
of a nanosecond), but current APIs only report in either nanoseconds
or microseconds.

The code in the kernel models the frequency of the hardware counter
to parts in 232E-21 (~= 1 second over the lifetime of the universe)
so it can more than adequatly model todays atomic standards.

I have proven that claim in my lab by using a FreeBSD system (with
the xrpu timecounter) to measure the phase and frequency offset of
a Cesium standard relative to GPS.  A HP5370B (20ps one-shot
resolution) was used as control instrumentation and the results
agreed well inside the theoretical window of uncertainty.

In other words, no matter what hardware you will throw at FreeBSD, 
it will be able to fully exploit the precision and resolution of
that hardware.

But the two *really* interesting things about the FreeBSD code is:

	You can change your timecounter on the fly.  This allows
	the machine to boot using maybe the TSC, then load the
	bitcode on the xrpu board, initialize the hardware on the
	xrpu and start to use that as the timecounter.

	If the hardware can be read atomically, no interrupt
	locking is used.  This means on a multi-CPU system you
	will not have block interrupts to figure out what time
	it is, in fact all CPUs can find out what time it is
	*at the same time*, without interferring with each other.

I belive those two features are unique to FreeBSD at this time.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


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?2017.973277815>