Comment 3 for bug 1278359

I cannot see how making time sync calls even more sparse would not cause even more drift.

ntpdate is obsolete. I am not even sure why we still deploy it instead of ntp. Inertia, perhaps?

But this would not solve your issue: the replacement, be it NTP or openntpd, or whatever, still needs to keep the clock synchronised, so would still need to call NTP lock servers every so often. How often will depend, specifically, on the quality of your computer's RTC, and the importance you give to clock synchronisation. I do not think, in general, once per day is good enough. I think -- depending on the quality of your RTC -- from around one hour to, perhaps, a few hours would be good enough. If your RTC is so bad you need a sync call every few minutes, better get a more reliable machine. Certainly, and never, more than a day.

My personal view, and problem I see on using ntpdate, is actually the opposite of yours: I think ntpdate does NOT maintain clock synchronisation. Granted, it *does* sync the RTC at network up. Then, the RTC will slowly but surely drift. Given machines that more and more stay powered on & connected, one sync per network up is NOT enough. Instead, we should move to ntp or openntpd.