bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: timestamp resolution


From: Joseph M Gwinn
Subject: Re: timestamp resolution
Date: Thu, 10 May 2007 14:42:35 -0400

Hans,

Hans Aberg <address@hidden> wrote on 05/10/2007 09:09:59 AM:

> On 9 May 2007, at 16:30, Joseph M Gwinn wrote:
> 
> > In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an
> > unspecified offset because POSIX counts ~SI seconds regardless of
> > astronomy and thus leap anything.
> 
> I think the specs ignore the issue, so it is only accurate within a 
> couple of ten seconds. I figure typical system just ignore the leap 
> seconds from the epoch, and adjusts the internal clock on the first 
> lookup after the time server has changed. It is these jumps in the 
> internal clock that may pose a problem: it is hard to tell which 
> computer that have adjusted and which have not.

The POSIX.1 standard is very specific, and each and every word was 
hard-fought.  I would parse it (and the corresponding Rationale) very 
slowly and carefully.  Even the things not said are important.

There is no intent to put astronomical or attosecond time in the POSIX 
core.  The intent is to support file timestamps and realtime timers and 
timeouts and the like. 

Nor do astronomers need their various clocks built into the operating 
system, as for the astronomers time is just another kind of data, as they 
compute events remote from the here and now.  Likewise physicists.

 
> If one would follow the suggestion of using a TAI-JD the way I did, 
> one would end up with a system that ignores the leap system in the 
> internal second count, from the epoch. It means that one must have 
> time servers that do not introduce a jump when a leap second appears. 
> Instead, when a human readable time stamp occurs, one makes a lookup 
> from a file, that adjusts the time accordingly.

One can already use NTP to slave ones computer to GPS System Time to 
achieve this.  All the big radars I work on do just that.  Set the GPS 
receiver to emit "GPS time" (not "UTC"), and point NTP in the workstations 
and servers to the NTP server attached to that GPS receiver.


> > (The fact that ordinary computer clock
> > hardware isn't nearly as accurate as that collection of caesium beam
> > clocks is neither here nor there - it's the semantics of the 
> > timescale, not its accuracy, that counts here.)
> 
> Right. The idea is not to impose a system on the current hardware, 
> but admitting future hardware with more accurate clocks to adjust at 
> need. This need not only to be file time stamps, but say distributed 
> ronoting, or something.

Ronoting?

 
> > POSIX time cannot actually be TAI bacause not all POSIX systems have
> > access to (or need for) time that's accurate with respect to any 
> > external timescale.  Think isolated networks with no access to the 
sky.
> 
> A completely isolated system only needs adjustment to its one and 
> only clock. In a distributed setting, be it over the network, or by 
> radio broadcasts, need access to time servers which do not introduce 
> a leap second in the count.

Don't assume that an isolated system can only be a single computer with a 
single clock.  The big radars for instance consist of tens of computers, 
many network components, and two GPS receivers (and associated NTP 
timeservers), all in a ten story high building.

 
> > As for the choice of the one true clock, the original and still a core
> > reason for POSIX to care about time is to support causal ordering 
> > of file updates by comparison of timestamps.
> >
> > The granularity issue has always been with us.  While it is known 
> > that no finite-resolution timestamp scheme can ensure causal order, 
the
> > alternative (a central guaranteed-sequence hardware utility) is 
usually
> > impractical, so people have always used timestamps.  (IBM sells such a
> > utility box for use in their transaction systems.)  What one can most
> > easily do is to require much better timestamp resolution as technology
> > progresses, thus reducing the window of non-causality in such 
> > things as make.
> 
> Different system will require different granularity. The interesting 
> thing is that a high performance system distributed around planet 
> Earth might in principle have an accuracy of 10^-7 seconds.

One can actually do far better than that already, but it's expensive. 
Again, astronomers were the pioneers.  Look into VLBIs (Very Long Baseline 
Interferometers).  Also the HP app note "TheScienceOfTimekeeping.pdf" has 
a nice summary of the precision achievable by various methods.

Joe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]