I need to perform a task every 10ms. I’ve been using
kernel.sleep(0.01), but sleep seems to be slow and erratic at sub-second
resolutions. Here’s a test I ran along with the results:
So I’m wondering if there’s a way to get a steady 10ms delay. Another
option would be to set up an alarm or scheduled callback or something
every 10ms. Is this possible.
I need to perform a task every 10ms. I’ve been using
kernel.sleep(0.01), but sleep seems to be slow and erratic at sub-second
resolutions. Here’s a test I ran along with the results:
[snip]
Try select()
[snip]
148
sleep with select on both an Athlon64 X2 3800+ and an Athlon XP 2400+.
Is there some YARV in there?
Lionel
Have you all tried this outside of irb?
Just run the actual script itself + profiler to find out where the
slowdown is occurring.
Try it with sleep and select versions. This might show some different
points… maybe not.
It’s unlikely to get 10ms intervals reliably even in C, so getting it
in ruby is very unlikely.
The reason it’s hard to get it even in C is (as man setitimer says):
“Time values smaller than the resolution of the system clock are
rounded up to this resolution (typically 10 milliseconds).”
Even taking the system clock resolution out of the equation, if the GC
kicks in, it will definitely cause a delay greater than 10ms. Add in
the rest of the delays caused by ruby’s runtime, and it’s a loosing
game.
If you require running a loop at 10ms intervals, you’re probably going
to have to dip down into C.
irb(main):007:1> puts Time.now.usec/1000
What kind of system are you on? It doesn’t work so well for me.
slowdown is occurring.
Try it with sleep and select versions. This might show some different
points… maybe not.
I tried your script on Windows under irb and using ruby and get similar
results. I end up with times like 171.0, 171.0, 187.0, 203.0,
203.0,…, obviously select is not waiting, at least under Windows.
So I’m wondering if there’s a way to get a steady 10ms delay. Another
option would be to set up an alarm or scheduled callback or something
every 10ms. Is this possible.
I ran your code as a script and it worked fine on Windows XP.
I did not try irb.
What kind of system are you on? It doesn’t work so well for me.
Interesting.
It’s an older 32 bit dual processor AMD box. That was with Ruby 1.8.5.
OS is Linux Redhat Enterprise, but the Ruby was compiled locally.
I consistently get precise timings off of it, just like that. I do not,
however, on another box – a newer 64 bit dual core AMD, also running
Linux. On that box a wait of 0.01 seems to fairly consistently wait
about
0.012.
I think that is about as precise as one is going to make the timings,
with
Ruby, in any case, though.
On Fri, Apr 27, 2007 at 04:57:21AM +0900, Earle C. wrote:
irb(main):001:0> 0.upto(25) do
irb(main):002:1* puts Time.now.usec/1000
irb(main):003:1> STDOUT.flush
irb(main):004:1> sleep 0.01
irb(main):005:1> end
105
132
143
I believe part of the problem is that you are not correcting for the
time that ruby spends in the loop. In [ruby-talk:42003] Dave T.
proposed this solution:
def every(period)
base = last = Time.now.to_f
count = 0
loop do
now = Time.now.to_f
actual_secs = now - base
expected_secs = period * count
correction = expected_secs - actual_secs
correction = -period if correction < -period
select(nil, nil, nil, period + correction)
now = Time.now
last = now.to_f
count += 1
yield(now)
end
end
Which I’ve tested using this code:
n = 0
every(0.01) do
puts Time.now.usec / 1000
n += 1
break if n == 25
end
It’s unlikely to get 10ms intervals reliably even in C, so getting it
in ruby is very unlikely.
The reason it’s hard to get it even in C is (as man setitimer says):
“Time values smaller than the resolution of the system clock are
rounded up to this resolution (typically 10 milliseconds).”
I’ve been reading about this a bit lately and as far as I understand it,
windows has a 15ms “tick” (this might be different for different windows
versions)
The linux tick is by default 10ms. You can change linux to 1ms though
(1000HZ), by changing a kernel setting:
CONFIG_HZ_1000=y
I use 1000 HZ and my output is:
123
133
143
153
163
173
183
193
203
213
223
233
I consistently get precise timings off of it, just like that. I do not,
however, on another box – a newer 64 bit dual core AMD, also running
Linux. On that box a wait of 0.01 seems to fairly consistently wait
about
0.012.
I think that is about as precise as one is going to make the timings,
with
Ruby, in any case, though.
Kirk H.
So I’ve done some more testing and I found something interesting:
Code:
#!/usr/bin/ruby -w
require ‘enumerator’
a = []
15.times do
sleep 0.008000499999999999
sleep 0.0080004999999999999
a << Time.now.usec / 1000.0
end
a.each_cons(2) {|x,y| puts y-x}
Now if use the second sleep expression instead of the first, I get the
following results:
11.978
12.016
11.963
12.073
11.939
12.06
12.235
11.696
12.0
12.047
11.956
12.004
11.996
12.0
Can anyone explain why the delay jumps from ~8ms to ~12ms? I think this
may be the root of my problem.
n = 0
every(0.01) do
puts Time.now.usec / 1000
n += 1
break if n == 25
end
I do have to say that, given what this code does and the time in which
it runs, saying that ruby just cannot run fast is silly. I am very glad
to have seen this thread!
ruby is interpreted langue and becouse of some restrictions on select
and
interpereter you can’t get exact delays, the bigger delay is more
acurate
it’s but if you need that sort of precision consder including c code.
