[LinuxPPS] still the strangeness

[Udo van den Heuvel]

Hello,

Today I upgraded to ntp 4.2.2p4. No change in behaviour:

[root at epia etc]# ntpq -pn
     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l    -   64  377    0.000    0.000
 0.001
x127.127.20.0    .GPS.            8 l    4   16  377    0.000   -1.800
 2.973
 194.109.22.18   193.79.237.14    2 u   59  128  377    7.315  171.446
 2.132
+193.67.79.202   .GPS.            1 u   59  128  377   15.029  169.144
 5.140
*193.79.237.14   .GPS.            1 u   60  128  377   13.353  170.024
 2.601
 82.92.197.115   .INIT.          16 u    -   64    0    0.000    0.000
 0.000
+82.92.228.68    192.53.103.108   2 u   52  128  357   13.496  171.286
 5.605
 83.83.82.105    193.79.237.14    2 u   50  128  377   15.350  172.901
 2.448

Note the 377 reach for the GPS.
Remote sites have a 170+ ms offset. I don't know why or exacty since
when but at least since I upgraded from VIA Epia CL6000 to EK8000.

Config looks right. Garmin GPS-18 LVC is connected to ttyS0 which is on
the I/O-plate on the back. ttyS1 for the ups is next to the I/O-plate on
the back.
The symbolic link is OK:


[root at epia redhat]# cd /dev
[root at epia dev]# ls -l *ps*
lrwxrwxrwx 1 root root 10 Dec 13 09:45 gps0 -> /dev/ttyS0
lrwxrwxrwx 1 root root 10 Dec 13 09:45 pps0 -> /dev/ttyS0
[root at epia dev]# ls -l /dev/ttyS0
crw-rw---- 1 root uucp 4, 64 Dec 19 15:19 /dev/ttyS0
[root at epia dev]# grep gps /usr/src/redhat/SOURCES/nmear1.patch
+            link[LENPPS] = "/dev/gps0";    /* just a default device */


I stopped ntpd and started minicom on tyyS0.
$PGRMCE gives:

$PGRMC,A,-2.9,100,,,,,,A,3,1,2,9,30*78

So we do have a 200ms pulse definded. (the 9)
Also the pulse is on. (the 2 before the 9)
Then I gave a reset using $PGRMI,,,,,,,R.

ntp.conf looks like:


server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

server 127.127.20.0 minpoll 4
fudge 127.127.20.0 flag3 1 flag2 0 time1 0.000
fudge   127.127.20.0 stratum 8 # 8 because of the problem

restrict default nomodify notrap nopeer noquery kod limited # notrust

server ntp.xs4all.nl
server ntp0.nl.net
server ntp2.nl.net
server 0.nl.pool.ntp.org
server 1.nl.pool.ntp.org
server 2.nl.pool.ntp.org

driftfile /var/lib/ntp/drift
broadcastdelay  0.008
logconfig -syncstatus -sysevents

discard average 5 minimum 2

restrict 127.127.0.0      mask 255.255.0.0  nopeer # internal clocks
restrict 127.0.0.1        mask 255.255.255.255 # accept local network
restrict 192.168.10.0 mask 255.255.255.0 nomodify notrap nopeer #notrust

statsdir /var/log/ntp
filegen peerstats file peers type day link disable
filegen loopstats file loops type day link disable


After starting ntpd, I check dmesg and it gives stuff like:


pps_core: New message from PID 2296 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: start sending replay to ID 2296...
pps_core: ... replay sent (180)
pps_core: New message from PID 2296 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: start sending replay to ID 2296...
pps_core: ... replay sent (180)
pps_core: New message from PID 2296 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: start sending replay to ID 2296...
pps_core: ... replay sent (180)


Any comments? Any ideas?

If the PPS would be on a different flank because of the newer VIA Epia
EK board we would see around 200 ms offset. 170+ is not close enough, right?
Does flag2 even work with LinuxPPS? I did not see affect in a few short
tests.


Udo