[ntp:questions] Leap second and refclock

Jon K Hellan jon.kare.hellan at uninett.no
Tue Jul 10 08:25:44 UTC 2007


We made a new refclock, which seems to be working well, but are not
sure what will happen when the next leap second comes along. Advice
would be appreciated.

Background: Our passive network monitoring computers use DAG
monitoring cards from Endace. These cards are GPS synchronized and
have a highly stable on board clock. This results in a very accurate
clock on the DAG card. To have a good clock on the rest of the
computer, we discipline NTP to GPS.

     _
    / \ GPS
     |                      Monitoring computer
     |        +---+        +-------------------------+
     +------+-|   |--------|Serial input             |
      RS-422| +---+ RS-232 |                         |
            |              |                         |
            +--------------|DAG monitoring card      |
                    RS-422 +-------------------------+

The configuration we have been using is shown above.  The GPS units
are Trimble Acutime 2000.  We are bringing RS-422 from the Trimble to
the DAG card, and RS-232 to the serial port. NTP uses the Trimble
Palisade refclock and talks the Trimble event stamping protocol to the
GPS.

For various reasons, we want a simpler setup. For one, Trimble seems
to have dropped the Acutime 2000. The successor, Acutime Gold, comes
with an RS-422/USB converter instead of the RS-422/RS-232 one. It is
also getting harder to find severs which have RS-232 inputs. Finally,
we would like to have fewer points of failure.

Fortunately, the host computer can ask the DAG card for its
clock status. What you get is a timestamp, and the count of the TSC
register when that timestamp was valid.

I wrote a refclock which polls the DAG card once a second, modelled
roughly after refclock_atom. It seems to work well. On the computer I
developed it on, estimated error converges to less than 4 us.  That's
a little bit better than the Palisade clock, and good enough for our
purposes.

One important difference is that my refclock doesn't provide a kernel
PPS signal. refclock_atom is designed to work with a prefer peer. The
PPS pulse defines the top of the second, whilst the prefer peer is
used to tell which second we're talking about. The prefer peer is
normally an NTP peer on the network.

Since my refclock doesn't provide PPS, I can't designate a prefer
peer. So what I do is wait until NTP is in synch before returning
anything from the refclock's poll method. But where refclock_atom.c
does this at the end of atom_poll:

	pp->leap = sys_prefer->leap;
	if (pp->stratum >= STRATUM_UNSPEC)
		peer->stratum = sys_prefer->stratum;
	else
		peer->stratum = pp->stratum;
	pp->lastref = pp->lastrec;
	refclock_receive(peer);
}

I do this:

	pp->leap = sys_peer->leap;
	if (pp->stratum >= STRATUM_UNSPEC)
		peer->stratum = sys_peer->stratum;
	else
		peer->stratum = pp->stratum;
	pp->lastref = pp->lastrec;
	refclock_receive(peer);
}

and once I'm in synched, that's asking myself for the leap
attribute. Is this where I would see a leap second? How should I solve
this? 

I guess I could hack the ntp core to treat my clock as a PPS
clock. But I would prefer to keep the core standard.

Anyway, essentially the situation is very similar to PPS. The DAG card has a
highly reliable top of the second indication. But I can't trust it to
know which second, since it got that information from me.

Jon Kåre Hellan
UNINETT, Trondheim, Norway




More information about the questions mailing list