From owner-freebsd-chat@FreeBSD.ORG Mon Mar 26 18:30:31 2007 Return-Path: X-Original-To: freebsd-chat@freebsd.org Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 413E916A473 for ; Mon, 26 Mar 2007 18:30:31 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 86B6813C50F for ; Mon, 26 Mar 2007 18:30:29 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2QITvGI032565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Mar 2007 21:30:04 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2QITd4G018207; Mon, 26 Mar 2007 21:29:51 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2QITdXZ018206; Mon, 26 Mar 2007 21:29:39 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 26 Mar 2007 21:29:38 +0300 From: Giorgos Keramidas To: deeptech71@gmail.com Message-ID: <20070326182938.GA18096@kobe.laptop> References: <200703251900.l2PJ0Z8w058298@lurza.secnetix.de> <4606D88E.4080503@gmail.com> <20070325215731.GA1517@kobe.laptop> <4607D66B.4070800@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4607D66B.4070800@gmail.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.512, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.69, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-chat@freebsd.org Subject: Re: 64bit timestamp X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 18:30:31 -0000 On 2007-03-26 16:19, deeptech71@gmail.com wrote: >Giorgos Keramidas wrote: >>On 2007-03-25 22:16, deeptech71@gmail.com wrote: >>> Actually, my intend wasn't to use it in filesystems, but >>> server-client apps, such as games, where 32bit integer timers >>> must be restarted every 3 weeks >> >> That's a bug in the applications themselves. The >> gettimeofday() call in any modern UNIX returns a `struct >> timeval', which contains *both* a time_t value of the current >> time with second-level accuracy and a tv_usec member with >> millisecond accuracy (or at least an approximation of a >> timestamp with millisecond accuracy). >> >> Any userlevel application which uses userlevel time counters >> and requires a restart every two or three weeks, because these >> userlevel timecounters have rolled back to zero, is broken and >> should be fixed. > > No, it's not a bug, the server and client communicates with > lots of packets timestamped with a synchronized time, and > sending 64bit timestamps would be too much bandwidth > consuming. There's a restart demand every hour or so, so it's > not a problem... but the server is limited for max 3 weeks. Well, if timestamps are required and the bandwidth is not enough to send 128 bits of timestamp data every few nanoseconds, then the operating system cannot do a lot of things to help. The best the OS can do is provide you *locally* with extra-fine timestamps, and let a smart algorithm of time synchronization between the two remote hosts handle the rest. It's not going to be easy, but someone has to do the "hard work" :)