[ntp:questions] reference clock, shm and ntpd

juergen perlinger juergen.perlinger at t-online.de
Tue May 24 23:16:02 UTC 2016


On 05/24/2016 11:27 PM, Stuart Maclean wrote:
> Back in January of this year, I posted my ntp scenario to this list:
> 
> http://lists.ntp.org/pipermail/questions/2016-January/040609.html
> 
> I never got a reply I could understand.
> 
> I am now revisiting the issue of using ntp to read from a shm segment,
> using driver 28.  I populate that shm segment using a daemon of my own,
> call it D, thus:
> 
> every 10 secs, my daemon D reads 'whole secs since the epoch' from a
> special hardware clock, call it HC.  My daemon also reads PPS events
> from that same clock (imagine it being like a GPS device, it can output
> a PPS and a NMEA-like string containing a timestamp).  I wrote a kernel
> device driver which sees the PPS as an interrupt on a GPIO pin and grabs
> system time and returns that as the read result of the PPS 'device' to
> daemon D.
> 
> So my daemon gets a time value from the hardware clock AND a local Linux
> system time.  I use these two to populate the fields of a single SHM
> struct which I write and NTP then reads.
> 
> My ntp.conf is thus:
> 
> server 127.127.28.2 minpoll 4
> fudge 127.127.28.2 refid HC
> 
> Things are kind-of working. I know without use of ntp, my system clock
> would drift from the HC time value.  It would tick slow, and the drift
> is significant, seconds per hour.
> 
>  ntpd is getting my Linux system clock to stay within 25 ms of the HC
> reference time, but never any nearer.  ntpq -p reports an offset of
> 25-26.  My daemon D also reports the time grabs it gets from HC and
> system time at time of PPS, and it too reports a discrepancy of 25ms.
> 
> I do not understand this 25ms 'barrier'?  Anyone enlighten me?
> 
> I suspect I am not using ntp correctly, with respect to how it expects
> to use a PPS signal.  As I alluded to in my earlier email, our system is
> a legacy Linux 2.6.* kernel pre-dating linuxpps support.
> 

Other clock sources (in my case, the Meinberg service daemon) do *not*
have this issue, so I guess your suspicion is right...

Among the things that can go wrong I would check:

Is the clock time properly set? Assuming you get your PPS pulse at the
start of a new second, both 'clockTimeStampUSec' and
'clockTimeStampNSec' should be zero.

Is 'receiveTimeStampUSec' the truncated result of dividing
'receiveTimeStampNSec' by 1000?

Is the precision field set to something that mirrors the precision of
the PPS signal? If you have 1usec accuracy, 'precision' should be set to
-20.

'leap' should be zero, but I guess you have that, or you would
experience other strange things.

(Note: I have a tendency to mess up the meaning of clock time and
receive time... If in doubt, switch the roles and see if my writing
makes more sense then.)

Oh, another thing that can go wrong: Do you sample the right edge of the
PPS pulse?

I guess you went over your code several times already, so I guess the
time stamps themselves are OK. Which leaves the other things to check.

Thinking about it, the PPS edge that gets evaluated becomes my prime
suspect, but since I don't have details about the hardware I cannot
validate or dismiss that suspicion. (While the trailing edge is not as
stable in timing as the leading edge for most receivers, the PPS pulse
width is stable enough to give you a pretty constant offset...)

And my apologies if you have already checked these issues.



Now, why do some clock sources insist in feeding two clock units, one
for PPS and one for the serial data stream?

Some people consider them being two clocks that are actually unrelated.
I don't want to start a flame war here, so let's just say that's one way
to see it. Other GNS based time sources just use one channel, and IMHO
cause less trouble for NTPD and the programmer. So you should be
perfectly fine with one SHM channel... provided you do the proper error
handling when the sat signal deteriorates, like stopping to feed the SHM
slot with dubious / untrustworthy time stamps.


Cheers,
	Pearly



More information about the questions mailing list