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-arch" 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>