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

alkopedia at googlemail.com alkopedia at googlemail.com
Wed Mar 25 20:46:11 UTC 2009


On Mar 25, 8:23 pm, mi... at udel.edu (David Mills) wrote:
> 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
>
> alkope... 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
> >questi... at lists.ntp.org
> >https://lists.ntp.org/mailman/listinfo/questions

Hi David!
Thanks for your suggestions. But there are several other problems :-)
1+2. The hardware I'm using was provided as it is and it consists of
Soekris net4501 embedded boards with only one PCI and one serial port
(no parallel port). The GPS and DCF77 receivers are Meinberg PCI
cards, which provide a Linux kernel driver and the ntpd can directly
use them with the reclock_meinberg driver. Therefore I've chosen Linux
as OS.

2. I don't use any level converters. The MAX3243C rs232 chip seems to
handle TTL levels fine. In the last 12 hours the offset to PPS was
between -5 and +5 microseconds.

Except for the PPSTIME issue the setup is working quite well, but I
have to check out the tos mindisp settings you've mentioned.

The complete system doesn't serve time to others. It's intention is
monitoring. I'm building this as a diploma thesis for a
telecommunication company. They have a large number of ntp servers
with GPS receivers (called SSU) across the country. So my system only
watches the offsets, that these SSUs have to assure that they are OK.

I'm not sure about symmetric mode. I guess this means to use the
"peer" option. Do you think it's a good idea to use peer between the 2
monitors? At the moment they work independent from each other. They
are doubled for the case that one of them breaks down.

Just for your information about LinuxPPS. Today I got response from
their mailing list:
"Kernel discipline has been talked about on the list before.  It is an
optional
part of the specification and is currently not part of LinuxPPS.
Right now I
think the goal is to get the basic PPS stuff into the kernel and then
to work
at adding enhancements like kernel discipline.

In addition to basic PPS support PPSKIT had kernel discipline along
with
nanokernel capabilities.  Unfortunately it never made it into the
kernel.
Perhaps because it was too ambitious.   Current kernels are now
nanosecond
capable and there is a possibility that basic PPS capabilities will be
part of
the kernel sometime soon since the LinuxPPS patches were considered
for
inclusion in 2.6.29 and there has been some work done to correct the
issues
that prevented inclusion.  Since it appears that this needs to be
added to the
kernel in small incremental steps perhaps the right thing to do would
be to
have a separate patch set for enabling kernel discipline so that work
on
getting basic PPS into the kernel can go forward unimpeded."

Greetings,
Thorsten




More information about the questions mailing list