On Tue, 22 Jul 2003, Ralf Baechle wrote: > > It's already questionable whether the update should be done at all (this > > was discussed zillion of times at the NTP group) and it disrupts > > timekeeping of the DECstation severely, but given the current choice, I'd > > prefer to make it as lightweight as possible. > > 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. > If in that situation we only update the time the RTC will stay way far Hmm, any problems with `ntpdate <your_server>; hwclock -uw'? Plus a lone `hwclock -uw' before a graceful halt/reboot? That's a typical userland task and a trivial one, actually. > from reality. Another case would be updates of the time near midnight > where the RTC and NTP date happen to just differ. That's why rtc_set_mmss() never does an update that would require a change to hours -- it defers it with a "set_rtc_mmss: can't update from x to y" message. > I share your dislike of updating the RTC for performance reasons; these > 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 > > ? I really see no point in doing it at all -- it's all easier and more flexible to be done in the userland. > > 5. Leap years are handled properly. > > Good thing. People at times do run their systems with clocks set wrongly, > even intensionally. So I blame (year % 4) == 0 for being a too trivial > view of the world. Well, that's actually just the Julian view. There were a number of surprising discoveries in code here and there wrt the y2k leap year exception -- apparently a number of people involved in coding were not aware of the full Gregorian Calendar leap year rule, even though doing that stuff should make them obliged to. Somehow the rule was already known to me many years ago, certainly before y2k and probably even before I got involved with computers... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
