An experiment: 64-bit time_t on IA-32 (5.2-RC)
Peter Jeremy
peterjeremy at optushome.com.au
Mon Dec 22 10:44:19 PST 2003
On Sun, Dec 21, 2003 at 10:39:38PM -0600, Craig Boston wrote:
>The initial compile went off without a hitch. This is no doubt due to hard
>work by the people working on the ia64, amd64, etc. ports where time_t is
>64-bits by default. A side note, I noticed that the alpha and sparc64 ports
>seem to be using 32-bit time_t, which surprised me.
Alpha has a 32-bit time_t for compatability with Tru64. There are
occasional discussions on -alpha regarding the pros and cons of moving
to 64-bits. I suspect SPARC is 32 bit for Solaris compatability.
>So anyway, kudos to the FreeBSD development team! It's certainly healthy for
>an OS to be able to survive a change in one of the base data types without
>suffering any major problems. Something to think about for 6.x perhaps?
This has been discussed on either -arch or -hackers sometime in the
past year or so.
>2. I was also slightly worried about the UFS on-disk layout. Turns out that
>UFS already uses 64-bit timestamps anyway so I had nothing to worry about ;)
Only UFS2. UFS1 has a 32-bit timestamp and an adjacent spare 32-bit field.
>3. Should I expect any appreciable slowdown from using a non-native type for
>time_t? So far I haven't noticed any difference, but I haven't done any
>scientific benchmarks or anything.
Adding, subtracting and comparing 64-bit values on an i386 is reasonably
efficient. The cost of moving small amounts of data in and out of the
kernel is probably swamped by the validation overheads. I suspect you'd
have trouble measuring the difference.
>$ uname -a
>FreeBSD aldaris 5.2-RC FreeBSD 5.2-RC #0: Sun Dec 21 20:44:33 CST 2003
>root at aldaris:/usr/obj/usr/src/sys/ALDARIS i386
>$ date -r 8589934592
>Wed Mar 16 06:56:32 CST 2242
>$ date -r 68719476736
>Sun Aug 20 01:32:16 CST 4147
>$ date -r 274877906944
>Wed Jul 14 00:09:04 CST 10680
That's a good start. Have you tried cross-checking those calculations
via an independent codebase? (I have no idea whether they're right or
wrong but it's worth a double check).
The next test would be setting the date to (say) 2038-Jan-19 03:14 UTC,
waiting 10 seconds and seeing what various utilities do.
If you're interested in doing serious validation, it would be
worthwhile looking at some of the Y2K test plans. I know one of our
customers had a very extensive test plan that checked that the system
under test would correctly tick across various date boundaries (eg
1999-Dec-31 => 2000-Jan-01, 2000-Feb-28 => 2000-Feb-29 => 2000-Mar-01,
2001-Dec-31 => 2001-Jan-01) as well as correctly handling entry, logging
and reporting of date/times.
Peter
More information about the freebsd-current
mailing list