Seth Kurtzberg
Also, what happens when you are using NTP? NTP might just correct it, but it would screw up the calculations NTP uses and it could start oscillating.
The NTP client (at least on Linux) adjusts the time by making a jump only if the time is very inaccurate. If the time only drifted a bit, it temporarily adjusts the speed of the system clock instead.
I'm also saying that I don't like the idea of using the same resolution w.r.t. the system clock, because it suggests that the time is known to a greater precision than is actually the case.
I don't think this would be a practical problem.
To me all this shows that the system clock needs to be handled as a special case, not just converted into the high resolution representation
Using a different representation of time just because somebody might not be aware that the resolution of the system clock is not as good as the representation suggests? No, this is an unnecessary complication. Anyway, what does the "resolution of the system clock" mean? On Linux the timeout of select(), poll() and epoll() is accurate only to the timer interrupt (10ms on older kernels and 1ms on newer ones), yet the gettimeofday is more precise (it returns microseconds, quite accurately; the call itself takes 2us on my system). So even if gettimeofday is accurate, sleeping for some time might be much less accurate. BTW, this means that the most accurate way to make a delay is to use select/poll/epoll to sleep for some time below the given time (i.e. shorter by the typical largest interval by which the system makes the delay longer than requested), then to call gettimeofday in a loop until the given time arrives. The implementation of my language does that under the hood. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/