Here was the website I came across.  Sorry I did not reference this before...

"

14.1.2. Choosing Between NTP Daemons

"
From:
https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html

I am guessing we don’t do autokey!

Jon

On Jun 17, 2021, at 11:23 AM, Michael Tremer <michael.tremer@ipfire.org> wrote:

Hello,

On 17 Jun 2021, at 16:26, Jon Murphy <jcmurphy26@gmail.com> wrote:

I’d like to challenge!

(This post was recently moved from the IPFire Community to the Development Mailing List)
I saw this in the agenda from last week:

<80392284118cf74d1a1176de8762f1da431444d3_2_517x148.png>
Screen Shot 2021-06-16 at 11.42.49 AM
1738×500 51.1 KB


I thought chrony was more for desktops & laptops. Devices that power down and might have a big time jump. And NTP was more for servers or devices that run full-time.

Yeah, I suppose that was true. Chrony used to be a client only, so it could not share its time with the network. That functionality was however added and it can also read from local time sources now.

I would say that they can be used interchangeably today. Some obscure features might be missing from chrony, but it should absolutely cover our use case.

The current NTP in IPFire can be easily changed from polling (one per hour / once per day) to non-polling by making a few simple changes to a config file:

disable
monitor

restrict
default nomodify notrap nopeer

restrict 127.0.0.1
server  $NTP_ADDR_1
prefer

server  $NTP_ADDR_2
server  127.127.1.0
fudge   127.127.1.0 stratum 10
driftfile
/etc/ntp/drift

$NTP_ADDR_1 and _2 are the Primary NTP server and Secondary NTP server from the https://ipfire:444/cgi-bin/time.cgi webgui page.

And by changing the https://ipfire:444/cgi-bin/time.cgi Synchronization to Manually

This would have been useful, but the change to chrony was proposed and I would like that because ntp was full of CVEs recently whereas chrony has a way more modern code base which hopefully is well reviewed and does not introduce anything bad.

Anyway, my thought is to make some changes to the current NTP service instead of implementing something new…

So far this is an item that Peter put on his to-do list, but I am not sure if anything was done about it, yet.

-Michael


Jon

---------------------------

TL;DR


When NTP is configured differently (Manually polling enabled) it will “correct” on it own:

Oct  6 21:40:01 ipfire ntpdate: Updated drift file.  Drift is 0.000 PPM at Tue Oct  6 21:35:43 CDT 2020
Oct  6 23:20:01 ipfire ntpdate: Updated drift file.  Drift is -18.986 PPM at Tue Oct  6 23:16:05 CDT 2020
Oct  7 00:20:01 ipfire ntpdate: Updated drift file.  Drift is -140.863 PPM at Wed Oct  7 00:16:04 CDT 2020
Oct  7 01:20:01 ipfire ntpdate: Updated drift file.  Drift is -210.676 PPM at Wed Oct  7 01:16:04 CDT 2020
Oct  7 02:20:01 ipfire ntpdate: Updated drift file.  Drift is -347.531 PPM at Wed Oct  7 02:16:04 CDT 2020
Oct  7 03:20:01 ipfire ntpdate: Updated drift file.  Drift is -407.147 PPM at Wed Oct  7 03:16:04 CDT 2020
Oct  7 04:20:01 ipfire ntpdate: Updated drift file.  Drift is -414.606 PPM at Wed Oct  7 04:16:04 CDT 2020
Oct  7 05:20:01 ipfire ntpdate: Updated drift file.  Drift is -414.826 PPM at Wed Oct  7 05:16:04 CDT 2020

More into:

https://community.ipfire.org/t/odd-ntp-offset-issues-continued/492