64bit timestamp

[Giorgos Keramidas]

On 2007-03-26 16:19, deeptech71 at gmail.com wrote:
>Giorgos Keramidas wrote:
>>On 2007-03-25 22:16, deeptech71 at 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" :)