High resolution sleep (Linux)

[John]

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 :)

[Nick Craig-Wood]

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

[Tim Roberts]

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.

[Hendrik van Rooyen]

"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

[Hendrik van Rooyen]

"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

[Steven D'Aprano]

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.

[mensanator]

On May 8, 12:59 pm, Dennis Lee Bieber <[e-mail]:

On Tue, 8 May 2007 08:24:01 +0200, "Hendrik van Rooyen"
<[e-mail] 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
[e-mail] [e-mail]
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: [e-mail])
HTTP://www.bestiaria.com/

[John Nagle]

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

[John]

On 9 Maj, 03:23, John Nagle <[e-mail]:

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.)

[=?UTF-8?Q?Bart.?=]

On 9 Maj, 03:23, John Nagle <[e-mail]:

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.

[Laurent Pointal]

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.

[Nick Craig-Wood]

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

[Cameron Laird]

In article <RT*****************@newsread2.news.pas.earthlink. net>,
Dennis Lee Bieber <wl*****@ix.netcom.comwrote:

[Cameron Laird]

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.

[Cameron Laird]

In article <ma***************************************@python. org>,
Hendrik van Rooyen <ma**@microcorp.co.zawrote:

[Roy Smith]

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!

[Hendrik van Rooyen]

"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

[Hendrik van Rooyen]

"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

[John J. Lee]

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!

:-)

[Ian MacLure]

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