Title: Don't Touch That Clock!

A friend wanted to transfer a large amount of data from her account in America, so I scheduled a download to take place overnight, using 'wget', a good mirroring tool. In the morning, I found this:

calc_rate: Assertion `msecs >= 0' failed.

Apparently, it was trying to calculate the transfer rate, and found it to be negative. This happened at 2:30am, which is the time when my system synchronises its clock to the university's NTP time server. I checked the logs and it seems the NTP synchronisation took the system clock back 6 seconds, and this must have caused the negative time difference.

I looked through the wget source and found it calls the Unix function 'gettimeofday' to calculate the time to the desired accuracy. Clearly it would be better to use a timer that is relative and not affected by clock changes, but there doesn't appear to be such a thing in the GNU C library.

Apparently, any programmer who deals with elapsed times on a multi-tasking system has to be aware of the fact that somebody might change the system clock while the program is running. This doesn't strike me as an ideal situation.

Of course, it is possible to work around the problem by ignoring unusual timings, or disabling the progress indicator altogether (since it's not really needed in a batch job), or disabling the NTP program that night, or telling it to "slew" the clock instead of setting it (this means that the clock's speed is slightly changed for a while until it has gained or lost the required amount of time, so that the clock never "jumps", but it can take a long time to perform). Still, it seems odd that a system such as Unix should not differentiate between absolute clock times, which might be resynchronised, and relative timers which should not be affected. Most PDAs manage fine no matter how often you set the clock.