The reason people are not working on improving what you list as #1 is that the NTP server's job is to transfer time over the network to to other computers also running NTP. The network limits time transfer accuracy to around one millisecond at best so it dose not good to use schemes better than #1.
OK, you can transfer time over a network better then 1 mS but it requires special network equipment that can time stamp the packets, that is not a general purpose solution because few people have this equipment. Your #3 works. Ive seen it doe a few times but it is not dramatically better then #1, from memory a factor or 2 or 4 is gained. The trouble is the clock resolution, few clocks actually count nanoseconds. One other idea. In the Linux kernel when ever the time is needed it calls a function that eventually call does "time = cs->read();" In other words the read function is placed into a structure and can be changed at any time while the system is running. So Linux has installable clock sources. Why not build a clock source that does not need NTP to set its rate Use a GPSDO or even a primary standard as the clock source. I've looked at the code and it's simple, more comments and function headers than "real code". You'd still need NTP to set the absolute time but the rate would remain dead on even if you stopped the ntpd process. On Sun, Oct 27, 2013 at 10:58 PM, Tom Van Baak <[email protected]> wrote: > > On most CPU architectures, the low level hardware has a register that > counts on the CPU clock. > > Merely counting the CPU clock is only half the requirement. Reading the > clock precisely when an external event occurs is the other half. > > In my mind, there are three levels of NTP precision: > > 1) The traditional scheme, in use for decades, where a PC uses interrupts > (e.g., DCD) and OS s/w acts as a crude time interval counter. This is quite > limiting, but Dave Mill's worked with what he had, and it's far better than > nothing. > > 2) The external h/w capture/counter scheme, which is what any external > time interval or time-stamping counter can provide. By using external h/w > instead of internal s/w you get a precise, low-jitter time comparison at > every pulse. The OP was talking about the picPET, a sub-microsecond $1 > time-stamping counter. But you can use a $1000 HP sub-nanosecond time > interval counter if you prefer. > > 3) An internal h/w capture/counter scheme, which is what the latest crop > of SBC offer. Here, not only is the counter tied to the CPU clock, but > timestamping is pure h/w, so all problems with s/w and latency and jitter > are removed from the equation. This is the ideal solution, not unlike how > any GPSDO is designed. > > In my mind, the modern SBC architectures with single CPU clock source > (could be OCXO or atomic), and real GPIO pins (instead of serial or USB > ports) and a native h/w capture/compare register should allow NTP to work > at the 10 to 100 ns level. If any of you could verify this, it would be > time-nut worthy. > > /tvb > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
