time module precision

[Jane Austine]

What is the precision (and accuracy) of time module on a Windows XP
machine?

threading module depends on time module so it's precision(and
accuracy) is up to time module's.

| for i in xrange(1000):
| time.sleep(0.001)

This sleeps for awhile, which means 0.001 sec is not ignored. On the
other hand,

| for i in xrange(10000):
| time.sleep(0.0001)

This returns right away. 0.0001 sec is ignored and lost in the air.

So can I tell the time.sleep's precision is 1ms? Any other way to
increase the precision? (Using busy waiting -- spinning loop -- is not
a good option, it makes over 90% cpu usage)

Jane

 

[Tim Peters]

[Jane Austine]

What is the precision (and accuracy) of time module on a Windows XP
machine?

There are many functions in the time module. You shouldn't assume
that any two have similar behavior (because, in fact, they may not).

threading module depends on time module so it's precision(and
accuracy) is up to time module's.

| for i in xrange(1000):
| time.sleep(0.001)

This sleeps for awhile, which means 0.001 sec is not ignored. On the
other hand,

| for i in xrange(10000):
| time.sleep(0.0001)

This returns right away.

It may or may not, depending on what other threads are trying to do.

0.0001 sec is ignored and lost in the air.

So can I tell the time.sleep's precision is 1ms? Any other way to
increase the precision? (Using busy waiting -- spinning loop -- is not
a good option, it makes over 90% cpu usage)

Python's time.sleep() calls the Win32 API Sleep() function on Windows.
All behavior is inherited from the latter. See MS's docs:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/sleep.asp>

In particular, MS Sleep() takes an integer argument, giving the number
of milliseconds to sleep. Your 0.0001 case falls under the special
Sleep(0) case due to truncation in float->int conversion.

Also Google on

sleep thread deviation

to find an interesting CodeProject article quantifying behavior on one
particular tester's Windows box. Also see an article it references
for approaches to the question "how do I handle small intervals?"
(short course: you probably can't, unless we're willing to throw
money at it).

 

[janeaustine50]

Tim Peters wrote:
[snip]

Python's time.sleep() calls the Win32 API Sleep() function on Windows.
All behavior is inherited from the latter. See MS's docs:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/sleep.asp>

Oh, after a short research, I found that time.sleep uses its customized
way of sleeping using "select".

http://groups.google.com/[email protected]

So I think its behaviour is more complicated than single MS Sleep call,
I suppose.

In particular, MS Sleep() takes an integer argument, giving the number
of milliseconds to sleep. Your 0.0001 case falls under the special
Sleep(0) case due to truncation in float->int conversion.

Oh, I see.

Also Google on

sleep thread deviation

to find an interesting CodeProject article quantifying behavior on one
particular tester's Windows box. Also see an article it references
for approaches to the question "how do I handle small intervals?"
(short course: you probably can't, unless we're willing to throw
money at it).

Thanks for the references.

What I want to do is waiting(not busy-delaying) for a few tens to
hundreds of microseconds in some threads. The closet solution I got is
using windows QueryPerformanceCounter (in Python, time.clock) with busy
looping checking if we have past the target time. However, that makes
the cpu usage upto almost 100%.

So the problem (waiting tens to hundreds of us without busy looping)
still remains...

 

[Peter Hansen]

So the problem (waiting tens to hundreds of us without busy looping)
still remains...

That's actually not a "problem", it's your solution
to a problem. Can you describe the _real_ problem, what
you are trying to do? _Why_ do you want to wait such
brief amounts of time?

I ask as someone with fairly extensive background in
realtime software (which is basically what it sounds like
you are trying to write here), and I suspect that you are
either trying to achieve something that's not really possible
on Windows XP, or that you are simply doing something that
is entirely unnecessary, probably for good reasons but
with too little experience of the issues involved. Can
you expand on your situation?

-Peter

 

[Tim Peters]

[Tim Peters]

Python's time.sleep() calls the Win32 API Sleep() function on
Windows. All behavior is inherited from the latter. See MS's docs:


<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/sleep.asp>

[[email protected]]
Oh, after a short research, I found that time.sleep uses its customized
way of sleeping using "select".

[http://groups.google.com/[email protected]]

So I think its behaviour is more complicated than single MS Sleep call,
I suppose.

Sorry, the information you found is wrong, as a brief look at Python's
timemodule.c will confirm. select() is used to implement time.sleep()
on Unixish boxes, but, contrary to the thread you found, it's not
possible to do that on Windows -- the Winsock select() requires at
least one of its socket-set arguments to be non-empty (see MS's
select() docs -- they're telling the truth too <wink>). Abusing
select() for "short sleeps" is an ugly (but effective) hack limited to
Unixish systems.

....

What I want to do is waiting(not busy-delaying) for a few tens to
hundreds of microseconds in some threads. The closet solution I got is
using windows QueryPerformanceCounter (in Python, time.clock) with busy
looping checking if we have past the target time. However, that makes
the cpu usage upto almost 100%.

So the problem (waiting tens to hundreds of us without busy looping)
still remains...

I agree with Peter Hansen's reply here, so please respond to it.
Windows is not a real-time OS, so what you want to do either cannot be
done on Windows, or you're approaching your actual problem (whatever
that may be) in a way that doesn't make good sense.

 

[Bengt Richter]

On 9 Jan 2005 03:09:27 -0800, (e-mail address removed) wrote:
[...]

What I want to do is waiting(not busy-delaying) for a few tens to
hundreds of microseconds in some threads. The closet solution I got is
using windows QueryPerformanceCounter (in Python, time.clock) with busy
looping checking if we have past the target time. However, that makes
the cpu usage upto almost 100%.

So the problem (waiting tens to hundreds of us without busy looping)
still remains...

Microseconds is tough if you are going to give up control to a scheduling/dispatching
mechanism that works in milliseconds (e.g. 10ms normal slice on NT4), and where
badly written interrupt handling may cause significant latency hiccups. There's a reason
CD burners come with big buffers.

One question is if you are waiting for an event that causes and interrupt, or if you are guaranteeing
a delay to give something a chance to happen (e.g. like some pysical process like a sound echo)
so you can read a sensor interface at an appropriate time after starting some process,
or whether you're waiting for an event that originates in another thread running under ordinary
scheduling constraints.

If you want close time control under windows, you may have to write driver-level software
and/or raise priorities to real-time levels and make sure those things don't run very long before
blocking. I suspect that multimedia support stuff in windows might be useful for quasi-real-time
stuff, but I haven't used it. (I just seem to remember reading something about that in the MSDN docs,
but I am not sure. And too lazy to go back and look ;-)

Regards,
Bengt Richter

 

[janeaustine50]

That's actually not a "problem", it's your solution
to a problem. Can you describe the _real_ problem, what
you are trying to do? _Why_ do you want to wait such
brief amounts of time?

I ask as someone with fairly extensive background in
realtime software (which is basically what it sounds like
you are trying to write here), and I suspect that you are
either trying to achieve something that's not really possible
on Windows XP, or that you are simply doing something that
is entirely unnecessary, probably for good reasons but
with too little experience of the issues involved. Can
you expand on your situation?

-Peter

What I am trying to do is sending binary data to a serial port. Since
the device attached to the port cannot handle a continous in-flow of
data, I need to make an artificial tiny delay in-between data chunks(a
few hundreds of KBs). The delay might be a few tens to hundreds of us.

I'd like to make the transmission as fast as possible, uh.. well..
reasonably fast.

[I sort of posted this already but hasn't got it through so am
reposting it now]

Thanks

 

[Peter Hansen]

What I am trying to do is sending binary data to a serial port. Since
the device attached to the port cannot handle a continous in-flow of
data, I need to make an artificial tiny delay in-between data chunks(a
few hundreds of KBs). The delay might be a few tens to hundreds of us.

I guess you've checked that your situation can't take advantage
of either hardware handshaking (e.g. RTS/CTS) or software handshaking
(Xon/Xoff) to do flow control.

Something doesn't quite feel right in your description, however,
but it could simply be because the sorts of devices we work with
are quite different. I'm very surprised to hear about a device
that can manage to absorb *hundreds of KBs* of data without any
handshaking, and yet after that much data suddenly manages to
have a hiccup on the order of mere microseconds before it can
take more data.

Also, is your data rate so high that a few hundred microseconds
represents a noticeable delay? I'm rarely dealing with data
rates higher than, say, 38400bps, where hundreds of KBs would take
on the order of minutes, so 100us is effectively instantaneous
in my world.

I calculate that your data rate would have to be higher than
307Mbps (a third of a gigabit per second) before 100us would
represent a large enough delay (measured in bits rather than
time) that you would be bothered by it... (defined somewhat
arbitrarily as more than 2% of the time required to send
100KB of data at your data rate).

I'd like to make the transmission as fast as possible, uh.. well..
reasonably fast.

I suspect it will be, if you simply do a time.sleep(0.001) and
pretend that's shorter than it really is... since WinXP
is not a realtime OS, sometimes that could take as long as
hundreds of milliseconds, but it's very unlikely that anyone
will ever notice.

-Peter