Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Oct 2001 11:40:00 -0700
From:      Nate Williams <nate@yogotech.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        Nate Williams <nate@yogotech.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG
Subject:   Re: 64 bit times revisited.. 
Message-ID:  <15325.41600.832823.952280@caddis.yogotech.com>
In-Reply-To: <Pine.BSF.4.21.0110291010010.26174-100000@InterJet.elischer.org>
References:  <15325.36894.320057.967406@caddis.yogotech.com> <Pine.BSF.4.21.0110291010010.26174-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15325.41600.832823.952280>