[LinuxPPS] PC Clock Offset

[Hal V. Engel]

On Thursday 11 June 2009 05:03:26 pm Bernhard Schiffner wrote:
> On Friday 12 June 2009 00:47:07 Andrew Hills wrote:
> ...
>
> > Can I assume the "DELAY 25.0 ns" line in my ntp.oncore.0 configuration
> > file compensates for the cable delay? How could I go about measuring and
> > compensating for the PPS interrupt handler latency?
> >
> > --Andrew Hills
>
> Yes you can assume so.

This is to tell the GPS how much delay there is in the antenna feed line so 
that it knows how far (time wise) it is from the antenna.  The general rule of 
thumb is to allow 5ns/meter of cable.  But the actual feed line delay will 
depend on the cable type.  The cable specific propagation delay can be looked 
up on-line and is easy to find if you want to use something more exact than 
the rule of thumb estimate.

To compensate for delays and latencies between the PPS pulse and the actual 
point when the time stamp is captured by the PPS interrupt handler you would 
use the fudge time1 setting in /etc/ntp.conf.   This sets a calibration offset 
that is used by NTP.

The factors being compensated for with this could include things like delays 
added by level converters (perhaps 15ns to 30ns if you are using one) or 
inverters (perhaps 10ns per stage), serial line propagation delays (about 
3.5ns/meter), the serial port itself (again perhaps another 15ns to 30ns) and 
the PPS interrupt handler latency.   The only one of these that would be 
difficult to measure or estimate with some level of confidence is the last one 
and it is by far the biggest factor (several microseconds) and dwarfs all of 
the others combined by perhaps 2 orders of magnitude.  In addition the 
interrupt latency is variable depending on the activity of the system at any 
given point in time.   Using a real time kernel and setting the serial 
interrupt handler to the highest priority on the system may reduce the 
variability of this to some extent. 

As Bernhard points out below about the best you can do with this on most 
systems is to estimate (guess would be more correct) something that is close 
to the average of all of these factors and hope that you are close.  I don't 
think most LinuxPPS users have done this since it is at best difficult to get 
good numbers to work with and the most that can be expected is to improve your 
clocks actual time keeping accuracy by perhaps 2us to 3us.

>
> A useful measurement is only possible in your host can generate an output
> signal.
> (I have no idea how to perform such a check in a good way. If you don't
> measure an interupt line directly there will alwayse be delays by
> software.)

I notice that newer kernels do have some latency tracer functionality in:

kernel hacking --> tracers

Would any of these be able to provide useful information?  I notice that these 
only have microsecond resolution however.

>
> After such a hyptheticval measurement you assume that "somewhere in the
> middle" is the time of interest.
>
> ntpd is by no means designed to enable measurements or verification. It
> only states about some computations.
>
> You can estimate some _improvements_ of latency if you change something in
> software. But it's (with x86 architecture) quasi impossible to "align"
> hard- and software.
>
>  :-(
>
> Bernhard
>
>
>
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support