From owner-freebsd-current@FreeBSD.ORG Mon Dec 22 10:44:19 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93A4016A4CE for ; Mon, 22 Dec 2003 10:44:19 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5342843D2D for ; Mon, 22 Dec 2003 10:44:14 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])hBM81LQU002229; Mon, 22 Dec 2003 19:01:21 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id hBM81FX2002228; Mon, 22 Dec 2003 19:01:15 +1100 (EST) (envelope-from peter) Date: Mon, 22 Dec 2003 19:01:15 +1100 From: Peter Jeremy To: Craig Boston Message-ID: <20031222080115.GA645@server.vk2pj.dyndns.org> References: <200312212239.38557.craig@xfoil.gank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312212239.38557.craig@xfoil.gank.org> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: An experiment: 64-bit time_t on IA-32 (5.2-RC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2003 18:44:19 -0000 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@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