[time-nuts] Time stamping with a PICPET

Chris Albertson albertson.chris at gmail.com
Mon Oct 28 11:35:50 EDT 2013


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 <tvb at leapsecond.com> 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 -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California


More information about the time-nuts mailing list