Hi Albert,

> The clock and the RTC are two different things.
Of course they are.
In my opinion, RTC in dnsmasq terms shouldn't be literally treated as it 
exactly is, but as main (original) reason leads to local time available to 
application is not equal to real time.
If platform has no RTC chip, NTP is the almost only time source, so time shifts 
are expeted.
If platform has RTC chip, but system clock source is inaccurate and NTP "fixes" 
it from time to time - time shifts are expeted.
If platform has RTC chip, but is has wrong value (battery failure/etc) - time 
shifts are expected.
All expected time shifts cases require HAVE_BROKEN_RTC to be define for normal 
flow.
There's nothing to fix here, because here nothing is broken.

> But timeouts can occur, TTLs can get past, etc. To treat those properly,
> dnsmasq needs to know how much time has flown while it was sleeping (if
> it ever does, of course).

It does (actually not due sleeping, more likely to timer granulation), can be 
easily checked in code.
Despite the fact that sleeping DHCP/DNS servers looks quite ridiculous, if 
dnsmasq code without HAVE_BROKEN_RTC has issue with time goes backward too 
much, it needs to be fixed.
Not with changing the clock source, because it'll just mask the problem, but 
with proper dealing with such kind of time values.
And, seems John have already found last_change variable wasn't static, didn’t 
check it by myself yet.

Best Regards, Vladislav Grishenko


> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Friday, October 14, 2016 7:04 PM
> To: Vladislav Grishenko <themiron...@gmail.com>
> Cc: 'John Knight' <john.kni...@belkin.com>; dnsmasq-
> disc...@lists.thekelleys.org.uk; 'Simon Kelley' <si...@thekelleys.org.uk>
> Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
> 
> Hi Vladislav,
> 
> Le Fri, 14 Oct 2016 11:52:33 +0500
> "Vladislav Grishenko" <themiron...@gmail.com> a écrit:
> 
> > Hi, Albert,
> >
> > > 1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we
> > > are not dealing with broken RTC.
> >
> > Root issue from original mail:
> > > One of which acknowledges potential problem if the clock goes
> > > backwards...
> > As for me it's indeed broken RTC behavior, not?
> 
> The clock and the RTC are two different things.
> 
> The RTC is what keeps time in between power-offs. It has backup power
> (frequently on PCs it is a CR20xx battery) and a slow autonomous clock
> source (typically a 32 kHz crystal). IT is not set or read frequently
> while the system is on, because it is usually slow to access.
> 
> So while it is on, the system keeps track of the time not through the
> RTC but through some internal clock reference which is easier and
> faster to read and set. It is this clock reference which gets read
> every time a process needs to known what time is "now", and it is what
> gets affected by NTP etc.
> 
> > > 2. The man mage for times() states that "a portable application
> > > would be wise to avoid using [the] value [returned by times()]. To
> > > measure changes in elapsed time, use clock_gettime(2) instead".
> >
> > Because start value of posix's times() return value may vary across
> > kernel versions & UNIX impl., combined with possibility of value
> > overflow the clock_t range. Since we don’t care neither about initial
> > boot value nor about sleep/suspended time (files can't be modified
> > when suspended, right?)
> 
> But timeouts can occur, TTLs can get past, etc. To treat those properly,
> dnsmasq needs to know how much time has flown while it was sleeping (if
> it ever does, of course).
> 
> > - the only possible issue is overflow. Since
> > times() not counting CPU ticks in sleep/supspended mode, suggestion
> > clock_gettime here is about using CLOCK_MONOTONIC which is almost the
> > same, but with no-overflow API.
> 
> Hm... I believe that's what my proposal amounts to on systems where
> CLOCK_BOOTTIME is not available.
> 
> > > - otherwise, if CLOCK_MONOTONIC is defined (it should always) and if
> > >   clock_gettime(CLOCK_MONOTONIC,...) succeeds at run time, use
> > > that;
> >
> > Even with defined CLOCK_MONOTONIC, the real presence of this clock
> > source can be retrieved from kernel in runtime only.
> 
> Indeed, hence my double test suggestion: one must test the existence
> of CLOCK_MONOTONIC and only call clock_gettime(CLOCK_MONOTONIC...)
> if
> it exists, and mone must test the return value of clock_gettime() in
> case dnsmasq runs on an older kernel/glic than it was compiled and
> built against.
> 
> > Yes, there're
> > old running kernels with no CLOCK_MONOTONIC, clock_gettime() returns
> > EINVAL. Same check is true for CLOCK_BOOTTIME.
> 
> Exact, hence my "returns success" conditional.
> 
> > Best Regards, Vladislav Grishenko
> 
> Amicalement,
> --
> Albert.


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to