Building a Stratum 1 NTP Server Using Odroid C2
-
How is it failing for you? More information required.
-
root@NTP-C2:~/ntp-4.2.8p15# systemctl status ntp
ā ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp; generated)
Active: active (running) since Sun 2021-06-20 18:13:20 EDT; 26s ago
Docs: man:systemd-sysv-generator(8)
Process: 29519 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
Memory: 448.0K
CGroup: /system.slice/ntp.service
āā29528 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 1001:1001Jun 20 18:13:20 NTP-C2 ntpd[29528]: leapsecond file ('/var/lib/ntp/lea
p-seconds.list'): loaded, expire=2021-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Jun 20 18:13:20 NTP-C2 ntpd[29528]: Listen and drop on 0 v6wildcard [::]:123
Jun 20 18:13:20 NTP-C2 ntpd[29528]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Jun 20 18:13:20 NTP-C2 ntpd[29528]: Listen normally on 2 lo 127.0.0.1:123
Jun 20 18:13:20 NTP-C2 ntpd[29528]: Listen normally on 3 eth0 192.168.10.11:123
Jun 20 18:13:20 NTP-C2 ntpd[29528]: Listening on routing socket on fd #20 for interface update
s
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
Jun 20 18:13:20 NTP-C2 ntp[29519]: Starting NTP server: ntpd.
Jun 20 18:13:20 NTP-C2 systemd[1]: Started LSB: Start NTP daemon. -
@jcpingu said in Building a Stratum 1 NTP Server Using Odroid C2:
root@NTP-C2:~/ntp-4.2.8p15# systemctl status ntp
ā ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp; generated)
Active: active (running) since Sun 2021-06-20 18:13:20 EDT; 26s ago
Docs: man:systemd-sysv-generator(8)
Process: 29519 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
Memory: 448.0K
CGroup: /system.slice/ntp.service
āā29528 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 1001:1001Looks fine to me. I've the same thing :
-
Indeed that's not necessarily a problem when it first starts. What does ntpq show? Is it using the local PPS source?
Steve
-
@stephenw10
Look at the bottom: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 UnsynchronizedThe clock is off now by at least an hour.
-
If it's out by that much you may need to manually update it to something closer first.
But just because it didn't sync immediately when NTP starts does not mean it won't sync later when NTP has a full list of update servers showing the correct reach values.Steve
-
@stephenw10
That is where I am stuck. I need to know how to update it manually. I don't have the linux expertise as I am from a windows background and just now getting into Linux... -
Use the date command.
-
@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 -
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
-
It shows:
-
@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...