time.sleep(1) sometimes runs for 200 seconds under windows

[Magnus Lycka]

Claudio Grondi wrote:
> I mean, that using time.clock() solves the problem, because the output 
> of the following code:

On Windows that it. At least on Linux and Solaris, time.clock() returns
CPU time. If time.clock() returns significantly different values before
and after time.sleep(1), there's something seriously broken in sleep on
such platforms.

Anyway, what is the perceived problem?
A) That sleep takes too much time, or
B) that time measurements don't work right?

If A), the problem is solved if what really happens is clock-setting
glitches.

If B), I see two options:

- Use some proper external and stable time source. (It should be
   fairly trivial to build a little socket server that returns
   timestamps from a single source if no other source is available.
   See http://www.python.org/doc/lib/socket-example.html )

- If the clock-resetting is actually warranted because the system
   clocks lag so much, make sure this resetting is made more often,
   so that it never gets so much off track.

Unless hardware is broken, or the clocks are changed so that they
get more and more off track with time as the rest of us perceives
it, there ought to be "negative sleeps" as well as sleeps much
longer than 2 seconds. Of course, if you only look for longer sleeps
than 2 secs, you won't see them.

BTW, finding "negative sleeps" pretty much proves that it's the
clocks, not actual delays, that cause problems...

I guess a typical cause of clock setting problems is that one has
two disagreeing time sources that both try to set the system times
of the computers...