[ntp:questions] Stick to PPS, even if the prefer server fails

David Mills mills at udel.edu
Wed Mar 25 19:23:47 UTC 2009


alkopedia,

We do something like that here with two GPS receivers and two busy servers. However, we assign one GPS receiver and PPS signal to each server. In your case, you want to duplex the receivers and PPS signals. Suggestions:

1. Immediately fire the Linux OS and replace with FreeBSD. It has PPS support ex box and very good serial drivers. You need to disable the hardware/driver FIFOs to get good serial time. This of course will be secondary to the PPS.

2. Use the parallel printer port rather than a serial port for the PPS. This avoids a level converter and hardware slew delays, as well as the control-lead state machine of the serial driver. Expect time within a few microseconds with the PPS.

3. Configure two serial drivers and one PPS driver for each server. Mark both seral drivers as preferred for both server. The mitigation algorithm will choose the first selectable prefer peer it finds, so reverse the order of the serial drivers in each configuration file. 

I think this configuration matches what you intend in your diagram. If you lose one or both GPS/DSF77 sources, the PPS signal will still wind the clocks. If you lose the PPS, the timing quality will follow the serial ports.

By sure to increase tos mindisp to something that avoids the intersection problem. I imagine 10 ms would be enough, depending on the performance of the GPS and DCF77 receivers.

I don't know how you feel about additional backup, such as running symmetric mode between the servers as we do. NIST doesn't want to do that on the basis that a failure of one NIST server should not result in delivery of stratum-2 time. They argue selection of redundent servers should be done by the clients. 

Dave



alkopedia at googlemail.com wrote:

>On Mar 24, 10:29 pm, mi... at udel.edu (David Mills) wrote:
>  
>
>>alkopedia,
>>
>>Your PPS signal is working, but not necesarily discipining thekernel. I
>>can't help you with Linux.
>>
>>Dave
>>    
>>
>
>Thanks for your help anyway. The PPS is working, that's right. But let
>me explain my setup more detailed:
>I've got to machines, called monitor201 and monitor202. Both are
>connected to a cesium frequency standard PPS (which is synced to UTC
>because it is part of BIPMs UTC calculation progress).
>both monitors get their prefer timestamps from another 2 machines:
>gps201 and dcf201 (which get their time by GPS and DCF77).
>My problem is as follows: assumed gps201 and dcf201 will get down or
>get wrong times by GPS/DCF77 at any time in the future, I want my
>monitors still be synced to PPS (because this one has guaranteed UTC
>time). Here is a picture for better understanding:
>http://img-up.net/img/ntpmoni-pu5NrlP.png (red: PPS)
>In other words: On the long run I want to trust the cesium more than
>GPS/DCF77 timestamps.
>
>If I've understood you right, this would be possible with the PPS
>kernel discipline?
>
>status 0x2001 (PLL,NANO) means that the kernel even doesn't see a PPS
>signal to use for discipline. After searching the LinuxPPS mailing
>list this seems to be some kind of bug, so I'll try to ask there
>again.
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>




More information about the questions mailing list