[LinuxPPS] New LinuxPPS user intro

Thu Sep 18 09:20:17 CEST 2008

Thanks all for your notes, but the biggest culprit, DCD signal polarity, can be ruled out (forgot to mention that I had already researched this in my original message).  Here are my findings:

After a fresh reboot, after starting ppsldisc before running ntpd, ppstest yields these results:

tix ~ # ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1221714531.152534290, sequence: 28 - clear  1221714530.352296448, sequence: 27
source 0 - assert 1221714531.152534290, sequence: 28 - clear  1221714531.352586412, sequence: 28
source 0 - assert 1221714532.152821740, sequence: 29 - clear  1221714531.352586412, sequence: 28
source 0 - assert 1221714532.152821740, sequence: 29 - clear  1221714532.352877215, sequence: 29
source 0 - assert 1221714533.153112543, sequence: 30 - clear  1221714532.352877215, sequence: 29
source 0 - assert 1221714533.153112543, sequence: 30 - clear  1221714533.353167179, sequence: 30

so it looks like the polarity is correct, assert 200ms before clear, so it's the assert front that I need to monitor for UTC alignment, as per the GPS 18 LVC specs.

Nonetheless, I once again tried by changing flag2 to 1 (monitor the clear front) and the issue is still there.

This is what I get just after restarting ntpd: 

tix ~ # ntpq -c rv -p
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.4p4 at 1.1520-o Sun Sep 14 15:03:57 UTC 2008 (1)",
processor="i586", system="Linux/2.6.26-gentoo-r1", leap=11, stratum=16,
precision=-17, rootdelay=0.000, rootdispersion=0.090, peer=0,
refid=INIT, reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000,
poll=6, clock=cc7c611f.54234f2e  Thu, Sep 18 2008  7:09:51.328, state=1,
offset=0.000, frequency=-292.299, jitter=0.008, noise=0.008,
stability=0.000, tai=0
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp.ien.it      .UTCI.           1 u    6   64    1    7.267  -167.78   0.008
 scott.tssg.org  92.200.154.6     2 u    5   64    1   50.760  -172.37   0.008
 chime6.surfnet. .PPS.            1 u    4   64    1   32.426  -161.64   0.008
 ntp.eenet.ee    194.204.30.15    2 u    3   64    1   62.067  -172.20   0.008
 ns11.fi.basen.n 193.79.237.14    2 u    2   64    1   74.208  -167.21   0.008
 GPS_NMEA(1)     .PPS.            0 l    -   16    1    0.000  -340.89   0.008

and it's fun to see the GPS/PPS offset doubled this time, with the other NTP servers at 170ms.

Then after a while here is what I get:

tix ~ # ntpq -c rv -p
assID=0 status=06d4 leap_none, sync_ntp, 13 events, event_peer/strat_chg,
version="ntpd 4.2.4p4 at 1.1520-o Sun Sep 14 15:03:57 UTC 2008 (1)",
processor="i586", system="Linux/2.6.26-gentoo-r1", leap=00, stratum=2,
precision=-17, rootdelay=6.947, rootdispersion=15.620, peer=4231,
refid=193.204.114.105,
reftime=cc7c7472.4f628372  Thu, Sep 18 2008  8:32:18.310, poll=7,
clock=cc7c7554.f4288ee5  Thu, Sep 18 2008  8:36:04.953, state=4,
offset=3.524, frequency=-291.647, jitter=5.189, noise=0.785,
stability=0.026, tai=0
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp.ien.it      .UTCI.           1 u   98  128  377    6.947    1.610   3.920
-scott.tssg.org  92.200.154.6     2 u   65  128  377   50.224   -2.897   0.563
+chime6.surfnet. .PPS.            1 u   75  128  377   31.866    7.578   0.335
-ntp.eenet.ee    194.204.30.15    2 u   47  128  377   61.899   -2.641   0.247
+ns11.fi.basen.n 193.79.237.14    2 u   77  128  377   73.997    1.843   0.256
xGPS_NMEA(1)     .PPS.            0 l   12   16  377    0.000  -172.54   2.993

So ntpd has steered the clock to the Internet NTP servers, and has put an "x" in front of my GPS/PPS setup.  Could not find the explanation in the docs, but I assume it means "invalid" or something similar.  Interestingly enough, changing the sensing from the assert to the clear front did non change the time offset.  Is this as it should be or there lies the problem?

Hal, thanks for this gentoo-specific libc note:

> Among those things are installing a patched version of glibc.  See 
> http://bugs.gentoo.org/show_bug.cgi?id=237974 (you might want to vote for this 
> so that it gets fixed sooner).  Then rebuilding ntp against the patched 
> version.

if that is the case, then I suppose I could try an earlier kernel, like 2.6.24 o 25 using the quinquies patch (ahhh those italian kids who studied latin in high school! :-) ).

What are the differences between PPS API 5.3.0, 5.3.1 and 5.3.2?  Why would I want to have the latest minor release, other than to have patches suitable for a specific version of the kernel?

One last thing, I noticed that ppstest fails if tried after stopping ntpd:

tix ~ # ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)

If I use ppstest after a fresh reboot, no problem.  Not so after stopping ntpd... worth investigating more maybe?

Also, can you please confirm that setserial is no longer needed after the line discipline changes of a couple of months ago?

Any more suggestions on what to look for in order to debug, please shout!

Thanks and 73,

Luca IK2OVV / K2OVV