Re: An experiment: 64-bit time_t on IA-32 (5.2-RC)

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