I am seeing interrupt latencies of up to 120 microseconds if I resize a pterm that is
displaying continuous output using devg-matroxg. If I switch the video
card to the ati-rage128 the issue goes away.
The interrupt I am measuring the latency of is at IRQ9, and the video is at IRQ10,
so it’s not a priority issue. devg-matroxg must be disabling all interrupts
for this time. Running 6.2.1 on a PC.
–
Art Hays
National Institutes of Health
avhays@nih.gov
May be, may be not.
According to PCI spec (2.2) no bus master may hold the bus for more than 8
PCI cycles in a row (well, 8 + 1 because it may hold it for one more cycle
after #GNT was deasserted). This is of course non-enforceable, since a
non-compliant device can hold the bus even after the arbiter deasserts #GNT.
The spec also recommends that all devices that detect a non-compliant
behavior on the bus, should cease activity (in hope the bad guy gets what he
wanted and goes away). So the bad guys rule 
The spec also does not say how exactly the arbitration must be performed.
Most x86 implementations use ‘fairness’ approach. It is adjustable to some
extent (and some designs have programmable arbiter so that the arbitration
scheme may be changed by software). If memory serves me well, each device
has ‘Min Gnt’ and ‘Max Lat’ parameters in the PCI header, that are treated
by the PCI as ‘requests’, based on which they get assigned ‘effective’
Latency parameter and (ideally) IRQ level. The arbiter is supposed to make a
decision about granting the bus based on its idea about ‘fairness’ and the
assigned latency parameter. This whole scheme works essentially like a
‘cooperative multitasking’ with those parameters being some kind of
equivalent for the priority. They don’t call it ‘Wintel’ for no reason
Then of course, the driver may be the bad guy. For all I know, video and
realtime do not go along well. Not on x86 anyway, it was simply not designed
for that.
– igor
“Art Hays” <avhays@nih.gov> wrote in message
news:behkjj$j81$1@inn.qnx.com…
I am seeing interrupt latencies of up to 120 microseconds if I resize a
pterm that is
displaying continuous output using devg-matroxg. If I switch the video
card to the ati-rage128 the issue goes away.The interrupt I am measuring the latency of is at IRQ9, and the video is
at IRQ10,
so it’s not a priority issue. devg-matroxg must be disabling all
interrupts
for this time. Running 6.2.1 on a PC.–
Art Hays
National Institutes of Health
avhays@nih.gov
But the graphics card is on the AGP bus. Can it still tie up
the PCI slots?
“Igor Kovalenko” <kovalenko@attbi.com> wrote in message news:bei8gs$av8$1@inn.qnx.com…
May be, may be not.
According to PCI spec (2.2) no bus master may hold the bus for more than 8
PCI cycles in a row (well, 8 + 1 because it may hold it for one more cycle
after #GNT was deasserted). This is of course non-enforceable, since a
non-compliant device can hold the bus even after the arbiter deasserts #GNT.
The spec also recommends that all devices that detect a non-compliant
behavior on the bus, should cease activity (in hope the bad guy gets what he
wanted and goes away). So the bad guys rule >The spec also does not say how exactly the arbitration must be performed.
Most x86 implementations use ‘fairness’ approach. It is adjustable to some
extent (and some designs have programmable arbiter so that the arbitration
scheme may be changed by software). If memory serves me well, each device
has ‘Min Gnt’ and ‘Max Lat’ parameters in the PCI header, that are treated
by the PCI as ‘requests’, based on which they get assigned ‘effective’
Latency parameter and (ideally) IRQ level. The arbiter is supposed to make a
decision about granting the bus based on its idea about ‘fairness’ and the
assigned latency parameter. This whole scheme works essentially like a
‘cooperative multitasking’ with those parameters being some kind of
equivalent for the priority. They don’t call it ‘Wintel’ for no reason >Then of course, the driver may be the bad guy. For all I know, video and
realtime do not go along well. Not on x86 anyway, it was simply not designed
for that.– igor
“Art Hays” <> avhays@nih.gov> > wrote in message
news:behkjj$j81$> 1@inn.qnx.com> …
I am seeing interrupt latencies of up to 120 microseconds if I resize a
pterm that is
displaying continuous output using devg-matroxg. If I switch the video
card to the ati-rage128 the issue goes away.The interrupt I am measuring the latency of is at IRQ9, and the video is
at IRQ10,
so it’s not a priority issue. devg-matroxg must be disabling all
interrupts
for this time. Running 6.2.1 on a PC.–
Art Hays
National Institutes of Health
avhays@nih.gov
\
The AGP is a ‘special’ PCI bus hanging off a northbridge and runs at a
higher data rate because its data lines are not shared with anything else.
One could think of it as a high-speed ‘expressway’ in a city. You can run
faster when the light is green, but you still need to have the green at the
next ‘intersection’ (when your bus grant expires and your burst transfer is
still unfinished) or you’ll have to stop. The arbitration is done by the
northbridge (aka host-PCI bridge) and therefore is common for all PCI busses
(it has to be due to the PCI ‘protocol’ allowing a bus grant to be given to
only one device at any given time).
Of course the arbiter may think that ‘AGP device must be important’ and
favor it over other devices. If an AGP card has a high ‘min grant’ request
the arbiter might just satisfy it at the expense of others and give it
‘longer’ green lights. The PCI spec before 2.2 was kinda vague on how long
one device can hold a bus, so a 2.1-compliant card can hold it for quite
long time. Or the AGP card itself may think it is so important and keep
trying to finish the transaction regardless of the arbiter removing the
grant.
Finally, I don’t think QNX actually drives the AGP bus to its full
capability (it is treated just like regular PCI with no AGP-specific
features being utilized), which may aggravate situation for some cards.
“Art Hays” <avhays@nih.gov> wrote in message
news:beiml5$pc6$1@inn.qnx.com…
But the graphics card is on the AGP bus. Can it still tie up
the PCI slots?“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:bei8gs$av8$> 1@inn.qnx.com> …
May be, may be not.According to PCI spec (2.2) no bus master may hold the bus for more than
8
PCI cycles in a row (well, 8 + 1 because it may hold it for one more
cycle
after #GNT was deasserted). This is of course non-enforceable, since a
non-compliant device can hold the bus even after the arbiter deasserts
#GNT.
The spec also recommends that all devices that detect a non-compliant
behavior on the bus, should cease activity (in hope the bad guy gets
what he
wanted and goes away). So the bad guys rule >The spec also does not say how exactly the arbitration must be
performed.
Most x86 implementations use ‘fairness’ approach. It is adjustable to
some
extent (and some designs have programmable arbiter so that the
arbitration
scheme may be changed by software). If memory serves me well, each
device
has ‘Min Gnt’ and ‘Max Lat’ parameters in the PCI header, that are
treated
by the PCI as ‘requests’, based on which they get assigned ‘effective’
Latency parameter and (ideally) IRQ level. The arbiter is supposed to
make a
decision about granting the bus based on its idea about ‘fairness’ and
the
assigned latency parameter. This whole scheme works essentially like a
‘cooperative multitasking’ with those parameters being some kind of
equivalent for the priority. They don’t call it ‘Wintel’ for no reason
Then of course, the driver may be the bad guy. For all I know, video and
realtime do not go along well. Not on x86 anyway, it was simply not
designed
for that.– igor
“Art Hays” <> avhays@nih.gov> > wrote in message
news:behkjj$j81$> 1@inn.qnx.com> …
I am seeing interrupt latencies of up to 120 microseconds if I resize
a
pterm that is
displaying continuous output using devg-matroxg. If I switch the
video
card to the ati-rage128 the issue goes away.The interrupt I am measuring the latency of is at IRQ9, and the video
is
at IRQ10,
so it’s not a priority issue. devg-matroxg must be disabling all
interrupts
for this time. Running 6.2.1 on a PC.–
Art Hays
National Institutes of Health
avhays@nih.gov
\
Art Hays <avhays@nih.gov> wrote:
I am seeing interrupt latencies of up to 120 microseconds if I resize a pterm that is
displaying continuous output using devg-matroxg. If I switch the video
card to the ati-rage128 the issue goes away.
I’ve reproduced the problem…
There’s a bug in the matroxg driver. There was one spot where it wasn’t
waiting for free FIFO space before writing to the draw engine registers.
This meant the chip would not complete a write cycle to the draw
engine registers until FIFO space became available. Thus the CPU
was being stalled for long periods of time.
I’ve filed a bug report, to make sure the fix makes it into a
release or patch ASAP.
Thank you for reporting this!
Dave
In the early days of PCI there were many (cheaper) devices that cheated and
wouldn’t let go of the bus. It made their device look faster while making
every other device appear faulty. Back in QNX4 we used pci_write to adjust
down the Max Latency or Latency counter or some such sillyness.
I don’t know if there is a pci_write equivlent for QNX6. If there is,
you’ll have to adjust this every time you re-boot (in a script).
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Igor Kovalenko” <kovalenko@attbi.com> wrote in message
news:bei8gs$av8$1@inn.qnx.com…
May be, may be not.
According to PCI spec (2.2) no bus master may hold the bus for more than 8
PCI cycles in a row (well, 8 + 1 because it may hold it for one more cycle
after #GNT was deasserted). This is of course non-enforceable, since a
non-compliant device can hold the bus even after the arbiter deasserts
#GNT.
The spec also recommends that all devices that detect a non-compliant
behavior on the bus, should cease activity (in hope the bad guy gets what
he
wanted and goes away). So the bad guys rule >The spec also does not say how exactly the arbitration must be performed.
Most x86 implementations use ‘fairness’ approach. It is adjustable to some
extent (and some designs have programmable arbiter so that the arbitration
scheme may be changed by software). If memory serves me well, each device
has ‘Min Gnt’ and ‘Max Lat’ parameters in the PCI header, that are treated
by the PCI as ‘requests’, based on which they get assigned ‘effective’
Latency parameter and (ideally) IRQ level. The arbiter is supposed to make
a
decision about granting the bus based on its idea about ‘fairness’ and the
assigned latency parameter. This whole scheme works essentially like a
‘cooperative multitasking’ with those parameters being some kind of
equivalent for the priority. They don’t call it ‘Wintel’ for no reason >Then of course, the driver may be the bad guy. For all I know, video and
realtime do not go along well. Not on x86 anyway, it was simply not
designed
for that.– igor
“Art Hays” <> avhays@nih.gov> > wrote in message
news:behkjj$j81$> 1@inn.qnx.com> …
I am seeing interrupt latencies of up to 120 microseconds if I resize a
pterm that is
displaying continuous output using devg-matroxg. If I switch the video
card to the ati-rage128 the issue goes away.The interrupt I am measuring the latency of is at IRQ9, and the video is
at IRQ10,
so it’s not a priority issue. devg-matroxg must be disabling all
interrupts
for this time. Running 6.2.1 on a PC.–
Art Hays
National Institutes of Health
avhays@nih.gov
\