New NTP server questions/problems.

[lerner]

A while ago I had problems getting my NTP (RPI) working.

With a fair bit of help I got it working better than it was and I am grateful.

Alas a "new" problem has since appeared.

AFAIK, the NTP server is working happily but if I leave it disconnected from the outside network for a long time, it seems to hang.

I noticed this recently when I booted a KODI machine and it gave me the EPOC date.
Shortly after that I booted another RPI and checked the state of the NTP server. sure enough: It was stuck in .INIT. mode.

What I would like to know is how to detect that happening and do something.

The "catch" is that the detection needs to be on the SAME machine as the NTP server.
I may set up a remote machine which could do an

Code: Select all

ntpq -p

on it and see what happens, but for now I don't have that machine.
So I want to keep it local on the same machine.

But for now the detection and output will be limited to the one machine.
So if the condition is detected, a GPIO pin is activated and a LED is turned on.

Anyone - please?

[knute]

AFAIK, the NTP server is working happily but if I leave it disconnected from the outside network for a long time, it seems to hang.

Anyone - please?

I think that's your problem. If the server hasn't gotten synced in recent history it can't serve up a valid time.

[lerner]

That's a fair enough call, but alas I don't think it is THE problem.

Alas I have since restarted/reset the NTP server so I can't show you the problem now.

But indulge me with this line of thinking:

On the NTP server, it has 3 external servers in its list. So there is a good source for the right time when it is connected to the big web.
It syncs.
All is good.

It is then disconnected from the big web and left there ticking along for a few days/weeks.

It has an RTC clock and shouldn't be power reset. Of course what happens when I am not around is beyond me. But still.
I log in and the RTC time is good enough. As is the Pie's clock.
Yet, the NTP is/was stuck in .INIT.

It doesn't know if it loses (or gains) time over a week. All it has is itself.
There is the Pie's clock and the RTC.

I don't know how they all interact. But that it has gone into the .INIT. mode is annoying.

I am not needing millisecond accuracy. It is just for housekeeping for when things are turned on/off. A minute (few seconds) here or there are not really "END OF DAYS" stuff.

But when it just gives up and sends EPOC dates, that's a whole other story.


Is that clearer to what is happening/expected/needed?

Again: Thanks.

[knute]

That's a fair enough call, but alas I don't think it is THE problem.

Alas I have since restarted/reset the NTP server so I can't show you the problem now.

But indulge me with this line of thinking:

On the NTP server, it has 3 external servers in its list. So there is a good source for the right time when it is connected to the big web.
It syncs.
All is good.

It is then disconnected from the big web and left there ticking along for a few days/weeks.

It has an RTC clock and shouldn't be power reset. Of course what happens when I am not around is beyond me. But still.
I log in and the RTC time is good enough. As is the Pie's clock.
Yet, the NTP is/was stuck in .INIT.

It doesn't know if it loses (or gains) time over a week. All it has is itself.
There is the Pie's clock and the RTC.

I don't know how they all interact.

I don't either.

But that it has gone into the .INIT. mode is annoying.

I think it has no choice when it doesn't get any updates.

But when it just gives up and sends EPOC dates, that's a whole other story.

Is that clearer to what is happening/expected/needed?

Again: Thanks.

Are you sure that it is sending EPOC dates or is it that the clients can't get an update from your server and stay at EPOC?

I think you need to look at "orphan mode" for the NTP server.

https://www.eecis.udel.edu/~mills/ntp/html/orphan.html

for some more info. Look around there is a lot of sites with some information about "orphan mode".

I've got a bunch of computers running on a closed network with a GPS clock serving NTP and a backup computer that has access to the world that serves NTP. I haven't tried using orphan mode but I think it applies in your case.

[FM81]

Have you told your NTP-server (in it's config) also to use the RTC as source?
Otherwise these two components (NTP and RTC) doesn't know about the existance of each other ...

Greetings, FM_81

[lerner]

Knute,

Thanks.

You are also probably right about the times and the "epoc" date.

It may not be the NTP server but the device using its default time as it is not getting any reply from the NTP machine.

FM81,

You too are right. I didn't think it through too much. But if the machine has the config for a REAL RTC, then I heped that the NTP would know of this and so do the right thing.

How do I tell the NTP that there is an RTC on the computer?

I shall do a bit of digging too, but I am also reading about the orphan thing mentioned by Knute.

[beta-tester]

you also can take a look to "chrony" it is a NTP server/client as well but has a different philosophy as "ntpd" has.
so it is working better with very long interruptions to an other ntp server.

chrony is an alternative open-source implementation of NTP service, originally designed for systems with low-bandwidth or intermittent TCP/IP service. It interoperates with ntpd using the same NTP protocols. Unlike ntpd which is designed to always be connected to multiple internet time sources, chrony is designed for long periods of offline use. Like ntpd, it can either operate purely as a client or provide time service. The chrony project has a home page at [CHRONY]. Its documentation includes an instructive feature comparison with ntpd at [CHRONY-COMPARE].

you can install chrony by

Code: Select all

sudo apt-get install chrony

PS.: if you are interested in getting time from GPS+PPS see RPi-GPS-PPS-StratumOne

[FM81]

How do I tell the NTP that there is an RTC on the computer?

You can add something like this to your config:

Code: Select all

server 127.127.1.0
fudge  127.127.1.0 stratum 15

But I'm not very sure if this is still supported, the "orphan mode" seems to have replaced something in the last months?
But you have nothing to lose, if you would test it ...

REMARK: Please do not understand these 127.127.x.y values als real IP-addresses, it is more a kind of "placeholders" for local NTP-sources! For example, my USB-DCF77-module (not on raspberry) has

Code: Select all

server 127.127.8.1 mode 5

on this place.

EDIT: Link added - see here for a list of local reference clock sources: https://www.eecis.udel.edu/~mills/ntp/h ... clock.html

Greetings, FM_81

[lerner]

Thanks very much.

I've looked at the links and read about the "undisciplined local clock" but I seem to be missing something.

Then it goes on to the orphan page.

Ok, again, I am raeding it, but missing something.

From the first one - undisciplined local clock:

Synopsis

Address: 127.127.1.u
Reference ID: LOCL
Driver ID: LOCAL

Yeah, ok.
I can't see where the 'u' is explained, or the local driver explained.

If I am reading it right I set up something like what you showed me then I can:

Code: Select all

ntp1 -p 127.127.x.y

and get back NTP times.

Given that it is 127.127.1.'u' I have tried a few but all to no avail.

From the bottom of my /etc/ntp.conf file:

Code: Select all

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
pi@TimePi:~ $ ntpq -p 127.127.1.0

Then when I try the ntpq command.

Code: Select all

127.127.1.0: timed out, nothing received
***Request timed out
pi@TimePi:~ $ 

Seems I am destined to have a lot of blonde days.

[FM81]

It's possible, that

Code: Select all

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

isn't supported by the RPi-RTC?
My experiance about this feature came from x86/amd64-machines; here it was working without any problems? May be my assumption about the raspberry-RTC is wrong?

EDIT: I've just tested on my machine:

Code: Select all

user@SERVER:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.8.1     .DCFa.           0 l   53   64  377    0.000   -0.109   0.008
x192.168.0.2     192.53.103.108   2 u   58   64  377    0.682   58.623   0.683
user@SERVER:~# ntpq -p 127.127.8.1
127.127.8.1: timed out, nothing received
***Request timed out

ntpq -pn works as it should, also with the local clock (which is different in my case), but ntpq -p 127.127.8.1 didn't!

EDIT number 2: After adding a DS1307-RTC-module and some practical tests I can say, that it can be used as described in 'ntp.conf'! But 'ntpd' will only use it, if there is nothing better reachable. I've disconnected a raspberry for a while completly from network for this test. Test-system was the latest full raspbian.

Best Regards, FM_81