Andrew Lentvorski wrote: > John H. Robinson, IV wrote: > >Those shops should be using clockspeed then. > > > >http://cr.yp.to/clockspeed.html > >http://cr.yp.to/proto/utctai.html > > Why use these? > > Especially since A) OpenNTP exists and B) NTP-type systems are > notoriously sensitive to very tiny details.
Because NTP does not use TAI. TAI does not have the problem with leap seconds that POSIX specifications do. TAI, Temps Atomique International (French for International Atomic Time), measures real time. One second of TAI time is a constant duration defined by cesium radiation. TAI has been measured continuously since 1955 and is the foundation of all civil time standards. TAI times are identified by year, month, day, hour, minute, and second. There are exactly 86400 TAI seconds in every TAI day. TAI days are labelled by the Gregorian calendar. ... UTC, Coordinated Universal Time, is based on TAI, and very similar to it, except that UTC has leap seconds every year or two. For example, here's how UTC and TAI handled the end of June 1997: 1997-06-30 23:59:59 UTC = 1997-07-01 00:00:29 TAI 1997-06-30 23:59:60 UTC = 1997-07-01 00:00:30 TAI 1997-07-01 00:00:00 UTC = 1997-07-01 00:00:31 TAI ... For many years, the UNIX localtime() time-display routine didn't support leap seconds. In effect it treated TAI as UTC. Its displays slipped 1 second away from the correct local time as each leap second passed. Nobody cared; clocks weren't set that accurately anyway. Unfortunately, xntpd, a program that synchronizes clocks using the Network Time Protocol, pandered to those broken localtime() libraries, at the expense of reliability. ... By resetting the clock at each leap second, xntpd extracts a correct UTC display (except, of course, during leap seconds) from the broken localtime() libraries. Meanwhile, it produces incorrect results for applications that add and subtract real times. ... It's easy enough to fix xntpd. It's also easy to fix localtime() to handle leap seconds. In fact, some vendors have already adopted Olson's time library. The main obstacle is POSIX. POSIX is a ``standard'' designed by a vendor consortium several years ago to eliminate progress and protect the installed base. The behavior of the broken localtime() libraries was documented and turned into a POSIX requirement. Up to you what you chose to do. My systems run NTP, but I have the luxury of not having to worry about time monotonicity. Additionally, we are talking about a step change at boot time, before the system can even be considered ready. Linux boot order: 0. kernel loads 1. system time set from hardware time 2. network comes up 3. ntpdate creates step change to known good time source 4. ntpd initiates clock skew to maintain steady time 5. applications are ready to be started Time monotonicity is available after step 4. Actually, after step 3, but the system time's idea of a second may not match the rest of the world's idea. This is what step 4 is for: to keep everything in sync. If the application requires time monotonicity before any clock synchronisation can occur, someone had better be spending a lot of money on very good hardware clocks. And a very good kernel. Something. -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
