On 2010-04-14, Chuck Swiger <[email protected]> wrote: > Hi-- > > On Apr 14, 2010, at 9:08 AM, David J Taylor wrote: >> I think you are correct in your final statement, but my understanding >> (albeit limited) is that kernel PPS provides better performance, and is used >> for a very limited set of operations (possibly just timestamping the PPS >> signal). All the filtering /is/ done in user-land. It isn't a pain to do, >> once you have found the appropriate two or three command-lines for your >> system. > > 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. > > 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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
