Marshall was complaining about an abnormally long sleep. While you are correct that sleep never guarantees a maximum time, only a minimum time, there must be a reasonable standard to which sleep must be expected to return control on a normal system. If you specify 1 second and got 4 seconds (Marshall's time), and there are no external reasons on that system (nice'd process at 100% CPU), then something else must be happening. A CPU timeslice is around 10-50 milliseconds on Windows http://support.microsoft.com/kb/259025, MS admits the time is updated only on a context switch http://msdn.microsoft.com/en-us/library/windows/desktop/ms724408%28v=vs.85%29.aspx. I just pointed out that on Windows systems with problematic clocks and scheduling, Perl's sleep likes to take many times longer than it should and there might be bug on why that happens. It is a known problem, http://www.nntp.perl.org/group/perl.daily-build.reports/2012/08/msg126306.html

# Failed test 4 -    right time (waited 1 secs for 3-sec alarm) at op/
+alarm.t line 55
op/alarm.t........... 
Failed 1/5 subtests
[download]

# Failed test 2 -    right time (waited 5 secs for 3-sec alarm) at op/
+alarm.t line 35
op/alarm.t ........................................................ 
Failed 1/5 subtests
[download]

And that system has been having a randomly failing alarm.t since, forever I think.

If a GUI program that is not doing anything CPU or I/O intensive randomly stops responding to mouse movement for 4 seconds, it would be completely unacceptable. Clearly the OS manufacturer (Microsoft) did not design the OS to ever do that, so other app specific causes should be considered. I couldn't tell whether Marshall's scripts output was done with his ping backticks delay or whether with a sleep(), I assumed sleep() since he claimed he rebooted and sleep() starting working accurately again.