On 2010-04-15, Chuck Swiger <[email protected]> wrote: > 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.
No I meant serial or parallel port interrupts. The standard drivers for these will process the interrupts and you can time stamp them. Or you can write a module for, say, the parallel port whose purpose is to time stamp the receipt of the PPS signal. I am not talking about a NIC (not sure how you would sent a PPS signal to a NIC. Modules can be compiled without compiling the kernel-- a lot lot easier to do. > > 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. But there are kernel calls (gettimeofday, adjtimex,...) which will access precisely those needed aspects of the kernel. I am not arguing that the kernel should not have any timing functions in it, just that PPS handling need not be there. > > 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 Interesting. > > Regards, _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
