Date: Mon, 26 Mar 2007 16:19:23 +0200 From: deeptech71@gmail.com To: freebsd-chat@freebsd.org Subject: Re: 64bit timestamp Message-ID: <4607D66B.4070800@gmail.com> In-Reply-To: <20070325215731.GA1517@kobe.laptop> References: <200703251900.l2PJ0Z8w058298@lurza.secnetix.de> <4606D88E.4080503@gmail.com> <20070325215731.GA1517@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote: > On 2007-03-25 22:16, deeptech71@gmail.com wrote: >> Oliver Fromme wrote: >>> Ideally, two consecutive, non-parallel operations should give >>> two different timestamps. That applies to creating or >>> touching a file or other kind of resource, or even just >>> calling the gettimeofday() function from within the same >>> thread, or whatever. In reality that isn't the case today for >>> FreeBSD for other reasons, but the timestamp accuracy of UFS2 >>> would certainly be sufficient for that. >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4607D66B.4070800>