granularity of gettimeofday()
The manual says the granularity of gettimeofday() is hardware dependent. The time may be updated continuously or in clock ticks. Can anyone explain for me the two different ways of updating the time? What kind of hardware can help? Thanks for your help. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
In message Pine.SOL.4.21.0011031156050.29568-10@jade, Zhiui Zhang writes: The manual says the granularity of gettimeofday() is hardware dependent. The time may be updated continuously or in clock ticks. Can anyone explain for me the two different ways of updating the time? What kind of hardware can help? You probably need to tell me what you need first... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
On Fri, 3 Nov 2000, Poul-Henning Kamp wrote: In message Pine.SOL.4.21.0011031156050.29568-10@jade, Zhiui Zhang writes: The manual says the granularity of gettimeofday() is hardware dependent. The time may be updated continuously or in clock ticks. Can anyone explain for me the two different ways of updating the time? What kind of hardware can help? You probably need to tell me what you need first... This is actually a question from the book "Kernel Project for Linux" and I am a TA for an operating system course that uses this textbook. I know a little bit of NTP and Intel Time stamp counter. I need an authoritive answer for this question because I do not have the time to go through the FreeBSD code to find out myself in a short time. My impression is that if the time is updated by an interrupt handler per tick, it can not get a microsecond granularity. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
* Zhiui Zhang [EMAIL PROTECTED] [001103 10:08] wrote: On Fri, 3 Nov 2000, Poul-Henning Kamp wrote: In message Pine.SOL.4.21.0011031156050.29568-10@jade, Zhiui Zhang writes: The manual says the granularity of gettimeofday() is hardware dependent. The time may be updated continuously or in clock ticks. Can anyone explain for me the two different ways of updating the time? What kind of hardware can help? You probably need to tell me what you need first... This is actually a question from the book "Kernel Project for Linux" and I am a TA for an operating system course that uses this textbook. I know a little bit of NTP and Intel Time stamp counter. I need an authoritive answer for this question because I do not have the time to go through the FreeBSD code to find out myself in a short time. My impression is that if the time is updated by an interrupt handler per tick, it can not get a microsecond granularity. Gettimeofday will force a check of the system hardware, basically you should get better than 100HZ resolution with gettimeofday. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
The time may be updated continuously or in clock ticks. Can anyone explain for me the two different ways of updating the time? What kind of hardware can help? You probably need to tell me what you need first... This is actually a question from the book "Kernel Project for Linux" and I am a TA for an operating system course that uses this textbook. I know a little bit of NTP and Intel Time stamp counter. I need an authoritive answer for this question because I do not have the time to go through the FreeBSD code to find out myself in a short time. My impression is that if the time is updated by an interrupt handler per tick, it can not get a microsecond granularity. The short answer is: FreeBSD returns a continous timescale. 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. The frequency model operates at a similar resolution. A timestamp is based in the current value of a chosen hardware counter at the time you ask for it, we don't rely on interrupts to tell us what time it is. Experiments in the lab have proved these claims to be true for currently available hardware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
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 ? 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. Joerg -- Joerg B. MicheelEmail: [EMAIL PROTECTED] WAND and NLANR MOAT Email: [EMAIL PROTECTED] The University of Waikato, CompScience Phone: +64 7 8384794 Private Bag 3105Fax: +64 7 8585095 Hamilton, New Zealand Plan: PMA, TINE and the DAG's To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
Cc'ed to arch because of it's hopefully informative contents. In message [EMAIL PROTECTED], 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 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
In message [EMAIL PROTECTED] Alfred Perlstein writes: : Gettimeofday will force a check of the system hardware, basically : you should get better than 100HZ resolution with gettimeofday. gettimeofday on many systems do this. There are other, older systems that do not have a high resolution clock to read and rely on timer interrupts to update the clock. These systems limit their gettimeofday reports to 10ms + a "uniqifier" that means two calls to gettimeofday in a row don't get the same value. On FreeBSD, we go ahead and read the timer hardware so you aren't limited to 1/HZ increments. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: granularity of gettimeofday()
Poul-Henning Kamp wrote: 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. We need to write benchmarks that place heavy emphasis on these features, then. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] He has been convicted of criminal possession of a clue with intent to distribute. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
