Real-Time Problems - Reason Graphics Card?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Hi all,
I have some problems establishing a periodic task of 1KHz on a particular
machine. It runs fine on other machines.

Here is the architecture:

  • hardware board triggers interrupts at 1KHz, IRQ 5
  • ISR increases sequence counter and triggers pulse at prio 63
  • Handler process at prio 63 does a MsgReceivePulse, increases own sequence
    counter and compares it with the sequence counter of the ISR. If not equal,
    it terminates

The handler process is falling behind once in a while. It seems that it is
related to graphic output (e.g.opening the helpviewer).
I want to use ClockCycles() to measure some latencies, but maybe somebody
has an idea right now?

It is a QNX 6.2.0 machine.
This is the graphics card:

2

Sorry here is the missing part:

Class = Display (VGA)
Vendor ID = 102bh, Matrox
Device ID = 519h, MGA-2064W Millenium GUI Accelerator
PCI index = 0h
Class Codes = 030000h
Revision ID = 1h
Bus number = 0
Device number = 13
Function num = 0
Status Reg = 280h
Command Reg = 82h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI Mem Address = e1000000h 32bit length 16384 enabled
PCI Mem Address = e2000000h prefetchable 32bit length 8388608 enabled
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10

The machine is a 1Ghz machine.
Thanks
Markus


“Markus Loffler” <markus@qrts.com> schrieb im Newsbeitrag
news:b9mlhm$49p$1@inn.qnx.com…

Hi all,
I have some problems establishing a periodic task of 1KHz on a particular
machine. It runs fine on other machines.

Here is the architecture:

  • hardware board triggers interrupts at 1KHz, IRQ 5
  • ISR increases sequence counter and triggers pulse at prio 63
  • Handler process at prio 63 does a MsgReceivePulse, increases own
    sequence
    counter and compares it with the sequence counter of the ISR. If not
    equal,
    it terminates

The handler process is falling behind once in a while. It seems that it is
related to graphic output (e.g.opening the helpviewer).
I want to use ClockCycles() to measure some latencies, but maybe somebody
has an idea right now?

It is a QNX 6.2.0 machine.
This is the graphics card:
\

3

Markus Loffler wrote:

Sorry here is the missing part:

Class = Display (VGA)
Vendor ID = 102bh, Matrox
Device ID = 519h, MGA-2064W Millenium GUI Accelerator
PCI index = 0h
Class Codes = 030000h
Revision ID = 1h
Bus number = 0
Device number = 13
Function num = 0
Status Reg = 280h
Command Reg = 82h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI Mem Address = e1000000h 32bit length 16384 enabled
PCI Mem Address = e2000000h prefetchable 32bit length 8388608 enabled
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10

The machine is a 1Ghz machine.
Thanks
Markus



“Markus Loffler” <> markus@qrts.com> > schrieb im Newsbeitrag
news:b9mlhm$49p$> 1@inn.qnx.com> …
Hi all,
I have some problems establishing a periodic task of 1KHz on a particular
machine. It runs fine on other machines.

Here is the architecture:

  • hardware board triggers interrupts at 1KHz, IRQ 5
  • ISR increases sequence counter and triggers pulse at prio 63
  • Handler process at prio 63 does a MsgReceivePulse, increases own
    sequence
    counter and compares it with the sequence counter of the ISR. If not
    equal,
    it terminates

The handler process is falling behind once in a while. It seems that it is
related to graphic output (e.g.opening the helpviewer).
I want to use ClockCycles() to measure some latencies, but maybe somebody
has an idea right now?

It is a QNX 6.2.0 machine.
This is the graphics card:

\

What is the priority of your process? Try raising its priority above
12(This is the priority of io-graphics). That should do the trick!
Frank

4

What is the priority of your process? Try raising its priority above
12(This is the priority of io-graphics). That should do the trick!
Frank

Well, it’s 63… :wink:


“Markus Loffler” <> markus@qrts.com> > schrieb im Newsbeitrag
news:b9mlhm$49p$> 1@inn.qnx.com> …
Hi all,
I have some problems establishing a periodic task of 1KHz on a
particular
machine. It runs fine on other machines.

Here is the architecture:

  • hardware board triggers interrupts at 1KHz, IRQ 5
  • ISR increases sequence counter and triggers pulse at prio 63
  • Handler process at prio 63 does a MsgReceivePulse, increases own
    sequence
    counter and compares it with the sequence counter of the ISR. If not
    equal,
    it terminates

The handler process is falling behind once in a while. It seems that
it is
related to graphic output (e.g.opening the helpviewer).
I want to use ClockCycles() to measure some latencies, but maybe
somebody
has an idea right now?

It is a QNX 6.2.0 machine.
This is the graphics card:





\

5

Markus Loffler <markus@qrts.com> wrote:

Hi all,
I have some problems establishing a periodic task of 1KHz on a particular
machine. It runs fine on other machines.

Here is the architecture:

  • hardware board triggers interrupts at 1KHz, IRQ 5
  • ISR increases sequence counter and triggers pulse at prio 63
  • Handler process at prio 63 does a MsgReceivePulse, increases own sequence
    counter and compares it with the sequence counter of the ISR. If not equal,
    it terminates

The handler process is falling behind once in a while. It seems that it is
related to graphic output (e.g.opening the helpviewer).
I want to use ClockCycles() to measure some latencies, but maybe somebody
has an idea right now?

It may be related not to graphics output – but to program creation,
and under that, to the low-level allocator at process creation time.

Can you test by loading/terming a fairly large program that does not
do any output and see how that compares? (By large, I mean fairly
large code segment, not just a large malloc in it.)

The graphics drivers/chip can also introduce latency problems, but
they are usually interrupt latency, and at the point of reducing the
latency between when your hardware asserts its interrupt and when
the CPU gets the interrupt. Basically they introduce it by bus
contention – they grab and dump a large chunk of data accross the
bus, monopolizing it. But, that would delay the irq, and not be
as likely to delay your process getting scheduled.

The evil that is SMM (system management mode) under x86 land might
also do this sort of thing – but it is less likely to catch you
at just the wrong time.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

6

I had similar problems with a graphics card slowing down real time
performance, maybe worse than this.

I was using a motherboard with a built in intel 815 graphics processor, and
using the enumerated driver for it. I tried playing with the wait states,
cache policies, and settings for the video chips, but I only got temporary
speedups from this. The next reboot after making those changes took me back
to poor performance, like something was not getting initalized correctly by
the driver when it started.

I had to do this:

su -c “slay io-graphics” root
su -c “crttrap start” root
waitfor /dev/photon

… in my startup script (every time I ran my application) to cause the
driver to initialize the hardware correctly.

When I didn’t do this, moving a window would take the processor time to 100%
and it would move Slooooowly. After kicking the graphics driver, the bar
barely went to 1/3 under full load while the app was running.

We finally decided to just add a supported add on graphics card (we
suspected the acceleration modes were getting disabled somehow), and it gave
us better overall performance. Even so, we still noted that “kicking” the
graphics driver before running the app made it run more efficiently.

Not sure this applies to what you are doing, but it sounds similar.

Thanks,

John Eddy

“Frank” <nospam@please.com> wrote in message
news:b9qjo7$daf$1@tiger.openqnx.com…

Markus Loffler wrote:

Sorry here is the missing part:

Class = Display (VGA)
Vendor ID = 102bh, Matrox
Device ID = 519h, MGA-2064W Millenium GUI Accelerator
PCI index = 0h
Class Codes = 030000h
Revision ID = 1h
Bus number = 0
Device number = 13
Function num = 0
Status Reg = 280h
Command Reg = 82h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI Mem Address = e1000000h 32bit length 16384 enabled
PCI Mem Address = e2000000h prefetchable 32bit length 8388608 enabled
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10

The machine is a 1Ghz machine.
Thanks
Markus


“Markus Loffler” <> markus@qrts.com> > schrieb im Newsbeitrag
news:b9mlhm$49p$> 1@inn.qnx.com> …
Hi all,
I have some problems establishing a periodic task of 1KHz on a
particular
machine. It runs fine on other machines.

Here is the architecture:

  • hardware board triggers interrupts at 1KHz, IRQ 5
  • ISR increases sequence counter and triggers pulse at prio 63
  • Handler process at prio 63 does a MsgReceivePulse, increases own
    sequence
    counter and compares it with the sequence counter of the ISR. If not
    equal,
    it terminates

The handler process is falling behind once in a while. It seems that
it is
related to graphic output (e.g.opening the helpviewer).
I want to use ClockCycles() to measure some latencies, but maybe
somebody
has an idea right now?

It is a QNX 6.2.0 machine.
This is the graphics card:





What is the priority of your process? Try raising its priority above
12(This is the priority of io-graphics). That should do the trick!
Frank
\

7

David Gibbs <dagibbs@qnx.com> wrote in message
news:b9rp8i$2ca$1@nntp.qnx.com…

It may be related not to graphics output – but to program creation,
and under that, to the low-level allocator at process creation time.

Can you test by loading/terming a fairly large program that does not
do any output and see how that compares? (By large, I mean fairly
large code segment, not just a large malloc in it.)

Actually if it was the process creation itself, it wouldn’t matter on the
size of the executable.

The graphics drivers/chip can also introduce latency problems, but
they are usually interrupt latency, and at the point of reducing the
latency between when your hardware asserts its interrupt and when
the CPU gets the interrupt. Basically they introduce it by bus
contention – they grab and dump a large chunk of data accross the
bus, monopolizing it. But, that would delay the irq, and not be
as likely to delay your process getting scheduled.

I think using the system analysis tool would be good here - it should shed
some light on what might be happening.

-Adam