Building a Stratum 1 NTP Server Using Odroid C2

jcpingu

@stephenw10
After setting the time manually, I am still getting:

Jun 20 18:13:20 NTP-C2 ntpd[29528]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
Jun 20 18:13:20 NTP-C2 ntpd[29528]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized

stephenw10

And if that's immediately after NTPd is started it's still not a problem. That's not how NTP works it has to build data from all it's sources until it can be confident it has the correct time then it syncs the system time.

For example my device here shows:

Jun 21 18:06:03 	ntpd 	60481 	kernel reports TIME_ERROR: 0x2007: PPS Frequency Sync wanted but no PPS; PPS Time Sync wanted but no PPS signal
Jun 21 18:35:03 	ntpd 	56525 	ntpd 4.2.8p15@1.3728-o Thu Jun 10 21:42:50 UTC 2021 (1): Starting
Jun 21 18:35:03 	ntpd 	56525 	Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Jun 21 18:35:03 	ntpd 	56525 	----------------------------------------------------
Jun 21 18:35:03 	ntpd 	56525 	ntp-4 is maintained by Network Time Foundation,
Jun 21 18:35:03 	ntpd 	56525 	Inc. (NTF), a non-profit 501(c)(3) public-benefit
Jun 21 18:35:03 	ntpd 	56525 	corporation. Support and training for ntp-4 are
Jun 21 18:35:03 	ntpd 	56525 	available at https://www.nwtime.org/support
Jun 21 18:35:03 	ntpd 	56525 	----------------------------------------------------
Jun 21 18:35:03 	ntpd 	56634 	proto: precision = 0.345 usec (-21)
Jun 21 18:35:03 	ntpd 	56634 	basedate set to 2021-05-29
Jun 21 18:35:03 	ntpd 	56634 	gps base set to 2021-05-30 (week 2160)
Jun 21 18:35:03 	ntpd 	56634 	Listen and drop on 0 v6wildcard [::]:123
Jun 21 18:35:03 	ntpd 	56634 	Listen and drop on 1 v4wildcard 0.0.0.0:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 2 igb0 [fe80::208:a2ff:fe0b:c946%1]:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 3 igb0 172.21.16.66:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 4 igb1 [fe80::208:a2ff:fe0b:c947%2]:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 5 igb1 192.168.66.1:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 6 igb1 [fe80::1:1%2]:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 7 lo0 [::1]:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 8 lo0 [fe80::1%3]:123
Jun 21 18:35:03 	ntpd 	56634 	Listen normally on 9 lo0 127.0.0.1:123
Jun 21 18:35:03 	ntpd 	56634 	Listening on routing socket on fd #30 for interface updates
Jun 21 18:35:03 	ntpd 	56634 	GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
Jun 21 18:35:03 	ntpd 	56634 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jun 21 18:35:03 	ntpd 	56634 	kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

In that case the GPS was powered down too so lost satellite sync, hence no PPS signal.

What does does ntpq -c pe show?

Steve

jcpingu

@stephenw10

It shows:

jcpingu

@jcpingu
I followed this guide:
https://nguvu.org/pfsense/network%20time%20protocol%20(ntp)/ntp-server/
Your output looks different than mine. Again, I am not a linux guy so there are things that may not be in the guide that I am missing...

bingo600

NTP will exit or refuse to start if the local clock is too far off the NTP received clock. ISTR 15 sec is the limit.

Most installations uses ntpdate , to update the local clock before starting the NTP daemon.

https://linux.die.net/man/8/ntpdate

Remember once the NTP daemon is started , ntpdate won't connect anymore.
As the daemon "owns/blocks" the port.

Edit:
Now will be a good time to reveal what Linux distro you have installed on the C2 ....

Edit2:
Wasn't this a Stratum 1 server build ... Indicating you have a GPS clock source ?
Then the NTP date shouldn't be needed , provided your GPS sends the correct data sentences.

/Bingo

jcpingu

@bingo600

I am using dietpi 7.2

stephenw10

Yes, it's showing 0 reach there so it's not seeing any data. Also no other ntp servers configured as sources so it's never going to sync to anything.

Is your GPS seeing sufficient satellites to get a lock?

Are you seeing NMEA strings from it on the com port?

My output looks different to yours because I'm running that on pfSense directly.

Steve

jcpingu

@stephenw10

jcpingu

@stephenw10

bingo600

@jcpingu
The interesting NMEA packets are the : $GNRMC packets.

I see you skipped the "NMEA" filter the guide uses (to only see the RMC's) , was that because you don't use an Ublox 8 ?

Edit:
From the guide:
Uses the NMEA reference clock 20 driver specified by 127.127.20.0.
Mode 17 sets the driver to process only GPRMC message at 9600bps. Using higher clock speeds does not necessarily increase timing precision and because we have disabled non-GPRMC messages, there’s no risk of not being able to transmit the message within the 1 second timespan.

Did i see you use 115200 ???

/Bingo

jcpingu

@bingo600
I have a newer revision of the GPS Board. Its default baud is 115200

jcpingu

@bingo600
I will check $GNRMC. It looks like I am not getting them...

jcpingu

@bingo600
Here you go:

stephenw10

Does ppstest work against gpspps0? If not did you create the symlink?

What does your ntp.conf file look like? Did you change the mode for 115200 baud?

Edit: Yeah you probably want mode 81 there.

Steve

jcpingu

@stephenw10
Yes per the guide Symlink is used, there's a file that use the below:
KERNEL=="ttyS1", SYMLINK+="gps0"
KERNEL=="pps0", SYMLINK+="gpspps0"

Also, how do I edit ntp.conf? When I enter it, I get permission denied

jcpingu

@stephenw10
Here is the ntp.conf content in the guide. Are you saying to change mode 17 to 81?

server 127.127.20.0 mode 17 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 flag1 1 refid GPS

security

restrict default kod limited nomodify nopeer
restrict -6 default kod limited nomodify nopeer

Local users may interrogate the NTP server fully.

restrict 127.0.0.1
restrict -6 ::1

stats

driftfile /var/lib/ntp/ntp.drift

Enable statistics logging.

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

leap file

leapfile /var/lib/ntp/leap-seconds.list

stephenw10

Yes because, like it says there, mode 17 is for 9600 baud and your GPS is running at 115200. So currently it's seeing no data.

jcpingu

@stephenw10
Thank you. I will advise latest status...

jcpingu

@stephenw10
The good News:

The not so good news, I am still seeing clock unsynchronized:

jcpingu

@stephenw10
I was looking @ your example, and I see that it also shows this error:
Jun 21 18:35:03 ntpd 56634 kernel reports TIME_ERROR: 0x41: Clock Unsynchronized