In message <20030722100444.GA4148@linux-mips.org> Ralf Baechle wrote:
> It's a common case to have a system boot up with the RTC date being
> completly off, then syncing via ntpdate and xntp to the accurate time.
Another common situation especially with embedded systems is that the
RTC holds the "correct" time, and probably runs at much higher
precision than the systm clock. In such systems, NTP can be used to
keep the system time in sync with the RTC, but the system time must
never be written back to the RTC. [Except when explicitely setting
> I share your dislike of updating the RTC for performance reasons; these
There are more problems with the 11 minute mode. We ran into this
issue for hard on some PowerPC systems. Assume a situation where the
RTC is connected through a I2C bus. Problem 1: normally the i2c
drivers will be loaded prety late, which means the system will run
initially with an undefined time. Problem 2: on some actions a i2c
transfer involves programming an on-chip i2c controller, which will
perform the task and then signal it's done by an interrupt. On such a
system the 11 minute mode will crash the system because rtc_set will
be called from interrupt contect itself.
There was a somewhat controverse discussion on the linuxppc_dev
mailing list, without a real solution.
> chips are impressive performance pigs. So how about updating the RTC
> date only when
> - write the time to the RTC for the first time after NTP synchronizes
> - write the time to the RTC if xtime.tv_sec <= last_rtc_update + 660
And never, ever update the RTC from interrupt context, please.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: firstname.lastname@example.org
"Free markets select for winning solutions." - Eric S. Raymond