Posted: Sat Jan 05, 2019 13:16 Post subject: [PATCH] Increase NTP update period
Hello,
process_monitor used to execute ntpclient (which synchronized time with NTP) every hour, which caused unnecessary load on NTP servers. In a vast majority of cases, routers don't need that precise timekeeping.
This patch changes the default NTP update period from one hour to three days, which was determined enough for a router.
I am going to post future patches concerning NTP once this one will be merged.
Code:
process_monitor: Increase NTP update period
process_monitor used to execute ntpclient (which synchronized time with NTP)
every hour, which caused unnecessary load on NTP servers.
In a vast majority of cases, routers don't need that precise timekeeping.
This patch changes the default NTP update period from one hour to three days,
which was determined enough for a router.
Signed-Off-By: Mateusz Jończyk
Helped-By: Broly
As it is difficult to specify under which license process_monitor.c is
distributed, this patch is licensed under the Creative Commons Zero license.
-static unsigned int NTP_M_TIMER = 3600;
+// Updating the time every third day is enough for a router
+static unsigned int NTP_M_TIMER = 3*24*3600;
static unsigned int NTP_N_TIMER = 30;
static int process_monitor_main(int argc, char **argv)
@@ -38,7 +39,7 @@ static int process_monitor_main(int argc
long int leasetime = 0;
I actually have to disagree with you... I think that an hour is a good amount of time, standard linux systems poll multiple times an hour. In the ntp source code the maxpoll is allowed max of 2^17 (~36 hours), 1 and a half days, not three days.
If the option could be changed, then I would have no problem, because those people that need or want to higher resolution could have it, but 1 hour is a good compromise. Not all router clocks are very good and many of us keep logs and having the times from the router shifted or off, make it hard to trouble shoot or understand what is going on.
Joined: 26 Mar 2013 Posts: 1856 Location: Hung Hom, Hong Kong
Posted: Thu Dec 03, 2020 11:03 Post subject: Re: [PATCH] Increase NTP update period
matjon wrote:
Hello,
process_monitor used to execute ntpclient (which synchronized time with NTP) every hour, which caused unnecessary load on NTP servers. In a vast majority of cases, routers don't need that precise timekeeping.
This patch changes the default NTP update period from one hour to three days, which was determined enough for a router.
I wanna suggest something:
process_monitor should fallback to use its hard-code ntp.pool.org IP address "212.18.3.19" for time checking when users-specified Server IP/Name are not responding or just plain wrong. This way DD-WRT would not be affected by wrong DNS (including DNSmasq & Unbound) nor NTP settings during startup.
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
poor form and actually could be a flaw to fall back to a default hard coded address. Everyone could have the error (or not even know) and then DDOS that one IP address or even what happens when that IP address has to go down for maintenance or is compromised?
Oh and what if you are on IPv6 only or not connected to the regular internet but an isolated network?
Joined: 26 Mar 2013 Posts: 1856 Location: Hung Hom, Hong Kong
Posted: Mon Dec 07, 2020 16:29 Post subject:
Wildlion wrote:
poor form and actually could be a flaw to fall back to a default hard coded address. Everyone could have the error (or not even know) and then DDOS that one IP address or even what happens when that IP address has to go down for maintenance or is compromised?
Oh and what if you are on IPv6 only or not connected to the regular internet but an isolated network?
That's why an entry should be logged if process_monitor chose to use the hard-coded NTP server IP address.
I don't know much about the IPv6 support though for that "Server IP/Name" field. But right now, if you blank that field, the hard-coded IPv4 address "212.18.3.19" was automatically used. Unless my testing was wrong...
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Jan 1 08:00:19 RT-N18U daemon.info dnsmasq[927]: started, version 2.82 DNS disabled
Jan 1 08:00:19 RT-N18U daemon.info dnsmasq[927]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua no-TFTP no-conntrack ipset no-auth DNSSEC loop-detect no-inotify no-dumpfile
Jan 1 08:00:19 RT-N18U daemon.info dnsmasq-dhcp[927]: DHCP, IP range 192.168.1.200 -- 192.168.1.249, lease time 12h
Jan 1 08:00:19 RT-N18U user.info : dnsmasq : daemon successfully started
Jan 1 08:00:22 RT-N18U user.info : unbound : recursive dns resolver daemon successfully started
Jan 1 08:00:26 RT-N18U user.info : dnsmasq : daemon successfully stopped
Jan 1 08:00:26 RT-N18U daemon.info dnsmasq[927]: exiting on receipt of SIGTERM
Jan 1 08:00:26 RT-N18U daemon.info dnsmasq[1094]: started, version 2.82 DNS disabled
Jan 1 08:00:26 RT-N18U daemon.info dnsmasq[1094]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua no-TFTP no-conntrack ipset no-auth DNSSEC loop-detect no-inotify no-dumpfile
Jan 1 08:00:26 RT-N18U daemon.info dnsmasq-dhcp[1094]: DHCP, IP range 192.168.1.200 -- 192.168.1.249, lease time 12h
Jan 1 08:00:26 RT-N18U user.info : dnsmasq : daemon successfully started
Jan 1 08:00:26 RT-N18U user.info : unbound : daemon successfully stopped
Jan 1 08:00:26 RT-N18U user.info : unbound : recursive dns resolver daemon successfully started
Jan 1 08:00:29 RT-N18U user.info : process_monitor : successfully started
Jan 1 08:00:29 RT-N18U user.info : ddns : inadyn daemon successfully started
Jan 1 08:00:34 RT-N18U daemon.err ntpclient[1203]: Failed resolving address to hostname 2.pool.ntp.org: Try again
Jan 1 08:00:34 RT-N18U daemon.err ntpclient[1203]: Failed resolving server 2.pool.ntp.org: Network is down
Jan 1 08:00:34 RT-N18U daemon.notice ntpclient[1203]: Network up, resolved address to hostname 212.18.3.19
Jan 1 08:00:34 RT-N18U daemon.debug ntpclient[1203]: Connecting to 212.18.3.19 [212.18.3.19] ...
Dec 9 16:22:51 RT-N18U daemon.info ntpclient[1203]: Time set from 212.18.3.19 [212.18.3.19].
Dec 9 16:22:51 RT-N18U daemon.info process_monitor[1201]: cyclic NTP Update success (servers 2.pool.ntp.org 212.18.3.19 88.99.174.22)
Dec 9 16:22:52 RT-N18U daemon.debug process_monitor[1201]: Restarting cron (time sync change)
Dec 9 16:22:53 RT-N18U daemon.debug process_monitor[1201]: Restarting unbound (time sync change)
Dec 9 16:22:53 RT-N18U user.info : unbound : daemon successfully stopped
Dec 9 16:22:53 RT-N18U user.info : unbound : recursive dns resolver daemon successfully started
Dec 9 16:22:53 RT-N18U daemon.debug process_monitor[1201]: Restarting unbound (time sync change)
Dec 9 16:22:53 RT-N18U user.info : unbound : daemon successfully stopped
Dec 9 16:22:54 RT-N18U user.info : unbound : recursive dns resolver daemon successfully started
Dec 9 16:22:54 RT-N18U user.info : process_monitor : daemon successfully stopped
Dec 9 16:22:54 RT-N18U daemon.info process_monitor[1201]: process_monitor : cleanup timers
Dec 9 16:22:54 RT-N18U user.info : process_monitor : successfully started
Dec 9 16:22:54 RT-N18U daemon.debug process_monitor[1390]: We need to re-update after 3600 seconds
Dec 9 16:22:54 RT-N18U daemon.info process_monitor[1390]: process_monitor : set timer: 3600 seconds, callback: ntp_main()
Dec 9 16:29:43 RT-N18U user.info : unbound : daemon successfully stopped
Dec 9 16:29:43 RT-N18U user.info : dnsmasq : daemon successfully stopped
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq[1094]: exiting on receipt of SIGTERM
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq[2142]: started, version 2.82 DNS disabled
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq[2142]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua no-TFTP no-conntrack ipset no-auth DNSSEC loop-detect no-inotify no-dumpfile
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq-dhcp[2142]: DHCP, IP range 192.168.1.200 -- 192.168.1.249, lease time 12h
Dec 9 16:29:43 RT-N18U user.info : dnsmasq : daemon successfully started
Dec 9 16:29:43 RT-N18U user.info : dnsmasq : daemon successfully stopped
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq[2142]: exiting on receipt of SIGTERM
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq[2172]: started, version 2.82 DNS disabled
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq[2172]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua no-TFTP no-conntrack ipset no-auth DNSSEC loop-detect no-inotify no-dumpfile
Dec 9 16:29:43 RT-N18U daemon.info dnsmasq-dhcp[2172]: DHCP, IP range 192.168.1.200 -- 192.168.1.249, lease time 12h
Dec 9 16:29:43 RT-N18U user.info : dnsmasq : daemon successfully started
Dec 9 16:29:44 RT-N18U user.info : unbound : recursive dns resolver daemon successfully started
Dec 9 16:29:44 RT-N18U user.info : unbound : daemon successfully stopped
Dec 9 16:29:45 RT-N18U user.info : unbound : recursive dns resolver daemon successfully started
Dec 9 16:29:48 RT-N18U user.info : process_monitor : daemon successfully stopped
Dec 9 16:29:48 RT-N18U daemon.info process_monitor[1390]: process_monitor : cleanup timers
Dec 9 16:29:48 RT-N18U user.info : inadyn : dynamic dns daemon successfully stopped
Dec 9 16:29:48 RT-N18U user.info : process_monitor : successfully started
Dec 9 16:29:48 RT-N18U user.info : ddns : inadyn daemon successfully started
Another irrelevant observation: many network-related processes were started before network was up at 08:00:34, and they were restarted a few times. This MIGHT slow down all boot and init processes. Also, dnsmasq was restarted a few times AFTER network was up...puzzling!
"ntp_main()" in the source codes could be interesting!
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Jan 1 08:00:34 RT-N18U daemon.err ntpclient[1203]: Failed resolving address to hostname 2.pool.ntp.org: Try again
Jan 1 08:00:34 RT-N18U daemon.err ntpclient[1203]: Failed resolving server 2.pool.ntp.org: Network is down
Jan 1 08:00:34 RT-N18U daemon.notice ntpclient[1203]: Network up, resolved address to hostname 212.18.3.19
Jan 1 08:00:34 RT-N18U daemon.debug ntpclient[1203]: Connecting to 212.18.3.19 [212.18.3.19] ...
Dec 9 16:22:51 RT-N18U daemon.info ntpclient[1203]: Time set from 212.18.3.19 [212.18.3.19].
Dec 9 16:22:51 RT-N18U daemon.info process_monitor[1201]: cyclic NTP Update success (servers 2.pool.ntp.org 212.18.3.19 88.99.174.22)
these lines show that it tries to go to a pool.ntp.org (this is correct and what ntp project prefers).
I have been through the ntp source code here, not as much as the full ntp source code and it adheres to everything properly.
As for your comment about restarting processes multiple times, that is a DD-WRT developer decision, you would have to ask BrainSlayer.
But it's used only when the Server IP/Name (nvram show ntp_server) is blank!!
And this behavior is also related to DNScrypt. I am wondering whether Unbound should be checked because it also requires a correct clock to work. That should be (nvram get recursive_dns)!
Should I open a ticket for that?
Quote:
As for your comment about restarting processes multiple times, that is a DD-WRT developer decision, you would have to ask BrainSlayer.
Agree... should be a new topic!
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Joined: 08 May 2018 Posts: 14217 Location: Texas, USA
Posted: Fri May 20, 2022 16:45 Post subject:
Well, these days only stock firmware and DD-WRT are the only two worlds still using a modified/patched ntpclient that I am aware of. Everyone else has switched to using the included ntpd in busybox which is based on OpenNTPD, AFAIK. I haven't dug very deep to get fully verified details, but. Not sure how that even relates, but I felt the need to spit out some trivial information just because _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
In case you were interested, "118.143.17.83" in the screenshot is actually "time.hko.hk". Avoid using domain name in the field, especially if you don't use DNSmasq as DNS server.
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!