Building a Stratum 1 NTP Server Using Odroid C2

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

stephenw10

Yes, I expect it to show that when ntpd is first started. It won't sync until sometime later when ntp is confident the time data it has is correct.
Wait some time and recheck. Or it may have already sync'd there since it show an offset or effectively 0 (2μs) from the GPS time.

Steve

jcpingu

@stephenw10
Thank you for all your help. I truly appreciate your patience and kindness. I still see the error this morning. However ntpq -p is showing the right output. I am assuming there's nothing I can do about the error...

bingo600

@jcpingu

Have a look here
https://serverfault.com/questions/1048870/ntpd-fails-to-sync-time-error-0x41-clock-unsynchronized

Especially this command : ntpq -c sysinfo

Normally as @stephenw10 mentioned , ntpd won't just accept a new clocksource , before investigating if it's "ok".

I usually expect approx 5 minutes (after daemon start) for the daemon to "trust/select" a clocksource.

jcpingu

@bingo600
Here's the output of that command. I will check out the link. Thanks...