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 the date&time.] > 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. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de "Free markets select for winning solutions." - Eric S. Raymond
