Joined: 08 May 2018 Posts: 14247 Location: Texas, USA
Posted: Sat May 14, 2022 14:32 Post subject: Re: USB script executed during sysinit... how many times?
egc wrote:
kernel-panic69 wrote:
Udhcpc gets WAN IP which DNSMasq and NTP rely on to work... for IPv4...
That is why I wrote:
Quote:
Maybe my example is not exactly true but you get the meaning.
Yeah, my ADH-OCD overlooked that
mwchang wrote:
It would be great if DD-WRT's Busybox could enable the "flock" command. Then we could use file locking to avoid multiple instances of a certain process.
ntp_timer=432000 which doesn't matter if you reboot or upgrade and reboot it will sync once and then a week only later. But Yea, I flash a new dev build sometimes twice or 3 times a day to test UI fixes. Othewise, I dont care if I loose 1 second or two in a week if even that much.
Joined: 08 May 2018 Posts: 14247 Location: Texas, USA
Posted: Tue May 17, 2022 15:50 Post subject:
It triggers other things to recycle and people do not know how to handle the syslog messages. There really is no need to sync more than once per 24 hours IMHO. _________________ "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
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Tue May 17, 2022 18:24 Post subject:
egc wrote:
Such a setting is 10 minutes work, that is not the problem.
But I am not sure what actually the problem is with updating the time every hour.
10 minutes to set a nvram variable, is this index finger only typing and searching for the next letter type thing? If so, half hour at least to an hour being generous. and my dd-wrt passwords are 40 characters long. So imagine that, takes me 3 hours to log in on a bad day when my index finger is tired.
I think the problem with NTP as standard interval causes other services that are dependent on any time to restart also, and too much log noise.
Several threads on that issue, I'm not looking for any to link them here, so I apologize for that, but they exist.
That said... It would be nice to have a UI interval timer bit and also a log entry to report the offset when NTP syncs. Im curious to see how much time Im losing in a week.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Wed May 18, 2022 9:08 Post subject:
Well, have a nice time or try to enjoy yourself during your travels.
Re: usefulness;
UI option to manipulate ntp_timer: this is not hidden on most platforms from UI, personally Im against hidden knobs unless there are real risks associated with them, this one seems harmless enough and offers it to novice users who are afraid of a terminal.
Quite a few long time users weren't even aware of this (judging from their replies). terrible if you ask me.
Personally for me, I,m comfortable with how it is but wont kick it out of the bed.
Time Offset; To know how far behind your router is when using larger interval times and then one can decide if the interval vs offset is desired and so adjust things accordingly.
Without the offset time after the update one cant really make any determination or adjustments.
Would be nice to add the ntp update offset on sync syslog logging so we can determine which interval works best vs the time lost during the current interval set.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu May 19, 2022 18:50 Post subject:
so to let you guys know that https://svn.dd-wrt.com/changeset/48931 adds a offset syslog report, so now we can make a judgement based on the drift between the time set and the difference when taking in consideration the interval set.
Then the ntp interval can be set to a value that more appropriate to what the individual needs are.
Note that most routers as noted by BS, dont have a RTC, so this is a software clock and depending on routers load it may worsen the offset.
Use wisely and responsibly. BS recommends default 3600sec or 1 hour (so that scheduled tasks dont go awry aka cron dependent anything).
Obviously within his use case doesn't care about log spam or the constant related services restarting on each NTP sync or how that affects regular usage for real world users that dont want the constant interruptions in services due to constant service restarts.