[LinuxPPS] still some offset and jitter though using pps

[Hal V. Engel]

On Friday 17 October 2008 10:38:49 Nicola Berndt wrote:
> Good to see that it can reach that accuracy. I just need to find a way
> to get there quicker, since sadly out on the airport there will be no
> real time from our arrival til our start..
>
> Please have a nice weekend!
> ../nico berndt

Out of curiosity I spent some time looking into the issue with getting ntpd to 
quickly sync the clock after system start up.  I found that there is a command 
line argument you can set to cause ntpd to do an initial (very large if 
needed) step of the clock.  This is supposed to work with a local refclock.  
This argument is -g or --panicgate.  I couldn't get -g to work but --panicgate 
did.  But I am not sure why one worked and the other did not (probably a bash 
script syntax thing).  

Today I tested it from a cold start and my clock started out with an offset of 
18us.  Typically my CMOS clock will drift 400ms to 500ms overnight when the 
computer is powered down.   Before making this change I had been running 
ntpdate against an external ntp server before starting ntpd.  This would get 
my clock to with in 3ms when ntpd was started and the offset would be <50us 
with in an hour.  As part of this test I disabled running ntpdate so my clock 
was around 400ms to 500ms off when ntpd was started.

Using this argument ntpd will wait until it has a good refclock available and 
then make a one time adjustment to the clock to sync it with the refclock.  To 
make this work correctly your local (GPS) refclocks must be the only ones 
configured on the system.  Otherwise it will sync to one of the external 
servers since these will typically be available before the refclock drivers 
has initialized any of the local devices (my OnCore takes about 30 seconds to 
start working after ntpd is started).

I also noticed that the offset was somewhat unstable while the machine was 
warming up.  But it stayed =<28us during the warm up period for this test run.

Hal