From owner-freebsd-arch Mon Oct 29 10:22:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 04EB637B401 for ; Mon, 29 Oct 2001 10:22:27 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA26402; Mon, 29 Oct 2001 10:14:22 -0800 (PST) Date: Mon, 29 Oct 2001 10:14:20 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <15325.36894.320057.967406@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG yes you are right here.. But the two TOP bits of the nanosecond fields are by definition always 0 (you can only have up to 1,000,000,000 nano seconds in a partial second) and 32 bits goes up to 4(American)billion, so the two top bits can safely be used for multiplying the seconds scale by 4. (in UFS timestamps.. you would never write a non-normalised time to disk) also timestamps can't be before 1970 so making it unsigned allows us to go to 2100+ and mutiplying it by for takes us to about 2600.. On Mon, 29 Oct 2001, Nate Williams wrote: > > >ufs has enough room to fix this.. > > >there has been a field defined in the on disk inode for nanosecs > > >in each of the time values... > > >if we take the lowest 8 bits of that field and re-assign it to be > > >the highest 8 bits of the seconds, then we have time accuracy down to > > >microseconds still and we expand file times by a factor > > >of 256 (which is all of recorded history plus some) > > > > > >we just always set those bits to 0 for the next 37 years and we don;t > > >really lose time resolution and we gain compatibility with the future.. > > >nothing these days has nonosecond resolution there anyhow.... > > Simply not true. We have pico second resolution in our product, which > is necessary because we're using *really* fast transports, and need to > do very precise timing. > > (We're not using FreeBSD now, but if we need that kind of resolution in > 2001, I can easily see the need for much higher resolution in the > future.) > > I'm with PHK here (can you believe it?). :) :) > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message