Sorry! 153msec NOT 135msec

Sorry! 153msec NOT 135msec

Post by Bermie Fow » Thu, 26 May 2005 03:04:45


Hi

I am trying to get "near-Real Time performance" on XP.
Something occurs at every 153msecs?
I have tried shutting down nearly all services but the
disturbance persists.
Any suggestions what it might be (or how I might go
about tracking the service/driver down)?

Thanks,

Bernie
 
 
 

Sorry! 153msec NOT 135msec

Post by Paul Keina » Thu, 26 May 2005 08:13:09

On Tue, 24 May 2005 19:04:45 +0100, "Bermie Fowler"




As long as you do not touch the Windows message queue even with a long
stick (e.g. WM_TIMER messages :-) you might get some reasonable
performance with the multimedia timer callbacks (provided that the
process that invoked that request was already running in the real time
priority class).

Paul

 
 
 

Sorry! 153msec NOT 135msec

Post by Bermie Fow » Fri, 27 May 2005 04:23:25

Hi,

I am using the Ardence (was Venturcom) RTX for Windows.
The RTX based tasks comfortably run in real time (at 1KHz).
However, I need to use a Win32 driver (Firewire/1394)
and therefore have set my system up so that a Win32 process waits on a
WaitForSingleObject event, which is stimmed at 1 KHz, from an RTX process.
The W32 Process is running at real time priority!
This design almost gets my W32 task to run at 1KHz (i.e. every msec) except
that every 153 msec. the Wait seems to be held-off for about
3 or 4 msec. after which time I get 3 or 4 events in rapid succession.

If I could get an RTX compatible driver (for 1394b) then I could do
everything under RTX and there would be no problem!

Bernie
 
 
 

Sorry! 153msec NOT 135msec

Post by Paul Keina » Fri, 27 May 2005 16:28:01

On Wed, 25 May 2005 20:23:25 +0100, "Bermie Fowler"



You should have told this in your original message :-).

In the late 1990's some interface cards (or their drivers) were badly
behaving by hijacking the system for several milliseconds at a time.
Some Ethernet cards, some IDE drivers had this kind of problems. Also
some graphic cards did not properly monitor the PCI bus signals (and
thus hijacking the PCI bus) in order to get the maximum frame rate out
of the card. However, I have not heard of such problems recently.

I have no idea how Firewire cards behave these days. Perhaps testing
with an other Firewire card with a different chip set and an other
driver might give some hints. There might be a temptation for Firewire
card manufacturer to optimise throughput over realtime responsiveness.

Since the RTX runs comfortably, this can not be a problem with SMM
interrupts.


If you just created the process in REALTIME_PRIORITY_CLASS, it will
run at priority 24. Starting with Win2000, the thread priority can be
set to any value between 16 and 31, while previously only a selected
priority levels (16, 22-26, 31) were available in Win 3.5x and NT4.
Based on observations during the NT4 to Win2000 transition, it appears
as if Microsoft has moved some user interface related functionality
(apparently to improve "experienced responsiveness") into the 27-30
range.

It would be a good idea to increase your thread priority one at the
time from 24 to 31 and test, when that hiccup disappears and leave the
priority there. Of course, the thread should do as little work as
possible at these priority levels.

Paul