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