[PATCH] Increase NTP update period

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Contributions Upload
Author Message
matjon
DD-WRT Novice


Joined: 05 Jan 2019
Posts: 3

PostPosted: Sat Jan 05, 2019 13:16    Post subject: [PATCH] Increase NTP update period Reply with quote
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 have posted this patch some time ago on
https://svn.dd-wrt.com//ticket/6463
but have received no response.

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.

diff -U3 -pr original/src/router/rc/process_monitor.c modified/src/router/rc/process_monitor.c
--- original/src/router/rc/process_monitor.c   2018-07-29 12:30:05.000000000 +0200
+++ modified/src/router/rc/process_monitor.c   2018-10-19 22:47:40.000000000 +0200
@@ -27,7 +27,8 @@ static void check_udhcpd(timer_t t, int
 extern void init_event_queue(int n);
 extern int timer_connect(timer_t timerid, void (*routine) (timer_t, int), int arg);
 
-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;
 
    init_event_queue(40);
-   NTP_M_TIMER = nvram_default_geti("ntp_timer", 3600);
+   NTP_M_TIMER = nvram_default_geti("ntp_timer", 3*24*3600);
    openlog("process_monitor", LOG_PID | LOG_NDELAY, LOG_DAEMON);
 
    if (nvram_invmatchi("dhcp_dnsmasq", 1)) {

Sponsor
Wildlion
DD-WRT Guru


Joined: 24 May 2016
Posts: 1035

PostPosted: Mon Jan 07, 2019 20:01    Post subject: Reply with quote
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.
mwchang
DD-WRT Guru


Joined: 26 Mar 2013
Posts: 747
Location: Hung Hom, Hong Kong

PostPosted: Thu Dec 03, 2020 11:03    Post subject: Re: [PATCH] Increase NTP update period Reply with quote
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)

May the Force and farces be with you! Live long and proper!

Facebook: https://www.facebook.com/changmanwai
Website: https://sites.google.com/site/changmw
SETI@Home profile: http://setiathome.berkeley.edu/view_profile.php?userid=211832
Wildlion
DD-WRT Guru


Joined: 24 May 2016
Posts: 1035

PostPosted: Thu Dec 03, 2020 23:37    Post subject: Reply with quote
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?
mwchang
DD-WRT Guru


Joined: 26 Mar 2013
Posts: 747
Location: Hung Hom, Hong Kong

PostPosted: Mon Dec 07, 2020 16:29    Post subject: Reply with quote
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. Smile

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)

May the Force and farces be with you! Live long and proper!

Facebook: https://www.facebook.com/changmanwai
Website: https://sites.google.com/site/changmw
SETI@Home profile: http://setiathome.berkeley.edu/view_profile.php?userid=211832
Wildlion
DD-WRT Guru


Joined: 24 May 2016
Posts: 1035

PostPosted: Mon Dec 07, 2020 23:54    Post subject: Reply with quote
If you blank the field it should default to pool.ntp.org and thus you got that ipv4 address through the dns lookup.
mwchang
DD-WRT Guru


Joined: 26 Mar 2013
Posts: 747
Location: Hung Hom, Hong Kong

PostPosted: Wed Dec 09, 2020 8:50    Post subject: Reply with quote
Wildlion wrote:
If you blank the field it should default to pool.ntp.org and thus you got that ipv4 address through the dns lookup.

Oh well, it seemed that my testing was totally wrong! Smile

I had the "Server IP/Nam" field blanked and here was what happened when DD-WRT booted. Note unbound was the only DNS server usable.

grep -i -E 'dns|bound|process_monitor|ntp' /var/log/messages
Code:
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)

May the Force and farces be with you! Live long and proper!

Facebook: https://www.facebook.com/changmanwai
Website: https://sites.google.com/site/changmw
SETI@Home profile: http://setiathome.berkeley.edu/view_profile.php?userid=211832
Wildlion
DD-WRT Guru


Joined: 24 May 2016
Posts: 1035

PostPosted: Thu Dec 10, 2020 0:13    Post subject: Reply with quote
mwchang wrote:

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.
mwchang
DD-WRT Guru


Joined: 26 Mar 2013
Posts: 747
Location: Hung Hom, Hong Kong

PostPosted: Thu Dec 10, 2020 18:56    Post subject: Reply with quote
Wildlion wrote:
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.

DD-WRT does have its hard-coded DNS record for that:
line 90-100 in https://svn.dd-wrt.com/browser/src/router/rc/ntp.c
Code:
  servers = nvram_safe_get("ntp_server");
  if (*servers == 0 || nvram_matchi("dns_crypt", 1)) {
    servers = "2.pool.ntp.org 212.18.3.19 88.99.174.22";
  }
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)

May the Force and farces be with you! Live long and proper!

Facebook: https://www.facebook.com/changmanwai
Website: https://sites.google.com/site/changmw
SETI@Home profile: http://setiathome.berkeley.edu/view_profile.php?userid=211832
Wildlion
DD-WRT Guru


Joined: 24 May 2016
Posts: 1035

PostPosted: Fri Dec 11, 2020 0:05    Post subject: Reply with quote
Interesting, I forgot about those others, I knew he had the 2.pool.ntp.org

I always am more concerned with the ntp algorithms/code itself.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Contributions Upload All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum