On Tuesday 17 June 2008, Alain Guibert wrote:
> On Monday, June 16, 2008 at 11:25:46 -0700, David Brownell wrote:
>
> > there should probably be a way to export a list of hardware "features"
> > (and misfeatures) of which that would be one
>
> Much thanks for your valuable input, Dave. That's actually an excellent
> idea, matching some of mines.
So we can start to accumulate a list of such features. Maybe:
struct rtc_stuff {
u32 settime_offset_ms; /* 500 on PCs */
u32 precision_ms; /* 1000 on most RTCs */
bool has_uie; /* irq on LSB update? */
bool has_pie; /* irq every 1/(2^n)? */
bool has_day_alarm; /* false on e.g. ds1307 */
bool has_month_alarm; /* false on original PCs */
bool has_year_alarm; /* true on many SOCs */
...
};
That'd need to grow a bit over time, and if it were retrieved using
some ioctl it'd have to cope with the usual 32/64 compatibility rules.
Probably worth pre-allocating some must-be-zero padding at the end,
to fill with new "features" as they are characterized.
Of course when the /dev interface isn't enabled, sysfs would need to
expose such stuff. So for now don't take that struct too seriously.
> > or at least to identify the RTC hardware through /dev operations.
>
> But then the knoweledge about the behaviour of each RTC type would have
> to be included into hwclock (and into each RTC-writing app), instead of
> into the corresponding driver. Workable, but somewhat less logical.
I don't like the idea of the *kernel* trying to impose that
much of a one-size-fits-all model on RTCs ... that's a way
to accumulate in-kernel bloat, not minimize it. There are
limits to the differences which can/should be hidden.
> >> All(?) RTC-setting apps work well out-of-the-box unmodified.
> > Busybox "hwclock" sure doesn't.
>
> Busybox is maybe not a totally appropriate example, because it makes no
> attempt to be precise besides the second granularity.
It trades off size for features, and expects that other tools
will be used (like NTP) if precision is a notable issue.
> ...
> This twice better "accuracy" probably justifies the inclusion of such
> restart delay by hardware designers 20 years ago. And pushes busybox
> into the pro-mimic camp.
There are other solutions, which is why that 20-year-old notion
hasn't caught on for newer discrete RTCs (which mostly seem to
work using I2C or SPI).
Note that your proposal was to model such a delay in the drivers.
I hope I showed why that's not good. But there could be a need
for such modeling in the infrastructure glue ... there is already
some code to cope with varying alarm ranges.
> > Does anything other than the util-linux(-ng) "hwclock" know about
> > this quirk of the PC RTC?
>
> - The mainline hwclock 2.33 by BJH at
> <URL:http://giraffe-data.com/software/about_hwclock.html>
>From my perspective, util-linux-ng is "mainline"! And I'd
expect that's the perspective of most folk on this list... :)
That doesn't build against Ubuntu 8.04, FWIW.
> manages
> half-second RTCs by default. The user of another RTC may get perfect
> results with the --correct=+0.5 option (or --correct=+0.495 on RTCs
> having 10 ms of non-resyncable granularity).
Better IMO to have the util-linux-ng RTC config file have an
option like that, and set it to 500 milliseconds on PC hardware.
A command line option could override that, or any default.
(The default should be 0 milliseconds ... not PC-specific.)
> - IINM the eleven-minutes mode of the Linux kernel, last time I looked,
> was scheduling the RTC write for the timer interrupt occuring at the
> closest to the middle of the second.
That's finally getting looked at. The previous code wrongly
assumed RTCs could always be written without sleeping. You'll
observe that when they connect using I2C or SPI, that's not
very practical.
> - Chrony 1.23 has a rather complicated "trimrtc" procedure, that will
> automatically adapt to whatever restart delay or not (by picking several
> verification ticks after the RTC_SET_TIME).
Sounds like something that should be done once as part of RTC
configuration for a given system, then stored away in the
config file along with timezone data etc. If there were a way
to interrogate RTCs as to their features, the "complicated"
scheme to deduce that value would not be needed...
> >> Applications timestamping the first tick following RTC_SET_TIME for
> >> verification
> > I'm trying to understand what, other than hwclock or a replacement
> > for it, would ever do that.
>
> As example I use wrapper scripts around hwclock doing that, in order to
> gather stats and syslog things like:
>
> | Jun 17 01:09:09 hwclockset: CMOS clock set:
> | Residual error +0.000068 s,
> | virtual error -0.000002 s.
> | Drift calculated -11.925593
> | reset to previous -11.870000.
> | Was last set 17618 seconds ago (4:53:38).
So: tools to monitor a given RTC against some other clock.
OK, worth while to have those. But I'm not sure how much
I should trust microsecond accuracy on such measurements;
or how much I should trust those other clocks!
It'd be nice to have generalized versions of those, which
would work for all clocksources.
> > Drawbacks of adding that requirement to drivers:
>
> Also I suppose that there could exist an RTC without restart delay, but
> without hundredth to be set to 50, nor other quick and easy trick to
> mimic a restart delay.
Having looked at several dozen I2C, SPI, and SOC based RTCs over
the past few years, only PC hardware has this notion of a restart
delay. So I feel quite comfortable saying that any program like
hwclock (whichever version) or "chrony" which assumes such a delay
will always exist and be 500 msec ... is PC-specific in at least
that respect.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
