Date: Thu, 01 Nov 2001 07:34:41 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011101073441.A94653@gsmx07.alcatel.com.au> In-Reply-To: <3BD9950D.BB72A8F9@mindspring.com>; from tlambert2@mindspring.com on Fri, Oct 26, 2001 at 09:53:33AM -0700
next in thread | previous in thread | raw e-mail | index | archive | help
[Resend due to bounce] [Cc: trimmed as per followup list] On 2001-Oct-26 09:53:33 -0700, Terry Lambert <tlambert2@mindspring.com> wrote: >You can alternately resolve this problem by forcing the >timestamp to be monotonically increasing, FWIW. Note that AmigaOS did this (see timer.device TR_GETSYSTIME). I think this is a good idea in general. It's trivial on a UP system. It's not too difficult on an SMP system. BUT I have no idea how to efficiently implement it on a cluster - which is where I suspect computing is moving. There are two requirements: Firstly, the resolution of the timestamp must be finer that the typical delay between gettimeofday() (or equivalent) calls. Secondly the required precision of the timestamps (as a time) must be less than the available resolution (since the low few bits may be noise). >This could be done in the FS, without any ugly hacks... Also agreed. In fact, I'd like to split this discussion into two bikesheds - one to discuss time_t, struct timeval et al, and another one to discuss timestamps on disks - there is no reason for the two formats to be the same - nothing in userland (other than dump/restore - which is a special case) needs know the UFS timestamp format. We just need to be able to translate between the two formats reasonably efficiently. Peter 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?20011101073441.A94653>