[LinuxPPS] Ultimate time server

[Javier Herrero]

El 29/12/2010 07:04, Paul Lavender escribió:
>
>
> What originally led me to this project was working in a not particularly
> demanding job away from home, giving me with too much time. My home
> server is using an Oncore at the moment which is continually locking up.
> A restart of NTP will get it going again, but it is a bit irritating to
> log in and find the stratum has gone to freerunning. So the plan was to
> lock a Rubium to the GPS, then to 'freerun' on the Rubium if necessary.
>
I see that you're lucky (free time) and not (away from home...). I think 
that you should first the reason why the ntp is unlocking. There should 
be some reason why the ntp stops to get the GPS pps/data or starts 
rejecting it, and I don't think that this is due to instabilities on the 
computer clock.

You can also try to use a Trimble Thunderbolt instead of a Rb. The 
thunderbolt will provide you also a pps output, a 10MHz signal 
disciplined to the GPS, with good short-term stability and excellent 
long term stability. The PPS output is derived from the 10MHz oscillator 
and has less jitter that a GPS pps output. I think that the serial data 
format is supported by ntp current implementation (not sure about). And 
an used Thunderbolt is in the price range of an used Rb.

But you can discover that you could continue having the same problem, 
that ntp unlocks.

I've another ntp server, based on a Blackfin board, an M12T oncore and 
an older linux version (previous to the LinuxPPS introduction on the 
main stream, so I manually patched the blackfin uClinux distribution at 
that time - about two years ago), that uses a not too spectacular TCXO 
as the clock source (about 2ppm error), and it shows no problem. It has 
accumulated uptimes well over 250-days and the only thing I don't like 
is that offset (as shown with ntpdc/ntpq) slowly wanders up to +/-4 
microseconds or so. This GPS has the antenna very unobstructed, located 
in the roof.
> As to the motherboard I am not afraid to get out my trusty soldering
> iron. I know less sophisticated processors have two pins - crystal in
> and crystal out. If the crystal is removed a clock can be fed into the
> crystal in pin. But I'll try to get other bits working first.
>
To replace the crystal with a precision oscillator is an effort to get 
ultimate precision. But even stratum 1 severs from national laboratories 
usually do not use them. For example, this is from the Real Observatorio 
Astronómico in Spain, hora.roa.es

ntpdc> kerninfo
pll offset:           -1.49e-07 s
pll frequency:        9.717 ppm
maximum error:        0.000877 s
estimated error:      0 s
status:               2107  pll ppsfreq ppstime ppssignal nano
pll time constant:    4
precision:            9.09e-07 s
frequency tolerance:  496 ppm
pps frequency:        9.717 ppm
pps stability:        0.026 ppm
pps jitter:           1.006e-06 s
calibration interval: 64 s
calibration cycles:   227999
jitter exceeded:      166274
stability exceeded:   6877
calibration errors:   10
ntpdc> peers
      remote           local      st poll reach  delay   offset    disp
=======================================================================
*GPS_ONCORE(0)   127.0.0.1        0   16  377 0.00000 -0.000000 0.01558
ntpdc>

And this from time.nist.gov

ntpdc> kerninfo
***Warning changing to older implementation
pll offset:           0 s
pll frequency:        -132.857 ppm
maximum error:        0 s
estimated error:      0 s
status:               0000
pll time constant:    10
precision:            0 s
frequency tolerance:  496 ppm
ntpdc>

The first one has a pll frequency of 9.717ppm and the second one is 
-132.857ppm (not a very good oscillator...). Of course, it is more 
important to have an stable source than an accurate source in this 
application (i.e. the absolute error is not so important since the GPS 
compensates it, but the drift can introduce an error since ntp is not 
particularly fast in compensating it.

I think that these two systems are using FreeBSD, not Linux.

Best regards,

Javier