[FIXED]: RPi as high precise NTP Server with GPS/PPS dev

[beta-tester]

MOVED from Troubleshooting to Advanced user:

hi,
i have a RPi that i want to use as a high precise NTP server (Stratum1) for a local network, where no connection to the external internet is.
that means i have no connection to any external NTP server.

to have my RPi running as an Stratum One server i use a GPS receiver that also provides a PPS (an high precise pulse per second signal).
the GPS does not have a battery to buffer the RTC of the GPS device (so after power off, everything boots from cold start).

i followed the descriptions here (Quick start NTP on the Raspberry Pi) and here (The Raspberry Pi as a Stratum-1 NTP Server).

i connected everything to the RPi correctly (RX, TX, PPS->GPIO 18).

everything seems to work fine as long the RPi is connected to the network with connection to external internet...
but if i use the RPi in a local network without a connection to external internet, then the RPi isn't able to get the correct time, that is should get from the GPS device.
can somebody tell me, there i made a mistake, and what i have to do to get my NTP Server running correctly with using the GPS time and its precise PPS signal in an isolated local network environment?

so i guess the GPS time never was used correctly to get the time.
in principe, the GPS is working, and PPS is working, the kernel is PPS enabled, NTP is PPS enabled, as you can see on the status messages below.

i use the official Raspbian Jessie Lite image (2016-02-26-raspbian-jessie-lite.img)

Code: Select all

pi@myStratum1:~ $ uname -a
Linux myStratum1 4.1.18+ #846 Thu Feb 25 14:11:56 GMT 2016 armv6l GNU/Linux

without internet connection!

Code: Select all

pi@myStratum1:~ $ ntpstat
unsynchronised
   polling server every 8 s

Code: Select all

pi@myStratum1:~ $ ntpq -crv -pn
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p6@1.3265 Wed Mar  9 21:01:11 UTC 2016 (1)",
processor="armv6l", system="Linux/4.1.18+", leap=11, stratum=16,
precision=-18, rootdelay=0.000, rootdisp=12.570, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000,
clock=da8b23f9.95c7cb10  Wed, Mar  9 2016 23:36:41.585, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000,
clk_jitter=0.004, clk_wander=0.000
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.22.0    .PPS.            0 l    -   16    0    0.000    0.000   0.000
 127.127.28.0    .NMEA.           3 l    -   16    0    0.000    0.000   0.000

Code: Select all

pi@myStratum1:~ $ dmesg | grep pps
[    3.096409] pps_core: LinuxPPS API ver. 1 registered
[    3.096417] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    3.111760] pps pps0: new PPS source pps.-1
[    3.111855] pps pps0: Registered IRQ 412 as PPS source
[   64.919550] pps_ldisc: PPS line discipline registered
[   64.923106] pps pps1: new PPS source ttyAMA0
[   64.923236] pps pps1: source "/dev/ttyAMA0" added

Code: Select all

pi@myStratum1:~ $ cgps -s
+-------------------------------------------++---------------------------------+
|    Time:       2016-03-10T06:29:00.000Z   ||PRN:   Elev:  Azim:  SNR:  Used: |
|    Latitude:    xx.xxxxxx x               ||  xx    xx    xxx    xx      Y   |
|    Longitude:   xx.xxxxxx x               ||  xx    xx    xxx    xx      Y   |
|    Altitude:   xxxx.x ft                  ||  xx    xx    xxx    xx      Y   |
|    Speed:      0.0 mph                    ||  xx    xx    xxx    xx      Y   |
|    Heading:    0.0 deg (true)             ||  xx    xx    xxx    xx      Y   |
|    Climb:      0.0 ft/min                 ||  xx    xx    xxx    xx      Y   |
|    Status:     3D FIX (2 secs)            ||  xx    xx    xxx    xx      Y   |
|    Longitude Err:   +/- x ft              ||  xx    xx    xxx    xx      Y   |
|    Latitude Err:    +/- x ft              ||  xx    xx    xxx    xx      Y   |
|    Altitude Err:    +/- xx ft             ||  xx    xx    xxx    xx      Y   |
|    Course Err:      n/a                   ||  xx    xx    xxx    xx      N   |
|    Speed Err:       +/- xx mph            ||  xx    xx    xxx    xx      N   |
|    Time offset:     -27774.290            ||                                 |
|    Grid Square:     xxxxxx                ||                                 |
+-------------------------------------------++---------------------------------+
cgps: caught signal 2

Code: Select all

pi@myStratum1:~ $ sudo 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 1457568421.095922675, sequence: 6277 - clear  0.000000000, sequence: 0
source 0 - assert 1457568422.095938675, sequence: 6278 - clear  0.000000000, sequence: 0
source 0 - assert 1457568423.095954675, sequence: 6279 - clear  0.000000000, sequence: 0
source 0 - assert 1457568424.095974675, sequence: 6280 - clear  0.000000000, sequence: 0
source 0 - assert 1457568425.095990675, sequence: 6281 - clear  0.000000000, sequence: 0
^C

here all the configuration files i use:

Code: Select all

pi@myStratum1:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0  console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Code: Select all

pi@Stratum1:~ $ cat /boot/config.txt
# /boot/config.txt
init_uart_baud=9600
dtoverlay=pps-gpio,gpiopin=18

Code: Select all

pi@myStratum1:~ $ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
pps-gpio

Code: Select all

pi@myStratum1:~ $ cat /etc/default/gpsd
# /etc/default/gpsd
# Default settings for gpsd.
# change the options.
START_DAEMON="true"
GPSD_OPTIONS="-n"
DEVICES="/dev/ttyAMA0"
USBAUTO="false"
GPSD_SOCKET="/var/run/gpsd.sock"

Code: Select all

pi@myStratum1:~ $ cat /etc/ntp.conf
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.22.0 refid PPS stratum 0

# Server from shared memory provided by gpsd
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 refid NMEA stratum 3 time1 0.510

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

restrict 127.0.0.1
restrict ::1

the install steps i did:

Code: Select all

pi@myStratum1:~ $ sudo apt-get -y install gpsd gpsd-clients
pi@myStratum1:~ $ sudo apt-get -y install pps-tools

pi@myStratum1:~ $ sudo apt-get -y install minicom ntpstat

pi@myStratum1:~ $ sudo service ntp stop
pi@myStratum1:~ $ sudo apt-mark hold ntp
pi@myStratum1:~ $ mkdir -p ~/ntp
pi@myStratum1:~ $ cd ~/ntp
pi@myStratum1:~ $ sudo apt-get install libcap-dev
pi@myStratum1:~ $ wget http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8p6.tar.gz
pi@myStratum1:~ $ tar xvfz ntp-4.2.8p6.tar.gz
pi@myStratum1:~ $ cd ntp-4.2.8p6/
pi@myStratum1:~ $ ./configure --enable-linuxcaps
pi@myStratum1:~ $ make
pi@myStratum1:~ $ sudo make install
pi@myStratum1:~ $ sudo cp /usr/local/bin/ntp* /usr/bin/  && sudo cp /usr/local/sbin/ntp* /usr/sbin/
pi@myStratum1:~ $ sudo service ntp start

EDIT few days later:
one step forwards, one steps backwards...

i found out, that the ntpd driver 28 for the virtual ip 127.127.28.0 starts to work only, when i connect a gpsd client to the gpsd once.
once that is done the time via NMEA (the gps data strings) acts as time source for ntp.
and also the ntp driver 22 for PPS virtual ip 127.127.28.0 starts to get being active from the view of ntp
(the /dev/pps0 is served by the kernel and is actively working all the time, only ntp takes notice of PPS after a gps client was connected to gpsd first)
the strange thing is, that the gpsd should start automatically, even without a connected gps-client
that what the documentation is telling...

Code: Select all

# /etc/default/gpsd
START_DAEMON="true"
GPSD_OPTIONS="-n"

that's what the options are being for

to auto start the gpsd, i use as WORKAROUND an additional entry gpspipe -r -n 1 & in the /etc/rc.local file, just before the exit 0

Code: Select all

# /etc/rc.local
...
gpspipe -r -n 1 &
exit 0

that will connect a gps client for exactly one NMEA output and then it disconnect itself gracely from the gpsd. but gpsd keeps active in the background and serves ntp with proper gps data.
anyhow, that works now... this was the step forwards.

that's, what i get now, after the RPi is booted up without a internet connection

Code: Select all

pi@myStratum1:~ $ ntpq -crv -pn
associd=0 status=0418 leap_none, sync_uhf_radio, 1 event, no_sys_peer,
version="ntpd 4.2.8p6@1.3265 Wed Mar  9 21:01:11 UTC 2016 (1)",
processor="armv6l", system="Linux/4.1.18+", leap=00, stratum=4,
precision=-19, rootdelay=0.000, rootdisp=1964.960, refid=SHM(0),
reftime=da903eb0.37b57464  Sun, Mar 13 2016 19:32:00.217,
clock=da903eb6.6399f39e  Sun, Mar 13 2016 19:32:06.389, peer=60741, tc=4,
mintc=3, offset=22.803398, frequency=-15.352, sys_jitter=0.000000,
clk_jitter=15.239, clk_wander=0.000
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.22.0    .PPS.            0 l    5   16    3    0.000  -71.439  13.025
*127.127.28.0    .NMEA.           3 l    6   16    7    0.000   22.803  20.441

but now i realize an other problems, to running my ntp statum 1 server

the NMEA gps data are not very accurate in sync by nature of gps NMEA string handling.
(the strings arrives not very syncroniusly via serial port and there are many additional gps data where its amount depends on how many satelites are in view and the baud rate of serial connection).
so its jitter can be up to 500ms in average it is something around 300 ms.
that is good enough, to set the local date time to a correct value, but is far away to be very accurate as it should for a stratum1 ntp server.

the problem is now. the ntp keeps to stay at the NMEA source and does never switck to the very precise PPS clock source.

how can i force ntp to use the high precise PPS source, after ntp was taking the NMEA data to setup the date time.
it is written in the documentation, that the PPS is taking in account only in cases. that a "normal" time sounrce was reached - because a PPS itself serves only a signal, not a date time. but a date time source is the NMEA. so the minimum requirements are given to take the PPS in account.
but ntp ignores the PPS. (it is marked as "x" = "falsetick" and is never be used)
and the ntp service gives only the very inaccurate synced time of NMEA.

Code: Select all

pi@myStratum1:~ $ ntpstat
synchronised to UHF radio at stratum 4
   time correct to within 365 ms
   polling server every 16 s

(that's my NMEA source)

how can i force ntp to use the high precise PPS in case there is no internet connection?
it should be like (as it is, when i have an internet connection and my local PPS is in use):

Code: Select all

pi@myStratum1:~ $ ntpstat
synchronised to atomic clock at stratum 1
   time correct to within 0 ms
   polling server every 16 s

(that's my local PPS source)

[FM81]

... but if i use the RPi in a local network without a connection to external internet, then the RPi isn't able to get the correct time, that is should get from the GPS device.

From the middle of your first linked page:

Code: Select all

Amend this line to add a trailing "prefer":

    server 0.debian.pool.ntp.org iburst prefer

Note: you must add a preferred server or PPS doesn’t work.

Means: Isolated network = no additional prefered server possible = PPS will not work

Greetings, FM_81

[beta-tester]

... but if i use the RPi in a local network without a connection to external internet, then the RPi isn't able to get the correct time, that is should get from the GPS device.

From the middle of your first linked page:

Code: Select all

Amend this line to add a trailing "prefer":

    server 0.debian.pool.ntp.org iburst prefer

Note: you must add a preferred server or PPS doesn’t work.

Means: Isolated network = no additional prefered server possible = PPS will not work

Greetings, FM_81

thanks, but i thought using the "NMEA" as fallback in case there is no internet will serve the minimum requirements

Code: Select all

# Server from shared memory provided by gpsd
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 refid NMEA stratum 3 time1 0.510

the NMEA will be used now (with the workaround by starting gpsd via rc.local), the PPS is giving non-null values as well now.
but PPS is still never be used for timekeeping.

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.22.0    .PPS.            0 l    5   16    3    0.000  -71.439  13.025
*127.127.28.0    .NMEA.           3 l    6   16    7    0.000   22.803  20.441

the x in front of the PPS means that ntp detect that PPS as falseticked.
(compared to the jittery NMEA it is true, because NMEA has a big jitter)

do you know how to tweak ntp to let ntp see PPS more accurate and NMEA as less accurate?
can i use time1, time2 or other flags to achieve that?

it makes me crasy/despair to know i have the hardware to get a precise clock, but the software i get not working as expected...

[beta-tester]

i think i got it working, without any internet network connection.

reading further documentations i found following sentences:

- PPS believed only if prefer peer correct and within 128 ms

(https://www.eecis.udel.edu/~mills/datab ... recise.pdf)

- Step threshold (128 ms): ignore if offset exceeds until stepout.

(https://www.eecis.udel.edu/~mills/datab ... /clock.pdf)

in combination with the man ntp documentation i changed my /etc/ntp.conf file like folowing...
(maybe the step limits are now way too wide and sloppy
0.5 is the absolute worsed limit, 0.128ms is default, but the NMEA is out of the 0.128 limit i guess, but within 0.4)

Code: Select all

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

# https://www.eecis.udel.edu/~mills/database/brief/precise/precise.pdf
# - PPS believed only if prefer peer correct and within 128 ms
tinker  step 0.4  stepback 0.4  stepfwd 0.4

# /dev/pps(0..3): Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0  minpoll 4  maxpoll 4
fudge 127.127.22.0  refid PPS  stratum 0  flag3 1  flag4 1

# gpsd: GPS NMEA serial data reference
server 127.127.28.0  minpoll 4  maxpoll 4 prefer
fudge 127.127.28.0  refid NMEA  stratum 3  time1 0.510


# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

#
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

now if i boot my RPi Statum 1 NTP server,
is takes the NMEA data to initially sync to date timer of GPS,
few seconds later the PPS get be activated and the ntpd takes PPS into account... and starts to sync to PPS as wanted

Code: Select all

synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 16 s

sync to atomic clock (my PPS)

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.22.0    .PPS.            0 l   15   16  377    0.000   -0.024   0.003
*127.127.28.0    .NMEA.           3 l   15   16  377    0.000  -54.385  30.985

watch the "o" in front of 127.127.22.0 PPS. isn't it beautyful...

[beta-tester]

From the middle of your first linked page:

Code: Select all

Amend this line to add a trailing "prefer":

    server 0.debian.pool.ntp.org iburst prefer

Note: you must add a preferred server or PPS doesn’t work.

Means: Isolated network = no additional prefered server possible = PPS will not work

Greetings, FM_81

hmm stupid me... without ´the tinker shit it works as well.
i only took you sugestions to put the prefer option to the NMEA time source, that alone will be the trick.

thank you for the hint.
(and i thought i was using all those combinations already )

so my ntp.conf file has simply that content:

Code: Select all

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

# /dev/pps(0..3): Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0  minpoll 4  maxpoll 4
fudge 127.127.22.0  refid PPS  stratum 0  flag3 1  flag4 1

# gpsd: GPS NMEA serial data reference
server 127.127.28.0  minpoll 4  maxpoll 4 prefer
fudge 127.127.28.0  refid NMEA  stratum 3  time1 0.510

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

#
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

[amorphys]

Hi,
good tutorial i was having same scenario like in your post and because of you i was able to fixed.

but right now i find another issue that is seems to affect the working gps-time-server with less than 10 satellites connected the visible can vary from 13 ~ 15 is that ntp does not start to use time from gpsd
Did you observe something similar ? during your setup i have now a location that does not work well i have fix with 9, 10 satellite but is not sync
ntpstat
unsynchronised
polling server every 8 s

same like before

i repeat myself it was worked well in a location but in one particular location does not work
Do you have some tips what to check ?

[beta-tester]

hi amorphys,

no, i not observed that till now. (* see the comment at the end)

at home, i have have the gps antenna on the window, but i am at base level and there is a balcony above the window and surrounded of other higher.
at that position i can be happy, if i get 7 satallites used for "3d fix" and even then i have maximum 2 of then makred as green and mostely they are yellow and red all the time. but i always get PPS signal as soon i get a 3d fix.

Code: Select all

┌───────────────────────────────────────────┐┌─────────────────────────────────┐
│    Time:       2016-09-17T.............   ││PRN:   Elev:  Azim:  SNR:  Used: │
│    Latitude:    ...........               ││ ...    ..    ...    19      Y   │
│    Longitude:   ...........               ││ ...    ..    ...    00      Y   │
│    Altitude:   ...... ft                  ││ ...    ..    ...    34      Y   │
│    Speed:      0.3 mph                    ││ ...    ..    ...    15      Y   │
│    Heading:    90.7 deg (true)            ││ ...    ..    ...    34      Y   │
│    Climb:      0.0 ft/min                 ││ ...    ..    ...    13      Y   │
│    Status:     3D FIX (13 secs)           ││ ...    ..    ...    00      N   │
│    Longitude Err:   +/- 52 ft             ││ ...    ..    ...    18      N   │
│    Latitude Err:    +/- 67 ft             ││ ...    ..    ...    00      N   │
│    Altitude Err:    +/- 64 ft             ││ ...    ..    ...    21      N   │
│    Course Err:      n/a                   ││ ...    ..    ...    16      N   │
│    Speed Err:       +/- 91 mph            ││ ...    ..    ...    00      N   │
│    Time offset:     0.520                 ││ ...    00    000    00      N   │
│    Grid Square:     ......                ││                                 │
└───────────────────────────────────────────┘└─────────────────────────────────┘

Code: Select all

watch -n4 sh -c "ntpstat; ntpq -p -crv;"

Every 4.0s: sh -c ntpstat; ntpq -p -crv;                                                                                          Sat Sep 17 18:41:55 2016

synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 8 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    5    8  377    0.000    0.024   0.011
*SHM(0)          .NMEA.           0 l    6    8  377    0.000   43.913  12.588
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p8@1.3265 Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.060, refid=PPS,
reftime=db880cee.fed0a371  Sat, Sep 17 2016 18:41:50.995,
clock=db880cf3.a1cbf457  Sat, Sep 17 2016 18:41:55.632, peer=64400, tc=3,
mintc=3, offset=0.023907, frequency=-19.019, sys_jitter=0.010965,
clk_jitter=0.008, clk_wander=0.012

(offset and jitter are high, because i just powered on the system again after a two months down time - only for you)

maybe it helps to add a battery to your gps, if it has that option. (it will buffer the RTC and the satallite table - so after powerup, it does not need to do a cold start)
i have a battery on my gps, so it will speed up covering the satellites.
possible the ntp deamon will give up (time out), before the gps get a 3d fix.

your picture shows, you definitely have a "3d fix". so you should get a PPS from the GPS device at that time.
you can try to restart the ntpd after the gps is giving the PPS signal.

ps: here is the script i made and used to setup my pps gps stratum one server...
https://github.com/beta-tester/RPi-GPS-PPS-StratumOne

(comment at the end )
are you sure, your scenario was working at one location?
i can see at your picture, that you are using an older version of ntpd (4.2.7p*). did you compiled an older version or did you "apt-get upgrade" the compiled ntpd by accident?
(before or after compiling and replacing the ntpd with your newest "customized" version, you should mark the ntpd to hold, to prevent apt-get upgrade to replace the compiled customized ntpd version)

Code: Select all

sudo apt-mark hold ntp

or are you using a RPi3, where you have to disable bluetooth to be able to use the serial at GPIO?

[amorphys]

Hi,
thanks for your quick reply .

I fixed the problem and here is how :
1.yes i put this old version of ntp from begining i changed now to the new one
2.was working well in my location with this version tested etc
3.I observed the log
cat /var/log/syslog
and here it was my answer was so simple
i put even a picture for this so my time on raspy was to big the difference so .....
4.i did update manual the pi date time etc and after stop and restart ntp here it was see picture of syslog after update
And now everything is work as should be
Many thanks for help me out to figure out

[w00dw0rm]

Hi - im interested in your output of ntptime. does it say PPSSIGNAL anywhere?
Thanks

[SpiraMirabilis]

Keep in mind that GPS Time is slightly off from Universal Coordinated Time.

[DougieLawson]

I never knew that GPS didn't play nicely with the 17 leap seconds inserted into UTC since they set their clocks.

http://leapsecond.com/java/gpsclock.htm

[SpiraMirabilis]

Yes, sir. For the GPS constellation, precise time is only really needed from one SV to another, of course, not from what we'd refer to as objective time or UTC. Implementing leap-seconds would be a net negative in terms of GPS accuracy.

[w00dw0rm]

Hey all and beta-tester - im trying to figure out if it is essential for ntptime to reflect PPS:

"The first thing you should look at is the status (0x2107 in our case). The magic words in parentheses explain the meaning of the individual bits. The important bit for now is PPSSIGNAL. That bit is set directly by the operating system and says a PPS signal has been detected."

from

http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm

as per ntptime output.

mine does not, it just says PPL and USYNC ( or PPL and NANO i think).

[beta-tester]

Hey all and beta-tester - im trying to figure out if it is essential for ntptime to reflect PPS:

"The first thing you should look at is the status (0x2107 in our case). The magic words in parentheses explain the meaning of the individual bits. The important bit for now is PPSSIGNAL. That bit is set directly by the operating system and says a PPS signal has been detected."

from

http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm

as per ntptime output.

mine does not, it just says PPL and USYNC ( or PPL and NANO i think).

is that a question?
if your GPS gives a PPS signal to the GPIO
and your kernel is setted up to use that PPS
and your ntpd is useing that PPS (you have to compile the ntpd newly by yourself - the normal one from the raspbian isn't able to use PPS as long as i know),
only then you will get a clock_sync via PPS after a while.
that PPS signal is essential for a stratum1 server.
everything else is less precise and can not be called stratum1 anymore.
stratum15 is the lowest precise clock server (e.g. if you only use the NMEA data of the gps device)
i mean to remember my that the time server needs two different time sources as minimum to get the lock to trust its time.
in my case (NMEA + PPS), if you don't have a GPS, you need two timeservers via internet or a DCF77 (its time data + its PPS) as reliable time source.
if the time server does not get a lock, then it is a free running clock free running in its frequency drift...
stratum16 = totally unsynced clock

[w00dw0rm]

Hi beta-tester,

Thanks for the explanation..

in my case,
yes I have PPS connected to GPIO
I think I set kernel to use PPS
I compiled ntp.

Let me re-phrase the question in my mind - because I want to ensure I did everything correctly by checking the status my pi:

is it important that the output of ntptime to contain something like:
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO)?
( as explained in section 6.2.4.2.1. of this: http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm )

because my output contains this:
status 0x2001 (PLL,NANO),

I would be interested in what your ntptime output is like, to compare against.

Thanks a lot.

[beta-tester]

...is it important that the output of ntptime to contain something like:
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO)?
( as explained in section 6.2.4.2.1. of this: http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm )

because my output contains this:
status 0x2001 (PLL,NANO),

I would be interested in what your ntptime output is like, to compare against.

Thanks a lot.

hmmm... that's interesting...
i did not used ntptime, but now, and you are right, i also get "only" (PLL,NANO).
see below the output of ntptime, ntpstat and ntpq first just after restart the service, then some second later, and then after a long while.

Code: Select all

StratumOne:~ $ sudo service ntp restart



StratumOne:~ $ ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db96437a.7c460ed8  Wed, Sep 28 2016 13:26:18.485, (.485444178),
  maximum error 1016 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -19.460 ppm, interval 1 s,
  maximum error 1016 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
  
unsynchronised
   polling server every 8 s
   
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .PPS.            0 l    -    8    0    0.000    0.000   0.000
 SHM(0)          .NMEA.           0 l    -    8    0    0.000    0.000   0.002
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p8@1.3265 Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=0.015, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
clock=db96437a.9b25a89f  Wed, Sep 28 2016 13:26:18.606, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=-19.460, sys_jitter=0.000000,
clk_jitter=0.002, clk_wander=0.000



StratumOne:~ $ ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db96437f.f63f4668  Wed, Sep 28 2016 13:26:23.961, (.961903795),
  maximum error 3516 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -19.460 ppm, interval 1 s,
  maximum error 3516 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
  
synchronised to UHF radio at stratum 1
   time correct to within 7977 ms
   polling server every 8 s
   
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .PPS.            0 l    -    8    0    0.000    0.000   0.000
*SHM(0)          .NMEA.           0 l    6    8    1    0.000  -38.888   0.002
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd 4.2.8p8@1.3265 Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=7977.279, refid=NMEA,
reftime=db96437a.a3bd2e76  Wed, Sep 28 2016 13:26:18.639,
clock=db964380.127d6c1e  Wed, Sep 28 2016 13:26:24.072, peer=30289, tc=3,
mintc=3, offset=-38.887758, frequency=-19.460, sys_jitter=0.001907,
clk_jitter=13.749, clk_wander=0.000



StratumOne:~ $ ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db96a25c.407e6b40  Wed, Sep 28 2016 20:11:08.251, (.251929298),
  maximum error 2500 us, estimated error 2 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -1.363 us, frequency -19.673 ppm, interval 1 s,
  maximum error 2500 us, estimated error 2 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
  
synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 8 s
   
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    3    8  377    0.000   -0.002   0.003
*SHM(0)          .NMEA.           0 l    2    8  377    0.000    6.240  25.342
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p8@1.3265 Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.030, refid=PPS,
reftime=db96a259.a3bb7612  Wed, Sep 28 2016 20:11:05.639,
clock=db96a25c.5bff8d29  Wed, Sep 28 2016 20:11:08.359, peer=30288, tc=3,
mintc=3, offset=-0.001500, frequency=-19.673, sys_jitter=0.003223,
clk_jitter=0.003, clk_wander=0.001

but the thing with ntptime is, that you can manipulate the status. i didn't found a proper description what values are allowed to set (see here), but i was able to "destroy" the status to 0x0.

maybe the kernel is not setting up that status in a proper way, or there is maybe a flag to set in the ntp.config or ntptime is not supported.
ppstest, ntpstat and ntpq suggests, that PPS is used, only ntptime is showing something different.

[w00dw0rm]

Yes I get very similar results:

Code: Select all

sudo service ntp restart

ntptime; ntpstat; ntpq -p -crv;

ntp_gettime() returns code 0 (OK)
  time db97605f.00925788  Thu, Sep 29 2016  9:41:51.002, (.002233705),
  maximum error 516 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -9.143 ppm, interval 1 s,
  maximum error 516 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
unsynchronised
   polling server every 8 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .kPPS.           0 l    -   16    0    0.000    0.000   0.000
 SHM(0)          .SHM.            0 l    -   16    0    0.000    0.000   0.001
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p6@1.3265-o Wed Sep 14 12:18:16 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.20-v7+", leap=11, stratum=16,
precision=-20, rootdelay=0.000, rootdisp=0.015, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
clock=db97605f.11f11315  Thu, Sep 29 2016  9:41:51.070, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=-9.143, sys_jitter=0.000000,
clk_jitter=0.001, clk_wander=0.000


ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db97606a.5705b7d0  Thu, Sep 29 2016  9:42:02.339, (.339931032),
  maximum error 6516 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -9.143 ppm, interval 1 s,
  maximum error 6516 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
synchronised to UHF radio at stratum 1
   time correct to within 7941 ms
   polling server every 16 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .kPPS.           0 l    -   16    0    0.000    0.000   0.000
*SHM(0)          .SHM.            0 l   11   16    1    0.000    3.279   0.001
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd 4.2.8p6@1.3265-o Wed Sep 14 12:18:16 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.20-v7+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=7941.272, refid=SHM,
reftime=db97605f.8b917308  Thu, Sep 29 2016  9:41:51.545,
clock=db97606a.5fe43e07  Thu, Sep 29 2016  9:42:02.374, peer=15607, tc=4,
mintc=3, offset=3.279228, frequency=-9.143, sys_jitter=0.000954,
clk_jitter=1.159, clk_wander=0.000

 
ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db976129.a1318764  Thu, Sep 29 2016  9:45:13.629, (.629662440),
  maximum error 6500 us, estimated error 1053 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 11.760 us, frequency -9.567 ppm, interval 1 s,
  maximum error 6500 us, estimated error 1053 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,
synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 16 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .kPPS.           0 l   11   16  377    0.000    0.014   0.137
*SHM(0)          .SHM.            0 l   10   16  377    0.000    3.030   0.525
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p6@1.3265-o Wed Sep 14 12:18:16 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.20-v7+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=1.165, refid=kPPS,
reftime=db97611e.8b91c49b  Thu, Sep 29 2016  9:45:02.545,
clock=db976129.b2224e3e  Thu, Sep 29 2016  9:45:13.695, peer=15606, tc=4,
mintc=3, offset=0.013985, frequency=-9.567, sys_jitter=0.136663,
clk_jitter=1.054, clk_wander=0.079

and I agree completely about:

ppstest, ntpstat and ntpq suggests, that PPS is used, only ntptime is showing something different.

But something still niggles at me about this PPS.... probably because I am at the cliff edge of my abilities in linux here.

By the way, it appears ntpdc (as suggested as an alternative to ntptime in https://www.eecis.udel.edu/~mills/ntp/html/ntptime.html ) is no longer working: http://lists.ntp.org/pipermail/question ... 37145.html so I found the ntpq -c [command] alternatives like:

Code: Select all

$ ntpq -c kerninfo
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
pll offset:            -0.01559
pll frequency:         -8.54549
maximum error:         0.0075
estimated error:       9.6e-05
kernel status:         pll nano
pll time constant:     4
precision:             1e-06
frequency tolerance:   500
pps frequency:         0
pps stability:         0
pps jitter:            0
calibration interval   0
calibration cycles:    0
jitter exceeded:       0
stability exceeded:    0
calibration errors:    0
dddnu@02B053:~ $

and it is bizzare that the ntpq -c kerninfo claims to not know about PPS, even though ntpq -p clearly does!

Maybe there are 2 PPS modes, from the hint in http://doc.ntp.org/4.2.4/ntpq.html
"o pps.peer
The peer has been declared the system peer and lends its variables to thesystem variables. However, the actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface. "

and maybe the ntpd -c -kerninfo (or ntptime) refers to the kernel interface, and what we have working is the PPS reference clock?
I wonder if there is any difference in accuracy..
Ta

[beta-tester]

hmm...
the raspbian kernel is compiled with the settings:

Code: Select all

StratumOne:~ $ sudo modprobe configs
StratumOne:~ $ zcat /proc/config.gz | grep PPS
# PPS support
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set
# PPS clients support
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
CONFIG_PPS_CLIENT_GPIO=m
# PPS generators support

where =m means, that this options are included as modules.
and all modules are used

Code: Select all

StratumOne:~ $ lsmod | grep pps
pps_ldisc               2389  2
pps_gpio                2993  1
pps_core                8756  4 pps_ldisc,pps_gpio

not sure how to read that correctly (http://lxr.linux.no/linux/drivers/pps/Kconfig), but the raspbian kernel is also compiled with "CONFIG_NO_HZ=y", maybe this will prevent the kernel to discipline itself by PPS. (maybe that kernel or the RPi hardware isn't able to do PPS sync itself)
so the PPS signal is used, but only bypassed to a consumer, if there is any, but the kernel itself isn't using that PPS for any sync.
and therefore the ntpq -c kerninfo is giving only PLL and not PPS in its status.

the kernel is using the clock, but does not sync the clock. ntpd is doing that job for the kernel.
but ntpd is using the PPS signal, provided by the kernel, to sync the time through its ntp sync mechanism.
a PPS is as good as any other internet time, but way more accurate, with way less latency, way more reliable.

there is a comment for the ntp.conf file entry for driver22

The driver normally operates like any other driver and uses the same mitigation algorithms and PLL/FLL clock discipline incorporated in the daemon. If kernel PLL/FLL support is available, the kernel PLL/FLL clock discipline can be used instead. The default behavior is not to use the kernel PPS clock discipline, even if present. This driver incorporates a good deal of signal processing to reduce jitter using the median filter algorithm in the driver. As the result, performance with minpoll configured at 4 (16s) is generally better than the kernel PPS discipline. However, fudge flag 3 can be used to enable the kernel PPS discipline if necessary.

so i read this comment as, that it does not lack in accuracy when using PPS signal only and not the "PPS disciplined kernel time" to sync - from the point of view of ntp - and everything that is using that PPS synced ntp time.

i reached the end of my abilities/knowledge.
i am not a pro in that ntp/pps/linux kernel stuff. i am happy, that my RPi is giving time, and i trust that time.

ps:

(..) so I found the ntpq -c [command] alternatives like:

Code: Select all

$ ntpq -c kerninfo
...

thank you that you found out. because i got time out messages with the other ntpdc method.