By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,908 Members | 1,860 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,908 IT Pros & Developers. It's quick & easy.

High resolution sleep (Linux)

P: n/a

The table below shows the execution time for this code snippet as
measured by the unix command `time':

for i in range(1000):
time.sleep(inter)

inter execution time ideal
0 0.02 s 0 s
1e-4 4.29 s 0.1 s
1e-3 4.02 s 1 s
2e-3 4.02 s 2 s
5e-3 8.02 s 5 s

Hence it seems like the 4 s is just overhead and that the time.sleep
method treats values below approximately 0.001 as 0.

Is there a standard way (or slick trick) to get higher resolution? If
it is system dependent it's acceptable but not very nice :)

May 4 '07 #1
Share this Question
Share on Google+
19 Replies


P: n/a
John <ja****@gmail.comwrote:
>
The table below shows the execution time for this code snippet as
measured by the unix command `time':

for i in range(1000):
time.sleep(inter)

inter execution time ideal
0 0.02 s 0 s
1e-4 4.29 s 0.1 s
1e-3 4.02 s 1 s
2e-3 4.02 s 2 s
5e-3 8.02 s 5 s

Hence it seems like the 4 s is just overhead and that the time.sleep
method treats values below approximately 0.001 as 0.
The exact minimum sleep time will be determined by the HZ value that
your kernel was compiled with. In newer kernels that is typically 250
or 1000, it used to be 100 in older kernels.

If you look at the config file used to build your kernel you can
discover the HZ value.

If you try to sleep for less than a timer tick, then the kernel
performs a yield.
Is there a standard way (or slick trick) to get higher resolution? If
it is system dependent it's acceptable but not very nice :)
I assume you are using sleep for timing purposes.. This isn't a
terribly good idea, but here is an idea for you....

# ------------------------------------------------------------
from time import time, sleep

def hr_sleep(duration):
end = time() + duration
if duration 0.02:
sleep(duration)
while time() - end < 0:
sleep(0)

if __name__ == "__main__":
from timeit import Timer
for e in range(0,7):
dt = 10**-e
loops = 10**e
t = Timer("hr_sleep(%f)" % dt, "from __main__ import hr_sleep")
print "expected = %.2E actual = %.2E" % (dt, t.timeit(loops)/loops)
# ------------------------------------------------------------

This prints

expected = 1.00E+00 actual = 1.00E+00
expected = 1.00E-01 actual = 1.00E-01
expected = 1.00E-02 actual = 1.00E-02
expected = 1.00E-03 actual = 1.00E-03
expected = 1.00E-04 actual = 1.02E-04
expected = 1.00E-05 actual = 1.19E-05
expected = 1.00E-06 actual = 2.66E-06

on my 250 HZ machine

You could then do run-time calibration to work out the overhead of the
function on any given machine to make it more accurate.

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
May 5 '07 #2

P: n/a
John <ja****@gmail.comwrote:
>
The table below shows the execution time for this code snippet as
measured by the unix command `time':

for i in range(1000):
time.sleep(inter)

inter execution time ideal
0 0.02 s 0 s
1e-4 4.29 s 0.1 s
1e-3 4.02 s 1 s
2e-3 4.02 s 2 s
5e-3 8.02 s 5 s

Hence it seems like the 4 s is just overhead and that the time.sleep
method treats values below approximately 0.001 as 0.

Is there a standard way (or slick trick) to get higher resolution? If
it is system dependent it's acceptable but not very nice :)
Consider what you're asking here. The operating system can only age the
timer list and re-evaluate process ready states when a process goes into
kernel mode, either by releasing the CPU or hitting the end of its time
slice. In order to know that a process has reached the end of its time
slice, it has to be interrupted by something, typically the timer
interrupt.

In order to provide 10us sleep resolution, the timer interrupt would have
to fire every 10us. The overhead of handling the timer interrupt and
rescheduling that often is quite significant.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
May 5 '07 #3

P: n/a
"Tim Roberts" <ti..@pr...o.comwrote"
Consider what you're asking here. The operating system can only age the
timer list and re-evaluate process ready states when a process goes into
kernel mode, either by releasing the CPU or hitting the end of its time
slice. In order to know that a process has reached the end of its time
slice, it has to be interrupted by something, typically the timer
interrupt.
Yes
>
In order to provide 10us sleep resolution, the timer interrupt would have
to fire every 10us.
Not necessarily. see below
The overhead of handling the timer interrupt and
rescheduling that often is quite significant.
Yes

It is also possible to keep the timer list sorted by "expiry date",
and to reprogram the timer to interrupt at the next expiry time
to give arbitrary resolution, instead of implementing a regular 'tick'.
But this also adds overhead and its a PITA to do efficiently,
using a linked list of "next interrupt time". So its not normally
done unless you *really* need it. Its easier to make a free
running hardware counter and to read it and do the sums
yourself, hogging the processor, if you need such fine resolution.

Ten microseconds is not much time - Speed of light is about
one foot per nanosecond, so that gives ten thousand feet of
travel for a radio wave - less than two miles, or about three
kilometres.

A rifle bullet can travel at around 5000 feet per second.
In ten microseconds it moves six tenths of an inch.
A vehicle at 300 Km/h (about 187 MPH) will not move
as much as a millimetre in that time.

OTOH - if you are trying to make a software radar system to
pick up intruders in your back yard, then ten microseconds
is a hopelessly long time...

- Hendrik
May 7 '07 #4

P: n/a
"Dennis Lee Bieber" <w..d@ix.n,..m.comwrote:
On Sun, 6 May 2007 10:15:26 +0200, "Hendrik van Rooyen"
<m..@mi..p.co.zadeclaimed the following in comp.lang.python:

A rifle bullet can travel at around 5000 feet per second.

You've got some fast rifles over there...
LOL - true - I stand corrected - I was aware that:

1) All the animals were slaughtered, and the American Civil
War fought with rifles of muzzle velocity around 1800 fps.
This was before bullets were jacketed - if you try to push a
lead slug through a rifled barrel faster than this, it strips and
fouls the barrel

2) That the old NATO round (.308 Winchester) travels at
around 2500 fps. - and this was some forty years ago,
when I did my stint of military duty.

So being an idle bugger, I just naturally assumed that the
speed would have doubled in the intervening time since
I was last involved in this subject. - hence the 5000.

Did you know that the first military smokeless powder
round was for the French Lebel? - It threw a bronze
ball, and could punch through a single brick wall.

Battlefields were suddenly far more dangerous places.

- Hendrik
May 8 '07 #5

P: n/a
On Tue, 08 May 2007 17:59:13 +0000, Dennis Lee Bieber wrote:
>Did you know that the first military smokeless powder
round was for the French Lebel? - It threw a bronze
ball, and could punch through a single brick wall.
Well, extreme high speed wouldn't help for that -- just get a
surface splatter. Heavy and slower... (or some sort of solid core --
depleted uranium with a teflon coating)
I remember a MythBusters episode that had the guys testing the old
Hollywood staple of somebody trying to escape gunfire by swimming
underwater. To their surprise, they found that modern high-velocity rounds
basically hit the water and stopped dead, hardly penetrating at all, while
an old musket shot they found actually penetrated the water furthest.

Hmmm... musket? I may be confabulating that last bit, the rifle may not
have been that old. World War One vintage perhaps? But it fired a heavy
slow round, and everybody predicted it would penetrate the water the
least, but it was the opposite.

Anyway, the myth was confirmed. I guess that's why people don't go fishing
with shotguns.
--
Steven.

May 8 '07 #6

P: n/a
On May 8, 12:59 pm, Dennis Lee Bieber <wlfr...@ix.netcom.comwrote:
On Tue, 8 May 2007 08:24:01 +0200, "Hendrik van Rooyen"
<m...@microcorp.co.zadeclaimed the following in comp.lang.python:
So being an idle bugger, I just naturally assumed that the
speed would have doubled in the intervening time since
I was last involved in this subject. - hence the 5000.

Development tends to go in both directions... Massive rounds moving
at, or slightly slower, than "typical" (2000fps) vs very light rounds
moving at really high speeds (the various .17).
Did you know that the first military smokeless powder
round was for the French Lebel? - It threw a bronze
ball, and could punch through a single brick wall.

Well, extreme high speed wouldn't help for that -- just get a
surface splatter. Heavy and slower... (or some sort of solid core --
depleted uranium with a teflon coating)
And penetration isn't always desireable. A slow, heavy round will
punch a tunnel through your arm muscle, but a fast, light round
will take your entire arm off.
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfr...@ix.netcom.com wulfr...@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-a...@bestiaria.com)
HTTP://www.bestiaria.com/

May 9 '07 #7

P: n/a
Hendrik van Rooyen wrote:
"Tim Roberts" <ti..@pr...o.comwrote"
It is also possible to keep the timer list sorted by "expiry date",
and to reprogram the timer to interrupt at the next expiry time
to give arbitrary resolution, instead of implementing a regular 'tick'.
Yes, and that's a common feature in real-time operating systems.
If you're running QNX, you can expect that if your high priority
task delays to a given time, you WILL get control back within a
millisecond of the scheduled time. Even tighter timing control
is available on some non-x86 processors.

Some CPUs even have hardware support for a sorted event list.
The Intel 8061, which ran the engines of most Ford cars in the 1980s,
had that.

But no way are you going to get consistent timing resolution like that
from Python. It's an interpreter with a garbage collector, after all.

John Nagle
May 9 '07 #8

P: n/a
On 9 Maj, 03:23, John Nagle <n...@animats.comwrote:
Hendrik van Rooyen wrote:
"Tim Roberts" <ti..@pr...o.comwrote"
It is also possible to keep the timer list sorted by "expiry date",
and to reprogram the timer to interrupt at the next expiry time
to give arbitrary resolution, instead of implementing a regular 'tick'.

Yes, and that's a common feature in real-time operating systems.
If you're running QNX, you can expect that if your high priority
task delays to a given time, you WILL get control back within a
millisecond of the scheduled time. Even tighter timing control
is available on some non-x86 processors.

Some CPUs even have hardware support for a sorted event list.
The Intel 8061, which ran the engines of most Ford cars in the 1980s,
had that.

But no way are you going to get consistent timing resolution like that
from Python. It's an interpreter with a garbage collector, after all.

John Nagle

The application the original poster (i.e. me) was interested in was a
program that sends ethernet packets at a loosely specified rate. A
loop that sends all packets with no sleep in between will send them at
a too high rate. Using the default sleep in my Python interpreter
sleeps to long, since even a few microseconds add up when you send
hundreds of thousands of packets.

If the process scheduler deals with another process now and then, it
doesn't matter. If it switches to another application between each
packet is beeing sent, that's a problem.

Anyways, what I need is high resolution sleep, not high resolution
timing. Installing a real time OS seems like overkill.

(Yes I know, one can also send, say, 50 packets at a time, and then
sleep, send 50 more packets, and so on.)

May 10 '07 #9

P: n/a
On 9 Maj, 03:23, John Nagle <n...@animats.comwrote:
Hendrik van Rooyen wrote:
"Tim Roberts" <ti..@pr...o.comwrote"
It is also possible to keep the timer list sorted by "expiry date",
and to reprogram the timer to interrupt at the next expiry time
to give arbitrary resolution, instead of implementing a regular 'tick'.
Yes, and that's a common feature in real-time operating systems.
If you're running QNX, you can expect that if your high priority
task delays to a given time, you WILL get control back within a
millisecond of the scheduled time. Even tighter timing control
is available on some non-x86 processors.

Some CPUs even have hardware support for a sorted event list.
The Intel 8061, which ran the engines of most Ford cars in the 1980s,
had that.

But no way are you going to get consistent timing resolution like that
from Python. It's an interpreter with a garbage collector, after all.

John Nagle

The application the original poster (i.e. me) was interested in was a
program that sends ethernet packets at a loosely specified rate. A
loop that sends all packets with no sleep in between will send them at
a too high rate. Using the default sleep in my Python interpreter
sleeps to long, since even a few microseconds add up when you send
hundreds of thousands of packets.

If the process scheduler deals with another process now and then, it
doesn't matter. If it switches to another application between each
packet is beeing sent, that's a problem.

Anyways, what I need is high resolution sleep, not high resolution
timing. Installing a real time OS seems like overkill..

(Yes I know, one can also send, say, 50 packets at a time, and then
sleep, send 50 more packets, and so on.)

--
http://mail.python.org/mailman/listinfo/python-list
What about C module with usleep,nanosleep?
Best regards.
Bart.

May 10 '07 #10

P: n/a
John a écrit :
Anyways, what I need is high resolution sleep, not high resolution
timing. Installing a real time OS seems like overkill.
IDEA Maybe try creating threading.Event and waiting for it with a timeout.
May 11 '07 #11

P: n/a
Bart <uz***@o2.plwrote:
What about C module with usleep,nanosleep?
Unlikely to help! It is an linux OS limit that the minimum sleep time
is 1/HZ.

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
May 11 '07 #12

P: n/a
In article <RT*****************@newsread2.news.pas.earthlink. net>,
Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
May 26 '07 #13

P: n/a
In article <Zl******************@newsread3.news.pas.earthlink .net>,
Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
>On Sun, 6 May 2007 10:15:26 +0200, "Hendrik van Rooyen"
<ma**@microcorp.co.zadeclaimed the following in comp.lang.python:

>A rifle bullet can travel at around 5000 feet per second.

You've got some fast rifles over there...

The .17Remington just passes 4000fps and is one of the two or three
fastest ( http://www.gunsandammomag.com/ammuni..._17_remington/ ).
The .17HMR is around 2600fps (
http://www.shootingtimes.com/ammunition/17_hmr_0508/ ). More common
rounds -- .308Winchester [7.62 NATO] run ~2700-3000fps (
http://www.chuckhawks.com/08_family_cartridges.htm ). Even the .50BMG
(Browning Machine Gun) is only a 2900fps round (
http://www.chuckhawks.com/50BMG.htm ). In comparison, some of the GAMO
and RWS-Diana air guns can push a .177 pellet around 1000fps.
May 26 '07 #14

P: n/a
In article <ma***************************************@python. org>,
Hendrik van Rooyen <ma**@microcorp.co.zawrote:
May 26 '07 #15

P: n/a
In article <3f************@lairds.us>, cl****@lairds.us (Cameron Laird)
wrote:
Hmmm; now you've got me curious. What *were* the first
composite projectiles?
Fetchez la Vache!
May 26 '07 #16

P: n/a
"Cameron Laird" <cl****@lairds.uswrote:

In article <RT*****************@newsread2.news.pas.earthlink. net>,
Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
.
.
.
Did you know that the first military smokeless powder
round was for the French Lebel? - It threw a bronze
ball, and could punch through a single brick wall.
Well, extreme high speed wouldn't help for that -- just get a
surface splatter. Heavy and slower... (or some sort of solid core --
depleted uranium with a teflon coating)
.
.
.
Hmmm; now you've got me curious. What *were* the first
composite projectiles? Conceivably archers, catapultists,
and slings would all have the potential to find advantage
in use of coated dense projectiles; is there any evidence
of such? There certainly was "mass production" of cheap
projectiles (clay pellets, for example). How were stones
chosen for large catapults? Was there a body of craft
knowledge for balancing density and total mass in
selection of stones?
Would a toggle headed harpoon count as
a "composite projectile" ? - they have been
around a long time.

Also the San people (better known as Bushmen)
have made their poison arrows so that the point
detaches from the shaft and stays in the wound,
ensuring better contact between the sticky gum
like poison and the blood of the victim.

- Hendrik

May 27 '07 #17

P: n/a

"Cameron Laird" <c.d@l...uswrote:
.
.
Ha! It's interesting, especially for "computerists", to consider
how some technologies "plateau": steam car speeds, fresco paint-
ing, dry-stone walls, ...
From what I remember from my reading, the Stanley Steamer
had a reputation as a "Hot Rod" (pun intentional) - and people
said that nobody who tried to get its maximum out of it would
live.

I would suspect that the cause was not the engine, but the
cornering performance of the chassis.

Would be interesting to put an engine like that into a modern
chassis to see what it would do.

Probably would not beat a mini fitted with a Kawasaki 1100
engine for each wheel, though - an interesting problem in
real time control...

- Hendrik

May 27 '07 #18

P: n/a
Roy Smith <ro*@panix.comwrites:
In article <3f************@lairds.us>, cl****@lairds.us (Cameron Laird)
wrote:
Hmmm; now you've got me curious. What *were* the first
composite projectiles?

Fetchez la Vache!
:-)
May 28 '07 #19

P: n/a
Roy Smith <ro*@panix.comwrote in news:roy-2F6BE5.16193326052007@032-325-
625.area1.spcsdns.net:
In article <3f************@lairds.us>, cl****@lairds.us (Cameron Laird)
wrote:
>Hmmm; now you've got me curious. What *were* the first
composite projectiles?

Fetchez la Vache!
Non, non, non, non, NON!
La vache, she is the COMPOSTING projectile.
Zere is a difference you ignorant Rosbif!

IBM
Jun 2 '07 #20

This discussion thread is closed

Replies have been disabled for this discussion.