Hello Jon,
thanks for your mail.
No, it did not (yet), as I kind of lost track about the status of this patch, due to
the amount of other stuff on my plate during the recent days.
I will have a look at it again later today and amend it for Core Update 169, if
suitable. Apologies for the delay and the silence on my end.
Thanks, and best regards,
Peter Müller
Peter,
Did this get approved for CU 169?
Or is it waiting for someone A-OK?
Jon
On Jun 1, 2022, at 4:43 AM, Michael Tremer <michael.tremer@ipfire.org> wrote:
Okay, that is soft enough for me.
On 31 May 2022, at 17:08, Jon Murphy <jcmurphy26@gmail.com> wrote:
Michael,
(see below)
On May 31, 2022, at 6:49 AM, Michael Tremer <michael.tremer@ipfire.org> wrote:
Hello everyone,
I would say that it is worth to work on this change, because it is simple enough that we won’t need to spend a week. If it is going to be replaced by chronie or something else, so be it - at least we had a problem fixed in the meantime.
On 30 May 2022, at 22:30, Jon Murphy <jcmurphy26@gmail.com> wrote:
Peter,
(see below)
On May 30, 2022, at 2:07 PM, Peter Müller <peter.mueller@ipfire.org> wrote:
Hello Jon,
thank you for submitting this.
I consent with the intention of your patch, and believe this is the cure (or at least
a medicine) to insanely high clock drifts on some IPFire installations. Based on the
forum activity, there used to be more of them, but my gut feeling is that this issue
never completely went away.
I found one system that was off by 38 seconds per day…
Okay. This is really bad though. Watches from a bubble gum machine keep time better than this.
Nevertheless, I would like to await Arne's feedback on this: Particularly on ARM systems
without a battery-backed RTC, IPFire comes up with a bogus time, and I am not sure what
the implications of this patch would be for such systems.
`ntpd` added a feature that may help:
" -g no panicgate Allow the first adjustment to be Big"
Yes, the rationale here is that if the system comes up with Jan 1st, 1970, ntpd refuses to change that. I don’t know why. It does not seem to make sense to me.
Hello,
The change I made to the initscript ntp file does not seem very elegant! But I was not sure of a better way too complete the same results.
+ echo -e "server ${NTP_ADDR_1} prefer\nserver ${NTP_ADDR_2}" > /etc/ntp/ntpInclude.conf
Is this OK or does it belong in a different section of code. It needs to be updated when the NTP Servers are changed or when the time.cgi (Time Server) page is updated.
Hmm, I would favour a better solution as well. That file might be populated, and just
overwriting it seems to be a bit brutal to me. :-)
The `/etc/ntp/ntpInclude.conf` file is intentionally over written. I was going to do a find & replace on the `config/ntp/ntp.conf` file, but this seemed much simpler. Barbaric but simple!
I agree that this isn’t the most elegant solution, but it isn’t far off.
I would give the file a different name, because “ntpInclude.conf” does not really represent what it holds - which is the servers.
Is it necessary to mark one of the servers with the “prefer” keyword? I am not sure if we should rank them. Shouldn’t the system choose the one that is most accurate?
If I understand prefer correctly this helps break the "tie".
prefer
Marks the server as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the "Mitigation Rules and the prefer Keyword" page for further information.
Both servers could be marked "prefer" but that just means the preference becomes the first server in the config files.
The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types.
When used with the server or peer commands, the prefer option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; however, if more than one source is so designated, they are used in the order specified in the configuration file. If the first one becomes unselectable, the second one is considered and so forth.
-and-
Is chrony going to replace NTP? If so, then the change below is not needed.
I would really like so, but don't see that happen in IPFire 2.x soon. For the medium
term at least, you patch is by no means obsolete.
Please don't hurt me!
Hope I did not. :-)
No pain! :-)
Thanks, and best regards,
Peter Müller
Jon
On May 26, 2022, at 7:40 PM, Jon Murphy <jon.murphy@ipfire.org> wrote:
- Device time more accurate. (e.g., +/- 10 seconds per day to < 100 ms on some devices)
( I know we don't need the perfect time server )
- NTP and time will be accurate in manual mode (setting on Time Server > NTP Configuration WebGUI)
- Change NTP "prefer" server:
- The current preferred NTP server in an Undisciplined Local Clock.
- This is intended when no outside source of synchronized time is available.
- Change the "prefer" server from 127.127.1.0 to the Primary NTP server specified on
the Time Server > NTP Configuration WebGUI page.
- Change allows the drift file (located at /etc/ntp/drift) to be populated by ntpd.
- The drift file is updated about once per hour which helps correct the device time.
Signed-off-by: Jon Murphy <jon.murphy@ipfire.org>
---
config/ntp/ntp.conf | 3 ++-
src/initscripts/system/ntp | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/config/ntp/ntp.conf b/config/ntp/ntp.conf
index 9e393ca8e..bcaf2ee9e 100644
--- a/config/ntp/ntp.conf
+++ b/config/ntp/ntp.conf
@@ -1,6 +1,7 @@
disable monitor
restrict default nomodify noquery
restrict 127.0.0.1
-server 127.127.1.0 prefer
+server 127.127.1.0
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
+includefile /etc/ntp/ntpInclude.conf
diff --git a/src/initscripts/system/ntp b/src/initscripts/system/ntp
index 74b8bc86a..6c8174d25 100644
--- a/src/initscripts/system/ntp
+++ b/src/initscripts/system/ntp
@@ -52,6 +52,8 @@ case "$1" in
fi
fi
+ echo -e "server ${NTP_ADDR_1} prefer\nserver ${NTP_ADDR_2}" > /etc/ntp/ntpInclude.conf
+
boot_mesg "Starting ntpd..."
loadproc /usr/bin/ntpd -Ap /var/run/ntpd.pid
;;
--
2.30.2