64bit timestamp

[deeptech71 at gmail.com]

deeptech71 at gmail.com wrote:
> 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.
> 

sry, i wanted to say, 48bit or 64bit is acceptable, but 96bit is not