64bit timestamp

[deeptech71 at gmail.com]

Giorgos Keramidas wrote:
> On 2007-03-25 22:16, deeptech71 at 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.