From owner-freebsd-arch Wed Oct 31 12:34:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id AE9C737B405 for ; Wed, 31 Oct 2001 12:34:51 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id HAA01941; Thu, 1 Nov 2001 07:34:44 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01KA6K16NEQ8VLLLIS@cim.alcatel.com.au>; Thu, 1 Nov 2001 07:34:42 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9VKYfV94703; Thu, 01 Nov 2001 07:34:41 +1100 Content-return: prohibited Date: Thu, 01 Nov 2001 07:34:41 +1100 From: Peter Jeremy Subject: Re: 64 bit times revisited.. In-reply-to: <3BD9950D.BB72A8F9@mindspring.com>; from tlambert2@mindspring.com on Fri, Oct 26, 2001 at 09:53:33AM -0700 To: Terry Lambert Cc: arch@FreeBSD.ORG Mail-Followup-To: Terry Lambert , arch@FreeBSD.ORG Message-id: <20011101073441.A94653@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i 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 [Resend due to bounce] [Cc: trimmed as per followup list] On 2001-Oct-26 09:53:33 -0700, Terry Lambert 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