Date: Fri, 26 Oct 2001 10:48:10 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110261748.NAA22627@rodney.cnchost.com> In-Reply-To: Your message of "Fri, 26 Oct 2001 08:28:14 %2B0200." <23015.1004077694@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> We are now routinely talking about GHz+ CPUs, but struct timespec
> can only do nanosecond resolution and arithmetic on timeval and
> timespec sux badly.
> I would like for us to introduce a new format of timestamps:
> struct time$something {
> time_t tx_sec; /* 64bit */
> uint_64_t tx_fsec; /* binary fraction of second */;
> }
>
> If we have access to a int_128_t type, we could instead simply
> define a scalar type 128 bits wide, resolved in 1/(1<<64) seconds
> (.0542E-18 == .0542 attoseconds)
>
> This format would be faster for any kind of arithmetic, including
> inside the timecounter code, and it would have sufficient bits in
> both directions for any forseeable future.
A 64 bit time_t with nanosecond resolution would last you,
let us see... 2^64/10^9/86400/365.25 or 584 years. Do we
really need timespec or 128 bit time values? Yes, this is
short sighted but 500+ years is a long enough time to develop
128 bit time. So I say abolish clunky structs like timespec
and timeval in favor of a 64 bit time type (or 128 bit, if
you can convince people).
IMHO there is not much point in using file timestamps of
resolutions less than 1 ns -- that is about 1 foot of travel
at the speed of light. Note that even a ns resolution will
cause problems on a multi-processor system where cpu nodes
are more than a foot or so apart -- a parallel make may
allocate jobs to processor nodes in such a way that a file
created later will have an earlier timestamp. Even if you
synchronize them your processor interconnect has to provide
predictable times to deliver data from node A to node B --
this is not usually the case. So I believe you need < ns
resolution only when a *single* node can update files faster
than a ns.
For specialized applications such as test equipment one may
need finer resolution but usually such embedded applications
don't run for 500 years continuously.
Perhaps the 64 bit time_t should be named longtime_t --
actually that is a serious suggestion! There is no need to
retire the 32 bit time_t -- we will have to deal with old
dump tapes and saved file systems for a long time so we will
need it in some form. So, just like ascii (char) and unicode
(wchar_t), why define a _new_ time type and insist people
start using that for new software? Then the current time_t
is valid only in the first "epoch".
Okay, how about this? Define N types that will be
*exactly* the same on *all* machines:
time_t 32 bits (1 second resolution, upto yr 2038)
nstime64_t 64 bits (10^-9 second resolution, upto yr 2554)
zstime128_t 128 bits (10^-21 second resolution, 10 billion yrs)
zs prefix because 10^-21 == zopto.
On-storage structures should use one of the three above
types. Perhaps the superblock or header should contain a
zstime128_t value indicating the base epoch (a point in
time). Add more types if you wish but please, abolish the
clunky timespec and timeval altogether!
BTW, this discussion should be conducted on comp.std.internat
as it affects all OSes, not just FreeBSD.
-- bakul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110261748.NAA22627>