On 2007-03-26 16:19, [EMAIL PROTECTED] wrote: >Giorgos Keramidas wrote: >>On 2007-03-25 22:16, [EMAIL PROTECTED] 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" :) _______________________________________________ freebsd-chat@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-chat To unsubscribe, send any mail to "[EMAIL PROTECTED]"
