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