From: Brian Candler <B.Candler@...>
Date: 2007-06-05T04:14:33+09:00
Subject: Re: Sleeping between 1e-2 and 1e-6s

On Tue, Jun 05, 2007 at 12:57:30AM +0900, Stefan Rusterholz wrote:
> I noticed that ruby uses a different way to sleep with values >1e-6s.
> I added my observations below. My question is now: what is the suggested
> way to sleep e.g. 0.001s?
> 10000.times { sleep(0.0000001) }? Cant' really be it, no? :)

You've hit the granularity of the thread scheduler. On my machine, running
your test code, it appears to be 4ms:

$ ruby sleep.rb
100x sleeping 0.01000000s: 0.01210674s per sleep, runtime: 1.21067s
100x sleeping 0.00100000s: 0.00407440s per sleep, runtime: 0.40744s
100x sleeping 0.00010000s: 0.00411841s per sleep, runtime: 0.41184s
100x sleeping 0.00001000s: 0.00411971s per sleep, runtime: 0.41197s
100x sleeping 0.00000100s: 0.00000858s per sleep, runtime: 0.00086s
100x sleeping 0.00000010s: 0.00000852s per sleep, runtime: 0.00085s
100x sleeping 0.00000001s: 0.00000852s per sleep, runtime: 0.00085s

Ruby is not a precision real-time environment - and neither are Unix or
Windows for that matter.

If you really need such a short pause, you could use ruby-inline and call
nanosleep() or usleep() or select() C functions, depending on what's
available on your platform. You'll block the entire Ruby interpreter for
that period of time, i.e. Ruby won't be able to do work in another thread at
the same time, but at least the CPU will be available to other processes on
your machine, unlike a spinloop as you propose above.

But you should think carefully about what you're doing. For example, if you
were trying to do

   loop do
     send_packet
     precision_sleep(0.001)
   end

then you will certainly send less than 1000 packets per second, and the
actual rate you send at will be variable. It may be better to send packets
at an *average* rate of 1000 packets per second, even if they go in bursts
of 10 or 12 packets.

Brian.