Building a Stratum 1 NTP Server Using Raspberry Pi

tman222

Hi @kiokoman - thanks for posting your experience using a Raspberry Pi 4. I'm looking to give this project another go this summer and catching up again on the instructions/advice in this thread and the equipment I would need to purchase. Do you mind listing what exact equipment you ended up using and any steps you took that weren't detailed in your prior posts? At this point, I'm looking to generally follow this guide I found, however, using a Raspberry Pi 4 B instead of the Odroid C2 board.

https://nguvu.org/pfsense/network%20time%20protocol%20(ntp)/ntp-server/

At the time this was written the Pi 4 had not been released yet and the Odroid presented a better option over the Pi 3 given true gigabit network support. I also like the PoE hat integration which helps simplify cabling.

Thanks in advance for any help and advice you can provide.

kiokoman

Raspberry PI 4
Memory Card with raspian
GPS Adafruit ultimate GPS hat
battery cr1220
external active antenna
uFL to SMA converter

https://www.kiokoman.eu.org/index.php/per-non-dimenticare/24-howto-raspberry-pi-4-headless-ntp-stratum-1-gps-pps

https://www.ntppool.org/scores/ntp.kiokoman.eu.org

tman222

Thanks @kiokoman for sharing your setup and instructions, I really appreciate it. I wanted to bring this thread back up because I'm looking into this again as a small tinkering project and was also curious to learn more about the alternative APU2 based Stratum 1 NTP server setup @q54e3w mentioned above. @q54e3w - could you share some more details on your setup? Thanks in advance.

q54e3w

I had a half finished build and setup guide I was in the process of putting finishing touches to but didn't get to. I'll push it to the top of the list.
The downside of the PTP protocol is that the accuracy isn't preserved across the LAN unless you have hardware that supports it and because of the clients who typically care about this level of accuracy, its seems to be only available in more expensive switches etc, take a look here for a starter and please follow up if you find any more home lab friendly pieces.
https://en.wikipedia.org/wiki/List_of_PTP_implementations
My hardware solution that data came from was a Intel i210 based SBC that supports IEEE1588 and a regular GPS received running stock debian with mild kernel optimization.

I've migrated from using NTP to Chrony which syncs up quicker especially from a cold start which was one of the drawbacks of the NTP implementation. I tried the Odroid C4 which is an updated C2 but the earlier kernels didn't have PPS deciding included and I didn't have the time to build a custom kernel. Im sure things have evolved since then.

All of this is perhaps irrelevant though as Ive had great success with a LeoNTP server, unbelievably accurate and consistent across the year through temperature fluctuations etc and outperforms a non temperature controlled Pi substantially.
http://leobodnar.com/shop/index.php?main_page=product_info&products_id=272
When I update that guide I'll include some performance graphs etc.

tman222

@q54e3w said in Building a Stratum 1 NTP Server Using Raspberry Pi:

I had a half finished build and setup guide I was in the process of putting finishing touches to but didn't get to. I'll push it to the top of the list.
The downside of the PTP protocol is that the accuracy isn't preserved across the LAN unless you have hardware that supports it and because of the clients who typically care about this level of accuracy, its seems to be only available in more expensive switches etc, take a look here for a starter and please follow up if you find any more home lab friendly pieces.
https://en.wikipedia.org/wiki/List_of_PTP_implementations
My hardware solution that data came from was a Intel i210 based SBC that supports IEEE1588 and a regular GPS received running stock debian with mild kernel optimization.

I've migrated from using NTP to Chrony which syncs up quicker especially from a cold start which was one of the drawbacks of the NTP implementation. I tried the Odroid C4 which is an updated C2 but the earlier kernels didn't have PPS deciding included and I didn't have the time to build a custom kernel. Im sure things have evolved since then.

All of this is perhaps irrelevant though as Ive had great success with a LeoNTP server, unbelievably accurate and consistent across the year through temperature fluctuations etc and outperforms a non temperature controlled Pi substantially.
http://leobodnar.com/shop/index.php?main_page=product_info&products_id=272
When I update that guide I'll include some performance graphs etc.

Thanks @q54e3w, I really appreciate the response. If you don't mind me asking, where did you purchase the LeoNTP server? Is there a US distributor or did you purchase directly from the UK? Thanks again.

q54e3w

@tman222 https://v3.airspy.us/product/upu-leontp/

kiokoman

yesterday I received the waveshare max-m8q GPS hat for raspberry, I have configured it with the shared memory with gpsd, I still need to understand how to remove unnecessary GPS sentences, this is based on ublox, the adafruit was easier to configure. it seems to me that with SHM the offset is more unstable

UBLOX
status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd ntpsec-1.1.3 2019-11-18T06:04:00Z", processor="armv7l", system="Linux/5.4.72-v7l+", leap=00, stratum=1, precision=-20, rootdelay=0.0, rootdisp=1.135, refid=PPS, reftime=e37124c1.ed9d57a5 2020-12-01T20:23:29.928Z,
clock=e37124cb.3ec99709 2020-12-01T20:23:39.245Z, peer=13250, tc=4, mintc=0, offset=0.000691, frequency=-18.836975, sys_jitter=0.000413, clk_jitter=0.000419, clk_wander=0.000275, tai=37, leapsec="2017-01-01T00:00Z",
expire="2021-06-28T00:00Z"
     remote                                 refid      st t when poll reach   delay   offset   jitter
=====================================================================================================
*SHM(0)                                .GPS.            0 l   10   16  377   0.0000   2.6169   1.5005
oPPS(0)                                .PPS.            0 l    9   16  377   0.0000   0.0007   0.0004
-192.168.10.200                        .GPS.            1 u   63   64  377   0.0923  -2.0291   0.0163
-151.3.106.211                         .GPS.            1 u   64   64  376  31.6928  -1.2702   1.2323
+193.204.114.232                       .CTD.            1 u   27   64  377  39.7531   0.6983   0.9118
+193.204.114.233                       .CTD.            1 u   20   64  375  30.1307   5.2933   0.7851
 0.it.pool.ntp.org                     .POOL.          16 p    -  256    0   0.0000   0.0000   0.0010
 1.it.pool.ntp.org                     .POOL.          16 p    -  256    0   0.0000   0.0000   0.0010
-194.0.5.123                           85.199.214.100   2 u   58   64  377  20.8733  -0.5592   1.2309
+37.247.53.178                         193.204.114.232  2 u    -   64  375  19.3794   0.6783   0.8454

ADAFRUIT
status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd ntpsec-1.1.3 2019-11-18T06:04:00Z", processor="armv7l", system="Linux/5.4.72-v7l+", leap=00, stratum=1, precision=-20, rootdelay=0.0, rootdisp=100.12, refid=GPS, reftime=e37127b4.87c1698d 2020-12-01T20:36:04.530Z,
clock=e37127bc.a80fc6d1 2020-12-01T20:36:12.656Z, peer=52517, tc=6, mintc=0, offset=-0.392457, frequency=-12.429184, sys_jitter=1.986283, clk_jitter=2.402087, clk_wander=0.192477, tai=37, leapsec="2017-01-01T00:00Z",
expire="2021-06-28T00:00Z"
     remote                                   refid      st t when poll reach   delay   offset   jitter
=====================================================================================================
oNMEA(0)                               .GPS.            0 l    8   64  373   0.0000  -0.3925   1.9863
+192.168.10.203                        .PPS.            1 u   30   64  377   0.1134   2.0148   0.2716
 193.204.114.232                       .CTD.            1 u    -   64  375  31.0446   6.9845   0.8522
 193.204.114.233                       .CTD.            1 u   30   64  377  32.4280   6.2898   0.5521
 0.it.pool.ntp.org                     .POOL.          16 p    -  256    0   0.0000   0.0000   0.0010
 1.it.pool.ntp.org                     .POOL.          16 p    -  256    0   0.0000   0.0000   0.0010
+212.45.144.88                         193.204.114.233  2 u   60   64  377  18.1799   1.5251   1.2220
+95.110.248.206                        193.204.114.233  2 u   14   64  377  29.5371   3.1092   0.6852
-162.159.200.123                       10.48.8.4        3 u   83  128  257  45.1323  -3.8529  11.8599
-80.211.178.99                         216.239.35.0     2 u   33  128  337  29.3981   3.7633  20.6043

q54e3w

How long has it been running? Give it 24 hours to find its groove.

kiokoman

yeah i'm still playing with both.. you know start / restart / reconfigure / compare :)

q54e3w

You really need to compare over a long time window, add both NTP sources to pfSense's NTP server, enable monitoring and you can observe long term trends under diagnostics.

pfSense.local.lan - Status: Monitoring 2020-12-01 14-05-08.png

kiokoman

@johnpoz do you still have that uptronic running? it's basically the same one I have but from another vendor
would you mind sharing your ntp.conf?
i actually have this on my ntp.conf but compared to the adafruit is not that good

ublox config ->

server 127.127.20.0 mode 89 iburst prefer
fudge 127.127.20.0 flag1 0 flag3 0 time1 0.0 time2 0.048 refid GPS

server 127.127.22.0
fudge 127.127.22.0 flag3 1 time2 0.0 refid PPS

gps output

pi@raspberrypi3:~ $ cat /dev/gps0
$GNRMC,124146.00,A,4520.67417,N,01147.19928,E,0.138,,051220,,,A*6C
$GNZDA,124146.00,05,12,2020,00,00*7A

ublox ->

*127.127.20.0    .GPS.            0 l   46   64  377    0.000    9.572   0.800
o127.127.22.0    .PPS.            0 l   45   64  377    0.000    4.465   0.339

adafruit part of it.pool.ntp.org ->

oNMEA(0)                                 .GPS.            0 l    1   64  377   0.0000   0.0042   0.0199

johnpoz

what are you looking for exactly? I am running ntpsec

Keep in mind the sat signal just meant to get you close - the thing that keeps your time the pps

The signal from gps will almost never be the selected source..

And unless you don't have internet to get you close via another ntp source the gps signal doesn't mean all that much...

Your looking for a ntp server that time is stable and doesn't drift, that comes from the pps signal.

I don't bother playing with the fudge factors trying to get the gps to be inline with other time sources with very little offset, because in the big picture it doesn't matter.

But this does remind me that should prob update my ntpsec version.. Its a bit dated.. 1.2 came out back in oct.

Here is what I used to setup mine when I switched to ntpsec
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/

edit: Well this turned into a bit more than just clockmaker --update ;) updating my pi to buster from stretch.. Lets hope it works ;) I didn't bother to take a backup.. And just doing a dist-upgrade.. Either be real simple - or will force me to do a clean install.. Seems openssl doesn't have package for tls 1.3 support in stretch.. It's always something, and the new version of ntpsec seems to want that to compile.

kiokoman

@johnpoz
i was referring to the offset and jitter , it's much loweron the adafruit,
the difference between the adafruit and the ublox is that the adafruit have the pps signal inside /dev/gps0 so i only need
server 127.127.20.0
and with flag1 1 I have gps+pps
you see it because NMEA have the 'o' instead of only the '*'

with the ublox instead i have to use /dev/gps0 and /dev/pps0 but it end up with larger offset/jitter and it drift up and down very mutch during the day compare to the adafruit, i will wait another 24h and i'll show you how the graph from the adafruit is linear but the ublox is not

I'm not using gpsd / shm but direct driver, thanks for the link i will try that if i'm unable to achieve better results with my config

johnpoz

Ok... So I just rebooted and updated mine to ntpsec 1.2 so current values a bit off..

ntpq> version
ntpsec-1.2.0+ 2020-12-05T14:15:31Z (git rev 9842b560f)

But looking over the data for last 2 days so can see 5 min entries.. This looks pretty stable to me

Those are micro seconds.. Not miliseconds.. Max offset of 0.42 ms, or 0.00042 seconds..

That clock jitter is pretty flat..

edit: Question for you, your running min pi install right? Or did you install the gui on your pi?

edit2: If your looking for some tuning advice check out
https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_performance_tuning

kiokoman

@johnpoz
yes, i'm running min install without any gui / stripped services

johnpoz

Lets see what your graphs look like after some time.. Its going to take a bit to stabilize.. How often are you polling your shm entries?

If you were using ntpsec vs ntp you could just use the refclock entry in the ntp.conf to set an offset for your gps after you have determined what that is via say syncing with some very stable stratum 1 servers..

With ntp you have to use the fudge servers to do a specific offset.. But that is not what effects jitter..

I understand there is something to do with the different hats and if they are using edge or falling of the pps signal which could introduce offset, etc. And yeah I think jitter because of some bug... There was something I was reading about that - I believe it was in the link I provided about ntpsec setup.

edit: Yup here it was
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/#_edge_detection_issues_and_new_hats

edit2: I just finished up playing with mine.. Have to check it in a few days.. But yeah mine is going to take a bit to fall back into rhythm.. I updated the distro, I updated ntpsec and couple of reboots in there, etc..

So you can see mine is a bit crazy right now as well

edit3: If your going to run ntp server - you might want to add it to the pool.. For one you get an email if it gets too wacky or is not working.. So its a way to monitor how your ntp is performing.. As you can see mine is going to take a bit to get back into good running.. Check out the last entries compared to how well grouped the previous checks were..

kiokoman

@johnpoz
i don't use shm anyway this is the difference i see between the 2 gps
i restarted the ublox service around 13:00, where you see the spike

adafruit
green is pps+gps
ublox
yellow is pps green is gps

johnpoz

That is same same pi make and model. Same setup just the difference in the hats?

Wow - something seems off there.. I can see why your interested now..

What specific pi? And what specific hat? Maybe I will order one ;)

kiokoman

@johnpoz
yes both are raspberry pi 4 with 4gb same debian but different hat

johnpoz

What are you using to graph that like that? I would be up for getting a pi4 and the same hat to test.. Always up for fun projects ;)

Trying to find an excuse to get a 4 ;) hehehe

You seem to be pretty for out on the same hat I have, your ublox

     remote                                   refid      st t when poll reach   delay   offset   jitter
=======================================================================================================
*SHM(1)                                  .PPS.            0 l    2   16  377   0.0000  -0.3426   0.0026

Is the hat you got.. You had to solder?
https://www.adafruit.com/product/2324