[time-nuts] Raspberry Pi NTP server

[Tim S]

This'll be my last chime-in on this topic...

    The problem here is that the interrupt of 125uSec to check for state
change is in software.  The 1PPS transition that you'd want to measure the
jitter of is in hardware.  Doing this experiment would require the same
hardware being recommended to to direct HW interrupts - i.e., a system with
exposed low-level GPIO pins that directly trip an interrupt in the host OS.

I'm not sure if it's being grasped that what is being talked about here is
the difference between push and pull.  With a low-level GPIO, it is pushing
an event into the system when it happens.  For USB polling - it is pulling
new events in when it has time to check.  Think of GPIO like yanking a rope
tied to the CPU's wrist every time it wants attention.  USB's handler is
something like turning the faucet on, and the CPU is checking every once in
a while to see if the glass is overflowing before turning off the tap - the
USB interrupt handler knows there is something it should pay attention to
(starting a watch event poll), but it doesn't control the volume of the
glass or the fill rate from the faucet. "...Nope not full, nope not full,
nope not full, OMG it's overflowing!..."

The big reason this is so variable is that USB is based on sharing PC
time.  It's designed to let the PC do what it wants for a while then fires
an asynchronous interrupt to check state.  Conversely and low-level GPIO is
designed to forgo the asynchronous interrupt timer and only call when the
state changes (and in most platforms, one can configure which state
transition to watch for).  Tuning a measurement PC with an real-time GPIO
will get you down to <=10uSec - which would give you about 4-bits of
fractional resolution for the jitter/lag measurement on the 125uSec USB
interrupt timer.

By hand tuning an embedded computer like a RaspberryPi, so that only the
interrupt handler for the 1PPS GPIO runs on one of the four cores - this
makes the loop size ridiculously small (only a few instructions).  With a
short loop size, all it has to do is pause until an interrupt occurs, then
when it occurs copy the tick time to a register (stack push), signal a new
edge to a thread running on another core (set a flag bit), then go back to
the paused state waiting for the next edge.  Even with a CPU idle speed of
600MHz, and assuming a very large 4 clocks cycles per instruction (most
commands in A72 cores of this nature would be single cycle instructions) -
that's a maximum loop interrupt-trigger-to-interrupt-waiting of 6.666nSec.
That would be about a bit more than 16-bit counter worth of time to the
125uSec USB interval timer.

The topic of idle CPU speeds does remind me of another impact of
latency/jitter... not very many PCs are fixed clock by default any more.
This can/should be changed on a time-critical/jitter-sensitive machine...

-Tim


> Date: Wed, 15 Jul 2020 05:59:12 -0700
> From: Hal Murray <hmurray at megapathdsl.net>
> To: Trent Piepho <tpiepho at gmail.com>
> Cc: Discussion of precise time and frequency measurement
>         <time-nuts at lists.febo.com>, hmurray at megapathdsl.net
> Subject: Re: [time-nuts] Raspberry Pi NTP server
> Message-ID:
>         <20200715125912.4E42240605C at ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
>
>
> tpiepho at gmail.com said:
> > It seems like it would not be that hard to get the USB frame sequence
> phase
> > locked to the system clock.  One would need a way to measure the phase
> offset
> > of the USB S-o-F vs the system clock, and then it's a standard process to
> > phase lock, with the necessary control to do this described above.
>
> The catch is that getting the frame lined up doesn't provide you with any
> info
> about the offset.  (I'm assuming we have something like a RS-232 to USB
> setup
> with the PPS signal connected to one of the modem control signals -
> Carrier
> Detect is the most popular.)
>
> If you have a knob to slew the phase of the USB signal, and things are
> stable,
> you could move the USB signal so that it is exactly lined up.  Then noise
> in
> the system would make half the samples come up "no" and the other half
> come up
> "yes".  That probably depends on something like the noise being large
> relative
> to the stability of the system.  (You could add artificial noise.)  If
> things
> aren't that stable, you can steer the USB timing back and forth to bracket
> the
> PPS signal.
>
> It all seems much simpler to put a counter in the USB device to measure
> the
> time between the PPS and the poll.  That actually sounds like a fun hack.
> Does anybody have a favorite dev board with a CPU and USB that would be
> appropriate for doing that?
>
> --
> These are my opinions.  I hate spam.
>
>