Building a Stratum 1 NTP Server Using Odroid C2
-
@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... -
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
-
I am using dietpi 7.2
-
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
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
-
@bingo600
I have a newer revision of the GPS Board. Its default baud is 115200 -
@bingo600
I will check $GNRMC. It looks like I am not getting them... -
@bingo600
Here you go:
-
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
-
@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
-
@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 GPSsecurity
restrict default kod limited nomodify nopeer
restrict -6 default kod limited nomodify nopeerLocal users may interrogate the NTP server fully.
restrict 127.0.0.1
restrict -6 ::1stats
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 enableleap file
leapfile /var/lib/ntp/leap-seconds.list
-
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.
-
@stephenw10
Thank you. I will advise latest status... -
@stephenw10
The good News:
The not so good news, I am still seeing clock unsynchronized:
-
@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 -
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
-
@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...
-
Have a look here
https://serverfault.com/questions/1048870/ntpd-fails-to-sync-time-error-0x41-clock-unsynchronizedEspecially 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.
