From owner-freebsd-arch Mon Oct 29 13: 0:44 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 28C5C37B401 for ; Mon, 29 Oct 2001 13:00:39 -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 MAA27006; Mon, 29 Oct 2001 12:46:34 -0800 (PST) Date: Mon, 29 Oct 2001 12:46:32 -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.41600.832823.952280@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 why? On Mon, 29 Oct 2001, Nate Williams wrote: > > 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.. > > All I can say is *yuck*. > > > > Nate > > > > > >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