Building a Stratum 1 NTP Server Using Odroid C2
-
@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.
-
@bingo600
Here's the output of that command. I will check out the link. Thanks...
-
@stephenw10
This is my ntp.conf file. Based on bingo600 comments above. Is there anything else that needs to happen here?server 127.127.20.0 mode 81 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
-
No, I think it's working as expected.
That error will always appear when you restart ntpd for any reason. I would only vbe concerned if it is still logging new errors after running for some time.Steve
-
Try to put in a few ntp pool servers for reference.
Add this to your ntp.conf
# Internet time servers for sanity server 0.pool.ntp.org iburst prefer server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst server 3.pool.ntp.org iburst
From here:
http://doc.ntp.org/4.2.6/drivers/driver20.htmlIt seems like the $GNRMC is not a supported sentence , and that either
$GPZDA or $GPZDG must be sent for the NTP system to be fully autonomous. As in being able to set date/time fully via NTP.What GPS model do you have ?
Is it from "China" ... Where most Ublox'es are "fakes"This is not an "all bad" mesage , as the PPS still will keep your clock extremely accurate (sub seconds) . You just need a bit of help setting the seconds.But it's strange that the nmea driver is so picky.
Maybe gpsd would help here/Bingo
-
The NTP nmea refdriver doc is "buggy"
I just had a quick glance at the source
https://github.com/ntp-project/ntp/blob/master-no-authorname/ntpd/refclock_nmea.cAnd it's comparing the last 3 (4) characters in the sentence so any RMC works
And it seems like it's parsing/setting the date from RMC sentenses too.
The only thing ZDA is providing "extra" is YYYY vs YY from RMC.It should be possible to make a working NTP system with just RMC sentences , if NTP has been updated to assume that YY (21) means 2021.
Which i expect the unfold_century function does./Bingo
-
@bingo600 said in Building a Stratum 1 NTP Server Using Odroid C2:
ntp pool servers
Does it matter where the ntp pool servers are inserted in the ntp.conf file?
-
This guy puts it after the drift file
# Drift file to remember clock rate across restarts driftfile /var/lib/ntp/ntp.drift # Servers pool uk.pool.ntp.org iburst
And have a look here
https://lintut.com/how-to-verify-ntp-setup-is-working-properly-in-linux-or-unix-server/Verifying a stratum1 server might not be "super easy"
Use
ntpstatMy box says (No GPS installed) :
ntpstat synchronised to NTP server (80.71.132.xxx) at stratum 2 time correct to within 48 ms polling server every 1024 s
And
ntpq -pntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== -n1.taur.xx .PPS0. 1 u 753 1024 377 7.164 -0.397 0.383 *80.71.132.10x.i .GPS. 1 u 985 1024 377 1.862 -0.114 0.111 +mmo2.ntp.xx .PPS. 1 u 141 1024 377 2.827 -0.571 0.479 5.103.139.163.s .GPS. 1 u 8d 1024 0 3.267 0.348 0.000 -82.180.61.122 193.204.114.233 2 u 735 1024 377 40.205 0.981 0.419 +grape.inet.xx.n 68.166.61.255 2 u 315 1024 377 1.207 -0.107 0.089
The peer with the * in front (here 80.71.132.10x.i ) is the one that is used (synced to) right now.
o = pps peer * = sys peer # = too distant + = selected x = false ticker - = discarded
Show the output of your ntpq -p