Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Oct 2001 08:28:14 +0200
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Peter Wemm <peter@wemm.org>
Cc:        arch@FreeBSD.ORG
Subject:   Re: 64 bit times revisited.. 
Message-ID:  <23015.1004077694@critter.freebsd.dk>
In-Reply-To: Your message of "Thu, 25 Oct 2001 16:36:02 PDT." <20011025233602.587C63808@overcee.netplex.com.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20011025233602.587C63808@overcee.netplex.com.au>, Peter Wemm writes
:

>There are a couple of other interesting things on 64 bit machines
>(alpha, ia64, sparc64) as things stand right now:
>  struct timeval {
>    long tv_sec;		/* 64 bit */
>    long tv_usec;		/* 64 bit */
>  }
>  struct timespec {
>    time_t tv_sec;		/* 32 bit */
>    long tv_nsec;		/* 64 bit */
>  }

I find it rather obvious that all 64bit archs should have 64bit
time_t's.

I'm not particular interested in what size we give the 32bit archs,
but acknowledge that at some point they will have to change and
5.0 i as good a chance as any.

BUT, i would like to point out a problem in the other direction:

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.

Converting from a time$something to a timespec or timeval is done by
multiplication and shift:

	tv_usec = (tx_fsec * (1000000 << 32)) >> 96;
	tv_nsec = (tx_fsec * (1000000000 << 32)) >> 96;

Which is much cheaper cpu-wise than the gunk we currently have to
deal with all over the place:

	if (tv_nsec > 1000000000) {
		tv_nsec -= 1000000000;
		tv_sec++;
	}
	if (tv_nsec < 0) {
		tv_nsec += 1000000000;
		tv_sec--;
	}

Comments ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

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?23015.1004077694>