Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!mit-eddie!uw-beaver!sumax!quick!srg
From: srg@quick.com (Spencer Garrett)
Newsgroups: comp.arch
Subject: Re: Computer time measurements (Was Re: 64 bits for times....)
Message-ID: <1990Aug25.234133.20761@quick.com>
Date: 25 Aug 90 23:41:33 GMT
References: <26012@bellcore.bellcore.com> <11187@alice.UUCP> <1990Aug22.044826.18572@portia.Stanford.EDU>
Organization: Quicksilver Engineering, Seattle USA
Lines: 22

In article <1990Aug22.044826.18572@portia.Stanford.EDU>, kevinw@portia.Stanford.EDU (Kevin Rudd) writes:
> I am unclear as to the self measuring precision required of a computer
> system.  For example, I don't see the relevence of marking file time
> stamps to the 1ns increment...

I do.  I would like to be able to handle timestamps as follows:

Express timestamps in nominal nanoseconds, using 64 bit numbers.  This
allows timestamps to be valid for over 290 years from some epoch and
also both positive and negative differences within that span.  The
actual tick rate of the computer in question will be longer, probably
much longer (e.g. 100 Hz), and a tick will cause the timestamp value
to jump ahead to the next appropriate value.  Ticks will not likely
have the same value every time.  Every time someone needs a timestamp,
the current value of the counter is returned, *and then the counter
is incremented*.  It is necessary that no more than one timestamp be
issued per nanosecond.  This is not likely ever to be a bottleneck.
In this manner, timestamps are both unique and ordered, and are valid
times to within the precision of a normal coarse line clock.  Folks
like Dave Mills and Andy Glew will still need a much more precise
source of time, but the scheme I propose is perfectly adequate for
things like timestamps, and is easily implemented on any computer.