On Apr 14, 2010, at 2:15 PM, unruh wrote: > On 2010-04-14, Chuck Swiger <[email protected]> wrote: >> >> The main point seems to be that a PPS signal should have much more reliable >> latency and less jitter, so when you examine the current clock and any >> adjustment, you can use the PPS signal offset instead of the offset being >> provided to adjtime() and get better results, assuming the clock is already >> relatively close to accurate time. [1] > > ??? Interrupt processing on say a serial or parallel interrups is in the > 1usec regime. HOw much better are you claiming that the kernel PPS is? > Seems to me it uses exactly the same serial or parallel interrupts.
Kernel PPS_SYNC discipline is capable of providing around +/- 120 nanosecond accuracy. While an ethernet packet containing NTP timestamps might well fire off an interrupt from the NIC, not only is the network ISR a lot more complicated and slower than fielding an interrupt from the serial or parallel port, there's also no guarantee that ntpd running in userland will immediately receive and process this information. For another thing, modern NICs tend to do some degree of interrupt mitigation, which adds delay. If that's not what you meant, I'm forced to admit that whatever you're saying is confusing me. :-) >> Search for PPS_SYNC in: >> >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_ntptime.c?rev=1.64.2.1.6.1 >> >> ...especially hardpps(). > > It looks like he tries to impliment the FLL or PLL loops in kernel > space, which is really not clear to me that it belongs there. Once you > have the timestamped PPS input, there is no need to do the rest of the > calculation in kernel space. If you need to be in the kernel to have access to your local clock hardware, whether it be ACPI, HPET, 8254, or some other architecture's mechanism [1], and you care enough about timekeeping precision to try and make sure you've got valid clock data (ie, you test that the clock data is monotonically increasing when you read it), then you might conclude it makes sense to deal with your high-precision timing in just such a context. For the sake of reference, here's some data PHK measured some years back for the time required to read various clock sources: TSC ACPI-fast HPET i8254 dual Xeon: 580 nsec 1429 nsec 1120 nsec 3980 nsec dual Opteron: 212 nsec 1270 nsec 1760 nsec 4420 nsec Regards, -- -Chuck [1]: HPET should be userland-visible (if you have it, your BIOS makes it available and ACPI maps it into memory which is exposed to userland), and there's also rdtsc(), but if it's not power-state invariant (and sync'ed between CPUs on SMP boxes), you're more likely to obtain remarkably inconsistent results than useful timing from it. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
