NTP FAQ [#1, #2, D. Mills] - Articles (part 23)

Previous part

From: zlsiial@cfs2.mcc.ac.uk (Dr A O V Le Blanc) Date: 16 Aug 1997 17:04:21 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: What sort of synchronisation is "normal"?

ashtray@replicant.apana.org.au (John Newnham) writes:

>Some questions. In the proto-FAQ for this group is the following text: ... > Clock > synchronization at the 10-millisecond level over long distance > (2000 km) WANs, and at the 1-milllisecond level for LANs, is > routinely achieved.

>What sort of accuracy do most people on this newsgroup get?

On our HPs and Suns we usually get remote accuracy of 1 to 10 milliseconds over long distances, and of about half a millisecond on the local net.

>For reference, the xntpd which I run (and wish to improve) >is on a 486 running linux, on a bursty and relatively >low-bandwidth network, in a room of varying temperature.

Current versions of Linux (at least the stable versions 2.0.29 and 2.0.30) don't seem to be easy to tune well. We very often see the ntp.drift file reach its maximum value, even after weeks of careful tinkering with the tick values. This is one reason why I suggested earlier that ntp be at least configurable to manage its own tick and tickadj as well as drift values.

>What factors affect it most - > computing hardware? (VAXen vs. PC) > operating system? (SunOS vs. anything...) > network connection? (latency? bandwidth?) > physical environment? > tuning by the administrator?

All of these affect the accuracy of the software, but I've seen some heavily loaded, cheap old Suns and HPs with more or less everything against them still keep very accurate time with xntp.

-- Owen LeBlanc@mcc.ac.uk

From: jkb@mrc-lmb.cam.ac.uk (James Bonfield) Date: 12 Aug 1997 10:10:04 GMT Newsgroups: comp.protocols.time.ntp,comp.sys.sgi.admin Subject: Re: xntpd 3-5.90.3 and IRIX 6.3 (R10000).

In article <5sfnat$7q2@sifon.cc.mcgill.ca> malin@nil.mni.mcgill.ca writes: >Until I stumbled on one host, an SGI O2 R10000, running >IRIX 6.3, a 64 bit kernel. At first this guy was chiming >alright, then after a reboot, refused to go along... >started drifting up to 200 secs/day off the servers...

We had an identical situation with an O2 & Irix 6.3, except that we had around 300 secs/day drift. The solution (thanks to Jon Peatfield for helping me here) was to use the timetrim program. This comes with newer xntp distributions, in the utils directory. It uses an SGI specific system call to adjust a kernel time skewing paramater. The kernel limits this skew to 0.3%, which in my case wasn't enough. However as long as you're close enough (which we apparently were) xntp can take over from there. Read the top of the timetrim.c file for some brief docs.

However I'd like to know how come these systems have such TERRIBLE time keeping. Our's was so bad that it wouldn't even be within a day if you left it alone for a year or so.

James -- James Bonfield (jkb@mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/

From: Casey Crellin <casey@ccii.REMOVE_THIS.co.za> Date: Fri, 15 Aug 1997 08:56:33 +0200 Newsgroups: comp.protocols.time.ntp Subject: Re: ntp on VXWorks MC68020 system?

Mike Mohar wrote:

> After a quick review of the docs, it didn't look like > ntp source has been targeted for a 68020 system? Has > anyone cross compiled it to this arch.?

It should soon compile for all vxWorks targets - at least those using the Tornado environment, look out for xntp3-5.90.3a.tar.gz or later these have the patches for vxWorks cross-compile.

Providing the only difference is the endianess, it should compile without problem after following the vxworks.html file.

Casey -- Casey Crellin

CCII Systems (Pty) Ltd http://www.ccii.co.za ------------------------------------------------------------------------

From: robk@oldtimer.win-uk.net (Robin Kimberley) Date: Thu, 14 Aug 1997 17:31:09 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: SNMP and NTP

In article <33F2A6BB.3F7E@abm.com.au>, Carl Brewer (carl@abm.com.au) writes: >Casey Crellin wrote: >> >> Are there any plans for an MIB for ntp? >> >> Has anyone ever implemented one?

Datum's TS2100 Network Time Server provides NTP and has SNTP with MIB as standard. Try Datum's web site www.datum.com and go to the Bancomm-Timing division.

Rgds

Rob Kimberley

From: Paul Skoog <pskoog@truetime.com> Date: Fri, 15 Aug 1997 07:54:12 -0700 Newsgroups: comp.protocols.time.ntp Subject: Re: SNMP and NTP

Casey Crellin wrote: > > Are there any plans for an MIB for ntp? > > Has anyone ever implemented one? >

TrueTime offers the NTS-100 Network Time Server which provides SNTP with a MIB and MD5 authentication standard as well. They have a new web site under construction at www.truetime.com with all the current information(first link takes you to the new site).

--Paul Skoog

From: Carl Brewer <carl@abm.com.au> Date: Thu, 14 Aug 1997 16:33:31 +1000 Newsgroups: comp.protocols.time.ntp Subject: Re: SNMP and NTP

Casey Crellin wrote: > > Are there any plans for an MIB for ntp? > > Has anyone ever implemented one? > > My initial thought to this was why not use ntpq/xntpdc, but if the would > be querier does not have these > it seems valid to supply this info to SNMP. > > Anyone got 2c worth on this?

I was just thinking of exactly the same thing today.

It would be great to be able to configure SNM (for example) to monitor if your NTP stuff was sync'ing, and generate an alert if it died, or switched over to its local hardware clock etc.

I guess the MIB would take some thought, but it'd be pretty seriously useful.

From: robk@oldtimer.win-uk.net (Robin Kimberley) Date: Fri, 15 Aug 1997 21:22:21 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: SNMP and NTP

In article <33F46D94.1217@truetime.com>, Paul Skoog (pskoog@truetime.com) writes: >Casey Crellin wrote: >> >> Are there any plans for an MIB for ntp? >> >> Has anyone ever implemented one? >> > > >TrueTime offers the NTS-100 Network Time Server which provides SNTP with >a MIB and MD5 authentication standard as well. They have a new web site >under construction at www.truetime.com with all the current >information(first link takes you to the new site). > >--Paul Skoog

Hi Ya Paul,

Please give my very kind regards to all my old friends at Truetime, Rick Dielman, Mike Tope, Greg Kret - but I still reckon the Datum TS2100 is a far far better box (and yes it also has MD5).

Cheers

Rob Kimberley

From: robin@acm.nospam.org (Robin O'Leary) Date: 18 Aug 1997 21:21:20 +0100 Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

In article <5t9nlc$f6v$1@netnews.upenn.edu>, Paul Hughett <hughett@galton.psycha.upenn.edu> wrote: >Actually, as far as I know, both Unix and NTP use TAI internally and >convert to UTC only for external output to the users. The time in >Unix systems is kept as the number of seconds since the beginning of >1970; the exact definition of the second is not specified but is >presumably the atomic second. Thus, the Unix time variable is TAI >minus an offset equal to TAI at the beginning of the epoch. >Similarly, the time values passed around by NTP are also just the >number of second since the epoch, or TAI.

Good idea though it is, unfortunately, this does not seem to be current practice. I wish it were. A literal reading of the POSIX specification for gettimeofday() does indeed suggest that this is required for conformance, but certainly Linux, which is quite aggressively POSIX-compliant in most respects, works in UTC. This is something I am working on:-)

>When you ask for the date in Unix, the system converts to YYYYMMDD >HHMMSS, including the necessary corrections for time zone, leap years, >daylight savings time, and leap seconds. Except for leap years, which >are hardwired into the code, this information is kept in a file >/etc/localtime (the location varies with different Unix systems); >information for other time zones is kept in /usr/lib/zoneinfo (again, >this varies). There is a program called zic which creates these >timezone files from a human-readable format.

I would like to know what Unix system you are on. The BSD C library knows a bit about leap seconds, but it still appears to expect time-of-day-seconds and timestamps on files to be in UTC. Try this rather crude test on your system to check:

#include <stdio.h> #include <time.h> #include <sys/time.h>

int main(int argc, char *argv[]) { struct timeval secs_and_usecs_since_1970; time_t secs_since_1970; struct tm *now; gettimeofday(&secs_and_usecs_since_1970, NULL); secs_since_1970 = secs_and_usecs_since_1970.tv_sec; now=localtime(&secs_since_1970); printf("gettimeofday returns %s\n", (now->tm_sec == (secs_since_1970 % 60))?"UTC":"TAI(?)"); }

It says UTC on Linux, and a look at the kernel source confirms that (if told to do so by some external agent like NTP) the kernel warps its internal second-keeping clock on leap-seconds.

> [snip]

>Marc is absolutely correct in saying that keeping TAI internally and >displaying UTC externally is complex and (if you're careless) error >prone; nevertheless, that is how it is actually done in Unix and NTP.

Again, I wish it weren't, but NTP is definitely UTC-only. See RFC1305 which I cited earlier in this thread for confirmation and (IMHO weak) justification for this decision. It is because NTP uses UTC not TAI that we are having this discussion in comp.protocols.time.ntp!

Robin O'Leary. -- <robin@nospam.acm.org> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.

From: nmm1@cus.cam.ac.uk (Nick Maclaren) Date: 21 Aug 1997 13:25:28 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

In article <5tbs1v$kgg@swan.ml.org>, Robin O'Leary <robin@acm.nospam.org> wrote: >In article <33F8F6C3.3C7F@erols.com>, The Browns <suneedle@erols.com> wrote: > >>Ultimately, we will need every part of the implementation to accomodate >>both TAI and UTC and that won't come quickly. > >I believe it can come quickly once NTP does its bit in distributing TAI >and TAI-UTC. The GNU libc code already has all the necessary leap-second >handling stuff in ready, and with those two layers fixed, applications >should be completely unaware of the change.

Unfortunately, this statement is the converse of the truth.

Having both UTC and TAI at every layer would cause complete chaos, because one application would write a timestamp using one and another would check it using the other. We already have this with local times. The ONLY sane way is to use TAI as the base clock, convert to UTC higher up and then convert to local time in some applications.

The important point that most conversions of time_t objects are not done using well-defined and standard interfaces. They are both used as unique, increasing timestamps AND as the Unix/POSIX-mangled time since a virtual epoch. And the second form is very often converted to and from other formats directly (i.e. not via the C library).

If you think that this is unreasonable, consider the problem of converting MVS TOD timestamps to Unix time_t - the former are long seconds (1.04576 seconds) since a different epoch! And then start considering what can be done with timestamps embedded in old files (e.g. file update times); it is CRITICAL to know whether they are TAI or UTC.

Given the fact that POSIX has canonised the lunatic behaviour of broken C libraries, and the misbegotten half-UTC is used so much in external and data protocols, there is virtually no chance of changing to TAI. This is a pity, but such is life :-(

Nick Maclaren, University of Cambridge Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

From: The Browns <suneedle@erols.com> Date: Mon, 18 Aug 1997 21:28:35 -0400 Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

Much has been said on both sides of the TAI-UTC in this thread in the last few days. Some people think our computers and NTP should maintain time as TAI because either a) it's a philosophical issue or b) they know of applications where accurate counting and timing of every second is important. Others think we should use UTC because either a) it's a philosophical issue or b) they know of applications where matching legal time is important.

I think the important thing, pointed out by some, is that there are needs for both ways of tracking time and we need a mechanism to do that. Certainly changing from UTC to TAI just changes who is happy and who isn't and makes a bunch of people change existing code (a la Year 2000) to accomodate it.

We then get into a chicken and egg discussion about why different pieces (UNIX, NTP, clocks, etc.) won't work one way or the other. Ultimately, we will need every part of the implementation to accomodate both TAI and UTC and that won't come quickly. It would be useful, though, to focus the discussion on what the final result might look like and how to get from here to there.

It seems to me we need all of these:

1. A time structure in each OS that tells us both TAI and UTC 2. A way to tell the OS how we want to see the time 3. A way to tell the OS whether we want to see 23:59:60 or to see a clock running at half speed for two seconds starting at 23:59:59.0. 4. An NTP that communicates both TAI and UTC in a robust way 5. A procedure for reliably entering leap-second announcements into the system, whether the hardware clock supports them or not.

I think we can attack the NTP piece now (while getting a jump on the year 2038 problem :-)). Maybe someday the OS vendors will follow along.

Jerry Brown

From: djb@koobera.math.uic.edu (D. J. Bernstein) Date: 19 Aug 1997 08:09:31 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

In article <33F8F6C3.3C7F@erols.com>, The Browns <suneedle@erols.com> wrote: > Others think we should use UTC because either a) it's a > philosophical issue or b) they know of applications where matching legal > time is important.

1. Legal time here in Chicago is not UTC. It's CST/CDT.

2. The NTP time scale is a bastardized version of UTC; it cannot be converted reliably to UTC, TAI, or any other useful time scale.

3. Real systems are not synchronized to UTC, at least during leap seconds; working applications cannot depend on time_t matching UTC.

4. Olson's time library already supports TAI time_t. It handles leap seconds in localtime() and mktime().

> 1. A time structure in each OS that tells us both TAI and UTC

This already exists. There's time_t for a numerical version of TAI, and struct tm for UTC.

> 2. A way to tell the OS how we want to see the time

This already exists. It's the TZ environment variable.

> 3. A way to tell the OS whether we want to see 23:59:60 or to see a > clock running at half speed for two seconds starting at 23:59:59.0.

What for? Who wants a half-speed clock?

> 4. An NTP that communicates both TAI and UTC in a robust way

TAI is the crucial part. The OS already needs a leap-second table if it wants to handle times correctly; the current TAI-UTC difference is unnecessary if this table exists and insufficient if it doesn't exist.

> I think we can attack the NTP piece now (while getting a jump on the > year 2038 problem :-)).

See http://pobox.com/~djb/proto/tai64.txt.

---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: robin@acm.nospam.org (Robin O'Leary) Date: 19 Aug 1997 11:20:47 +0100 Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

In article <33F8F6C3.3C7F@erols.com>, The Browns <suneedle@erols.com> wrote: >... >I think the important thing, pointed out by some, is that there are >needs for both ways of tracking time and we need a mechanism to do >that. Certainly changing from UTC to TAI just changes who is happy and >who isn't and makes a bunch of people change existing code (a la Year >2000) to accomodate it. >We then get into a chicken and egg discussion about why different >pieces (UNIX, NTP, clocks, etc.) won't work one way or the other.

Everyone who wants change agrees that we need both standards. This has never been in dispute. The only dissenters are those who want NTP to continue only on UTC and somehow expect those who need TAI to make their own arrangements to get it. There are no circular arguments here.

>Ultimately, we will need every part of the implementation to accomodate >both TAI and UTC and that won't come quickly.

I believe it can come quickly once NTP does its bit in distributing TAI and TAI-UTC. The GNU libc code already has all the necessary leap-second handling stuff in ready, and with those two layers fixed, applications should be completely unaware of the change.

>It would be useful, >though, to focus the discussion on what the final result might look like >and how to get from here to there. A good plan.

>It seems to me we need all of these: > >1. A time structure in each OS that tells us both TAI and UTC Yes. Perhaps it would be more explicitly accurate to say ``A time structure from which both TAI and UTC may be calculated.''

>2. A way to tell the OS how we want to see the time The POSIX gettimeofday() is supposed to return seconds since epoch anyway, so gives us TAI directly. The conversion functions respect the setting of the time-zone, so if we can treat TAI like an extra time-zone, the user-level notification mechanism is already there. I presume nobody really wants to be able to ask for something like TAI+8+daylight saving time, but if they do it just means creating copies of the relevant UTC time-zones but omitting the leap-second conversion.

>3. A way to tell the OS whether we want to see 23:59:60 or to see a >clock running at half speed for two seconds starting at 23:59:59.0. I don't think the latter should be an available option. It is neither TAI nor UTC, and I don't think we are in a position to justify the creation of new timescales.

>4. An NTP that communicates both TAI and UTC in a robust way Rather, ``An NTP that can communicate any or all of TAI, UTC, TAI-UTC, current or planned, in a robust way.'' That covers the four types of information we may be able to acquire from refclocks or IERS.

>5. A procedure for reliably entering leap-second announcements into the >system, whether the hardware clock supports them or not. Agreed. Actually there are several issues here: remembering historical leap seconds in a file so that the library time conversion code can convert arbitrary times when it is asked for UTC, telling the kernel the current TAI-UTC offset, and telling NTP to distribute notification of TAI-UTC and future leap seconds.

>I think we can attack the NTP piece now (while getting a jump on the >year 2038 problem :-)). Maybe someday the OS vendors will follow along. Agreed.

Who wants to help start a new RFC?

Robin O'Leary. -- <robin@acm.org.nospam> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.

From: robin@acm.nospam.org (Robin O'Leary) Date: 19 Aug 1997 11:20:47 +0100 Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

>Ultimately, we will need every part of the implementation to accomodate >both TAI and UTC and that won't come quickly.

>It would be useful, >though, to focus the discussion on what the final result might look like >and how to get from here to there. A good plan.

>I think we can attack the NTP piece now (while getting a jump on the >year 2038 problem :-)). Maybe someday the OS vendors will follow along. Agreed.

Who wants to help start a new RFC?

Robin O'Leary. -- <robin@acm.org.nospam> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.

From: James Youngman <JYoungman@vggas.com> Date: 21 Aug 1997 16:07:02 +0100 Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

>>>>> "Nick" == Nick Maclaren <nmm1@cus.cam.ac.uk> writes:

Nick> The important point that most conversions of time_t objects Nick> are not done using well-defined and standard interfaces. They Nick> are both used as unique, increasing timestamps AND as the Nick> Unix/POSIX-mangled time since a virtual epoch. And the second Nick> form is very often converted to and from other formats Nick> directly (i.e. not via the C library).

I really wish that time_t had not been specified to be an arithmetic type. There really isn't a very good reason for having it so.

Nick> If you think that this is unreasonable, consider the problem Nick> of converting MVS TOD timestamps to Unix time_t - the former Nick> are long seconds (1.04576 seconds) since a different epoch!

At least, modulo leap seconds, this is unique. OTOH, leap seconds are the problem under discussuion.

Nick> And then start considering what can be done with timestamps Nick> embedded in old files (e.g. file update times); it is CRITICAL Nick> to know whether they are TAI or UTC.

Mmm.

Nick> Given the fact that POSIX has canonised the lunatic behaviour Nick> of broken C libraries, and the misbegotten half-UTC is used so Nick> much in external and data protocols, there is virtually no Nick> chance of changing to TAI. This is a pity, but such is life

IMHO it's a hardware problem not a software problem. The rotation of the Earth should be stabilised with rockets.

Tidal wave? What tidal wave?

From: nmm1@cus.cam.ac.uk (Nick Maclaren) Date: 21 Aug 1997 19:36:44 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

In article <5ti237$okt@swan.ml.org>, Robin O'Leary <robin@nospam.acm.org> wrote: >In article <5thfk8$889$1@lyra.csx.cam.ac.uk>, Nick Maclaren ><nmm1@cus.cam.ac.uk> wrote: >>Having both UTC and TAI at every layer would cause complete chaos, because >>one application would write a timestamp using one and another would check >>it using the other. We already have this with local times. The ONLY sane >>way is to use TAI as the base clock, convert to UTC higher up and then >>convert to local time in some applications. > >Having both UTC and TAI available is no more chaotic than having GMT, >BST, PDT and all the other civil time conventions. In any case, I >propose having only TAI in the kernel, with libc converting to and from >UTC whenever it would otherwise have performed a time-zone conversion. >Applications that work in local time won't notice a change at all; >those which only use ticks-since-1970 will work as they did before but >now subtractions and comparisons will work properly across leap-second >boundaries.

No, that won't work. At present, there is only one ticks-since-1970 format used under Unix - adding TAI increases this to two. You ARE correct that the human-readable formats already have this ambiguity, and it does cause complete chaos - try changing time zones between level 0 and 9 dumps, and then doing a full restore!

The KERNEL and NTP could easily use TAI, but the problem is the result of the time() function.

>The only applications which will behave differently are those which >communicate tick values with other non-TAI machines, or those which >convert from ticks to calendar time themselves. The former should >either fix their protocols or pass network-compatible values through >converters---as we already must with ntohl/htonl; the latter are getting >wrong answers whenever they compute times outside the current leap-second >era anyway so probably justify the cost of fixing if accuracy is really >important---and if accuracy isn't really important, well, they'll just >give answers which are a few seconds wrong.

Please be serious. There are hundreds of such protocols, few of which have any capability for alternative versions - consider tar, cpio, rcp and NFS alone. At present, they are all consistent to within 1 second, which is acceptable - you are proposing a 10-20 second variation.

>>The important point that most conversions of time_t objects are not >>done using well-defined and standard interfaces. They are both used as >>unique, increasing timestamps AND as the Unix/POSIX-mangled time since a >>virtual epoch. And the second form is very often converted to and from >>other formats directly (i.e. not via the C library). > >But POSIX-time is not suitable for use as an increasing timestamp, >nor can it be accurately converted to UTC beyond a span of a year or two >from the current time! > >>If you think that this is unreasonable, consider the problem of converting >>MVS TOD timestamps to Unix time_t - the former are long seconds (1.04576 >>seconds) since a different epoch! > >To convert to TAI would be a subtract, a multiply and an add. Not much >of a problem surely?

No - for ONE program. There are THOUSANDS of such programs. My remark was explaining why you idea of doing it in libc cannot be made to work.

>> And then start considering what can >>be done with timestamps embedded in old files (e.g. file update times); >>it is CRITICAL to know whether they are TAI or UTC. > >But we don't know what old time-stamps mean now! There have been 22 >different POSIX-approved timescales so far since the adoption of UTC in >1972, one for each leap-second (TAI+10, TAI+11,...TAI+31), and you can't >know which of those timescales was used for each of your timestamps. >If it had really been critical to you, you would have stored them in >TAI anyway!

As I mentioned above, they are consistent to within 1 second. Remember that timestamps (as distinct from dates) are always produced using the CURRENT timescale.

Nick Maclaren, University of Cambridge Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

From: robin@acm.nospam.org (Robin O'Leary) Date: 22 Aug 1997 21:42:48 +0100 Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions?

In article <21@oldtimer.win-uk.net>, Robin Kimberley <robk@oldtimer.win-uk.net> wrote: >Surely what you suggest is more chaotic - at least with GMT, BST etc >we are looking at whole hours only, whereas with TAI vs UTC we are >messing with odd numbers of seconds. It used to be just as easy to get hours (or half-hours in some parts of the world) wrong as it is to get seconds wrong. But we've had more years of experience with clocks and watches which can show up this size of error and consequently we have already made some engineering decisions, such as keeping our clocks in POSIX-time, to help avoid those problems. As our clocks get better, errors of 30 seconds or even fractions of a second become more important. That is, after all, why we run NTP.

>It is a similar problem to using GPS time vs UTC time. GPS transmits the number of leap-seconds too, so it is possible to convert between current GPS-time and POSIX-time. Using only NTP to obtain your time, even that isn't possible.

>If one was working in a closed environment, which didn't have to >interface with the outside World... ...one would need a timescale which didn't depend on the input of astronomers.

>...(which is slowing down guys) it would be perfectly acceptable, and >one could use any time scale one wanted:) Not acceptable even then. TAI would be the best choice. POSIX-time has ambiguous values in it and is therefore not suitable for any purpose which requires accuracy of the order of one second. And, as already remarked, you can't use POSIX-time on an isolated computer because the computer has to know where the leap-seconds are so it can leave them out of its counting.

>Let's keep one universal time - UTC. I have a better plan: let's keep one *really* universal time - TAI (assuming the laws of physics governing hyperfine transitions really are are universal). Of course, for use with our current legal civil time (UTC) and to achieve POSIX-compliance (shudder) we will also provide appropriate conversion functions,

Robin O'Leary. -- <robin@nospam.acm.org> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.

From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> Date: Tue, 19 Aug 1997 10:00:07 +0200 Newsgroups: comp.protocols.time.ntp Subject: Re: Future Directions? (long)

Robin O'Leary wrote: [several paragraphs about how a consistent TAI timescale is better than UTC]

> Agreed, it adds a layer of complexity. However, mapping current time > from TAI to UTC is child's play: you add a constant. You have to get > the constant from somewhere and that is potentially more difficult, > but remember that NTP already does distribute instantaneous leap > second information. Compare that with the difficulty of implementing > UTC correctly: how many programs that you use will let you enter the > perfectly valid UTC time 23:59:60 and process it correctly? Not many, > I'm sure. And ask any computer how old a file is in seconds and it's > almost certain to tell you the wrong answer if it was created before > the last leap second was added to UTC. Writing a function to compute > the number of seconds between two UTC times is not trivial because it > requires two table look-ups, and most program I have seen to do this > wrong or not at all! Performing the same calculation in TAI is > just subtraction.

I do agree that delta calculations in TAI seconds is very easy:

However, I don't believe anyone thinks TAI seconds (or UTC seconds or Unix seconds_since_1970) is a very useful way to present time/date information to humans.

If you want to keep all timestamps in TAI seconds, then you also need to fix all program and library code that converts between YYYY-MM-DD HH:MM:SS and (TAI/UTC/Unix) seconds.

If every program in the world used dynamic linking to an OS-supplied set of conversion functions, then this would be feasible.

Currently, IMHO, it is not so.

Terje

-- - <Terje.Mathisen@hda.hydro.com> Using self-discipline, see http://www.eiffel.com/discipline "almost all programming can be viewed as an exercise in caching"

From: Richard Coleman <coleman@math.gatech.edu> Date: 19 Aug 1997 04:51:56 -0400 Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

> > Who will maintain the TAI-UTC offset? > > That's a reasonable question. I would expect one person to watch IERS > warnings and distribute a table of leap seconds in an easily parsed > format (see, e.g., http://pobox.com/~djb/libtai/leapsecs.txt). All the > stratum-1 servers would pick up the file every few months. After that > it's up to the protocol.

We already have to do a similar task to update the list of root name servers for your local name server. I don't see why doing this same task for the TAI-UTC offset is any harder.

I agree that using TAI as the basic measurement of time for computer networks is a good thing.

Richard Coleman coleman@math.gatech.edu

From: Stuart Anderson <sba@srl.caltech.edu> Date: Wed, 20 Aug 1997 10:46:12 -0700 Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

I am confused when people refer to Unix time or xntpd as being UTC. On my Solaris box at least, the number of seconds returned by gettimeofday() is not the actual number of seconds since 0h UT 1 Jan 1970

Stated another way, if I subtract the timestamp over a long period of time (including a leap second) the answer is wrong.

Is this sort of behavior to be considered:

1) A bug in Solaris

2) A feature of the definition of Unix time as, "well sort of UTC"

-- Stuart Anderson sba@srl.caltech.edu PGP 2AA64B7D

From: Tom Lane <tgl@netcom.com> Date: Thu, 21 Aug 1997 04:35:26 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

Stuart Anderson <sba@srl.caltech.edu> writes: > Is this sort of behavior to be considered: > 1) A bug in Solaris > 2) A feature of the definition of Unix time as, "well sort of UTC"

Well, Solaris is not alone --- AFAIK no version of Unix has ever accounted for leap seconds.

Even if the standard C library routines did know about leap seconds, plenty of application programs do their own timekeeping calculations, and most of 'em assume there are exactly 86400 seconds per day, every day. (I've written some myself :-(. A common reason for doing so is the standard library's lack of support for dealing with timezones other than your own and GMT.)

And even if all the software were fully leap-sec-cognizant, you'd still be dependent on the local sysadmin to update a configuration table every time a new leap second is declared.

Bottom line is that properly handling leap second timekeeping is still well beyond the average state of practice. I don't think that Unix is any worse off than any other OS in this area...

regards, tom lane

From: "Marc Brett" <Marc.Brett@waii.com> Date: 21 Aug 1997 09:59:52 GMT Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

Stuart Anderson <sba@srl.caltech.edu> wrote: > I am confused when people refer to Unix time or xntpd as being > UTC. On my Solaris box at least, the number of seconds returned > by gettimeofday() is not the actual number of seconds since > 0h UT 1 Jan 1970

> Stated another way, if I subtract the timestamp over a long period > of time (including a leap second) the answer is wrong.

> Is this sort of behavior to be considered:

> 1) A bug in Solaris

> 2) A feature of the definition of Unix time as, "well sort of UTC"

The correct answer is "2".

The classic definition was only ever valid for the short interval from 1970-01-01 00:00:00 UT to 1971-12-31 23:59:69 (sic) UT.

With the introduction of leap seconds on 1972-01-01 00:00:00 UTC, the (new and improved!) Unix time scale actually started (with time_t=0) at 1970-01-01 00:00:10 UTc, fully 10 seconds adrift. Six months later, the Unix time scale again changed and time_t=0 was set to 1970-01-01 00:00:11 UTc. This pattern kept going, and so today (1997-08-21) time_t=0 is 1970-01-01 00:00:31 UTc.

[I use the term UTc because I can't figure out if it shopuld be UT or UTC, or indeed the even more ambiguous GMT. UTC didn't exist before 1972, so it can't be used. However, Unix time is an atomic (or at least quartz oscillator) time scale, so UT, an astronomical time scale defined by the earth's rotation, can't really be used. Hence my compromise, UTc].

Since 1970, there have been 22 different Unix time scales, each one completely valid only for the interval between leap second events. Most people just use the latest scale, which aligns perfectly with UTC, and accept that timing events before the last leap second or after the next one is either a) erroneous or b) complicated.

I hasten to add that all this is not necessarily a Bad Thing. The logistical problems of trying to stick narrowly to the original definition of Unix time far outweigh the current confusion caused by the fuzziness of what, exactly, is meant by "Unix time".

-- Marc Brett +44 181 560 3160 Western Atlas Marc.Brett@waii.com 455 London Road, Isleworth FAX: +44 181 847 5711 Middlesex TW7 5AB England

From: eggert@twinsun.com (Paul Eggert) Date: 22 Aug 1997 18:03:38 -0700 Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

djb@koobera.math.uic.edu (D. J. Bernstein) writes:

> The Olson code uses 1970-01-01 00:00:10 TAI, which is > approximately 1.9 seconds different from 1970-01-01 00:00:00 UT.

To some extent we're talking angels-and-pinheads here, since in 1970 the Olson code didn't exist, nor did any POSIX.1 or Unix platforms exist to run it on. But the argument is pretty straightforward: the traditional Unix origin was ``midnight GMT'' on that date, and POSIX.1 clarified the ``GMT'' to mean UTC. And it is somewhat useful to have these definitions nailed down, so that POSIX.1 applications can reliably interchange timestamps back to 1970.

>(You've already made clear that by ``UTC'' you mean UT for dates before >1972. In any case, there are no standard time scales for which your >statement is correct.)

No, actually, by ``UTC'' I meant what the time authorities usually mean when they say ``UTC''. The International Earth Rotation Service (the body that decides when leap seconds occur) uses ``UTC'' to denote the Coordinated Universal Time regime that was in place before 1972. E.g. see: http://hpiers.obspm.fr/webiers/general/earthor/utc/table1.html

Granted, today's UTC method differs somewhat from the pre-1972 method. And I'll also grant you that timekeeping before 1972 was messier than it is today. But today's UTC method is not defined for times before 1972, and the only plausible way to interpret the POSIX.1 origin of 1970 is to use the UTC that was in effect in 1970.

From: eggert@twinsun.com (Paul Eggert) Date: 22 Aug 1997 18:38:38 -0700 Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

djb@koobera.math.uic.edu (D. J. Bernstein) writes:

>In practice, differences between time_t values are within +-0.1% of real >time differences, even across leap seconds. Most hosts don't run NTP.

I disagree. I think hosts that use POSIX.1-like time rules fall into three categories:

1. Hosts that run NTP and attempt to follow the POSIX.1 rules exactly. On these hosts, most time_t ticks are 1 second long, but when a leap second is introduced, the time_t tick is 2 seconds long.

2. Hosts that use adjtime() to adjust their clock so that there are not big jumps in the clock.

3. Hosts where people change the time by hand when it gets too far off.

I think the vast majority of such hosts fall into category (3). On these hosts, difference between time_t values are not within +-0.1% of real time differences when the clock jumps. The +-0.1% property does hold for category (2). I agree that very few hosts are in category (3) but in some sense the category-(3) hosts are doing the best job.

>you continue to talk about the POSIX time rules as if they were >something more than a description of fundamentally flawed time-date code >created many years ago by a few ignorant programmers.

I agree that there are many flaws in the POSIX time rules. I would like to have a better system in place. This will take a lot of work, and will require the cooperation of a lot of people. One way to get this cooperation would be to have a better system implemented, and to have it used in a few popular applications.

From: eggert@twinsun.com (Paul Eggert) Date: 22 Aug 1997 23:03:47 -0700 Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

djb@koobera.math.uic.edu (D. J. Bernstein) writes:

>Which makes more sense: adding leap-second support to a few routines >like localtime() and mktime(), or adding it to thousands of routines >that add and subtract time_t values?

Neither alternative is appealing; that's why few people do either, even though the source code for leap-second localtime is freely available. I've contributed a good deal of time to that effort, but it just isn't catching on. If we want leap second support to be widespread, we have to come up with a better way.

Robin O'Leary's proposal of augmenting NTP to broadcast both TAI and UTC is a promising way to attack this problem. But we shouldn't link this proposal to the idea of cramming leap seconds down localtime's throat: that's a sure way to scare potential users. We need a separate interface to the leap-second-aware mechanism.

>In the real world, most UNIX machines _never_ have their software clocks >readjusted.

Really? I don't know about your neck of the woods, but that isn't true around here. It may take a few weeks or months, but eventually someone gets annoyed with their box's clock being off (it breaks `make'-over-the-network among other things) and they fix it with rdate or call-the-phone-company-and-set-the-time. Around here the only Unix boxes that have _never_ had their clock readjusted are the boxes that were recently unpacked.

From: vjs@calcite.rhyolite.com (Vernon Schryver) Date: 23 Aug 1997 10:16:59 -0600 Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

In article <5tlug3$1v6$1@shade.twinsun.com>, Paul Eggert <eggert@twinsun.com> wrote:

> ... >>In the real world, most UNIX machines _never_ have their software clocks >>readjusted. > >Really? I don't know about your neck of the woods, but that isn't true >around here. It may take a few weeks or months, but eventually someone >gets annoyed with their box's clock being off (it breaks >`make'-over-the-network among other things) and they fix it with rdate >or call-the-phone-company-and-set-the-time. Around here the only Unix >boxes that have _never_ had their clock readjusted are the boxes that >were recently unpacked.

There are also commercial UNIX systems that are shipped with `timed` configured on by default precisely to deal with hassles such as `make`.

They may not amount to the majority. Causing all of the systems on the net to have the same time (+/- 10 ms) is not the same thing as causing them all to be within 10 ms of what the Naval Observatory says, and so might not qualify as whatever was meant by "readjusted."

Vernon Schryver vjs@rhyolite.com

From: Achim Gratz <gratz@ite.inf.tu-dresden.de> Date: 23 Aug 1997 11:22:11 +0200 Newsgroups: comp.protocols.time.ntp Subject: Re: Building a better time protocol using TAI

djb@koobera.math.uic.edu (D. J. Bernstein) writes:

> In the real world, most UNIX machines _never_ have their software clocks > readjusted. The software clock is set from a hardware clock at boot time > and then runs without outside intervention.

That is not true. After all, why would tickadj need the -s option if it were? Anyone doing network makes would care about the time also. That's why I got interested in NTP, anyway.

Achim Gratz.

--+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/{english/} E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 463 - 8325

Next part