Art Hays <avhays@nih.gov> wrote:
Tested with same conditions, same machine, on 6.1 the max interrupt latency
I see is 120usec (4usec typical). This happens when I scroll a window, rage
driver. Is this just a problem with the rage driver locking out
interrupts? Would other display drivers give me the 4.25 performance?
Art,
Can you get the device ID of the rage chip, from the ‘pci’ utility?
There used to be a bug in the devg-rage.so driver where it would write to
certain registers without checking a FIFO status bit first. This would
cause the Rage chip to insert wait states on the bus, which would block
the CPU, starving interrupt handlers etc. This was fixed way back, I
verified that I can not longer reproduce the problem on 6.1 with a
Rage II card. However, you may have chip that behaves differently…
BTW this bug was present under Photon 1.1x at one point also (Pg.rage),
where it’s also been fixed.
Dave
Armin Steinhoff wrote:
… and the remaining question why the Rage 128 driver kills the
realtime performance of QNX6.
Is it the driver? Is it a burst transmission of data at the PCI/AGP bus
??
What are the reasons ???
It must be the driver, since running QNX4 on the same machine does not
appear anywhere near so problematic, and the long worst case only
happens with video activity (OTOH 17usec is not all that good on a
450Mhz - I wouldn’t be surprised if the worst case latency was around
5usec with the highest priority interrupt, and no video on QNX4).
For this setup I would be interested in hearing what the worst case
latency is without the video scrolling. Art only mentions the 120usec
with the scrolling action on the rage; any comments Art ?
Rennie
Igor Kovalenko wrote:
“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C8E6FCA.9486DAC8@web_.de…
Any execution of a longer path can be preempted …
The extra work needed to set up protection
probably does contribute to longer latency, since it has to be done before
interrupt handler is invoked.
If making a pre-emptible kernel involved nothing more than removing some
cli/sti’s, I would imagine that this would have been done for QNX4 long
ago 
.
Rennie
“Rennie Allen” <rallen@csical.com> wrote in message news:3C90CE3D.1000306@csical.com…
Armin Steinhoff wrote:
… and the remaining question why the Rage 128 driver kills the
realtime performance of QNX6.
Is it the driver? Is it a burst transmission of data at the PCI/AGP bus
??
What are the reasons ???
It must be the driver, since running QNX4 on the same machine does not
appear anywhere near so problematic, and the long worst case only
happens with video activity (OTOH 17usec is not all that good on a
450Mhz - I wouldn’t be surprised if the worst case latency was around
5usec with the highest priority interrupt, and no video on QNX4).
For this setup I would be interested in hearing what the worst case
latency is without the video scrolling. Art only mentions the 120usec
with the scrolling action on the rage; any comments Art ?
Our application does use the display- it has a couple of oscilloscope type windows going
all the time. This doesnt seem to cause any problems with latency. However, when I put
up the help browser and then use the scroll bars to scroll the window I see the long
latency appear.
In order to really pin this down I am going to write a small process with an ISR for some
counter/timer cards I have. This will separate the test from our big multi-process,
multi-threaded application. I will try it interrupting on the ISA and PCI buses. I will
also try this with the TNT driver under the 6.2 beta. This should hopefully isolate the
problem satisfactorily, whether it’s me or the driver.
“David Donohoe” <ddonohoe@qnx.com> wrote in message news:a6qih9$ao7$1@nntp.qnx.com…
Art Hays <> avhays@nih.gov> > wrote:
Tested with same conditions, same machine, on 6.1 the max interrupt latency
I see is 120usec (4usec typical). This happens when I scroll a window, rage
driver. Is this just a problem with the rage driver locking out
interrupts? Would other display drivers give me the 4.25 performance?
Art,
Can you get the device ID of the rage chip, from the ‘pci’ utility?
4742h Rage 3D Pro AGP 2x. It’s integrated on the motherboard.
There used to be a bug in the devg-rage.so driver where it would write to
certain registers without checking a FIFO status bit first. This would
cause the Rage chip to insert wait states on the bus, which would block
the CPU, starving interrupt handlers etc. This was fixed way back, I
verified that I can not longer reproduce the problem on 6.1 with a
Rage II card. However, you may have chip that behaves differently…
BTW this bug was present under Photon 1.1x at one point also (Pg.rage),
where it’s also been fixed.
Dave
Art Hays <avhays@nih.gov> wrote:
For this setup I would be interested in hearing what the worst case
latency is without the video scrolling. Art only mentions the 120usec
with the scrolling action on the rage; any comments Art ?
Our application does use the display- it has a couple of oscilloscope
type windows going all the time. This doesnt seem to cause any problems
with latency. However, when I put up the help browser and then use the
scroll bars to scroll the window I see the long latency appear.
Hm…blitting vs non-blitting?
I think it is probably the driver/hardware interaction somewhere in
there.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“Art Hays” <avhays@nih.gov> wrote in message news:a6qnci$i72$1@inn.qnx.com…
In order to really pin this down I am going to write a small process with an ISR for
some
counter/timer cards I have. This will separate the test from our big multi-process,
multi-threaded application. I will try it interrupting on the ISA and PCI buses. I
will
also try this with the TNT driver under the 6.2 beta. This should hopefully isolate the
problem satisfactorily, whether it’s me or the driver.
Results from tests described above with interrupt on ISA bus:
1.) Problem under 6.1 is with the rage driver.
2.) Latency problem is not present with rage driver in 6.2 (good news!).
Since the problem disappeared with 6.2 I did not pursue testing on the PCI bus
or with the TNT driver.
An aside- I couldnt get the 6.2 beta to boot on this machine (6.1 boots fine). It’s a
Dell Optiplex 450,
about 4 years old.
Problem turned out to be the CD drive was too old. I guess there are some compatibility
issues
with some older CD drives.
Art Hays <avhays@nih.gov> wrote:
“David Donohoe” <> ddonohoe@qnx.com> > wrote in message news:a6qih9$ao7$> 1@nntp.qnx.com> …
4742h Rage 3D Pro AGP 2x. It’s integrated on the motherboard.
We tried this card, but couldn’t see the problem. While it’s possible
that the rage driver is causing “some” interrupt latency, I have
verified that it does not cause enough to starve the clock interrupt.
This program (x86 only) attaches to the clock interrupt and
toggles the speaker bit on every tick. Back when we found the
problem with the driver, graphics activity would cause
crackle in the tone being generated, but it no longer does this.
It would be interesting to see what happens if you run this on your
system.
Dave
#include <sys/neutrino.h>
#include <stdio.h>
#include <hw/inout.h>
const struct sigevent *
tick(void *arg, int id)
{
static bit;
out8(0x61, (in8(0x61) & ~3) | bit);
bit = bit ? 0 : 2;
return NULL;
}
main()
{
ThreadCtl(_NTO_TCTL_IO, 0);
InterruptAttach(_NTO_INTR_CLASS_EXTERNAL, tick, NULL, 0,
_NTO_INTR_FLAGS_END);
sleep(1000);
}