Erratic interrupt latency

Mario_Charest1 · March 12, 2001, 5:15pm

“Ken Schumm” <kwschumm@qsolv.com> wrote in message
news:Voyager.010312083647.310B@dilbert…

That’s what I’m trying to track down now. I’ve got APM disabled
in the BIOS, but the Ampro docs state that disabling it in the
BIOS doesn’t disable APM. So, I’ve reenabled the BIOS and am
trying to get the free APM stuff working - no luck so far, but
I’m still beating on it.

I thought that APM low power mode was invoked by the idle process.
Since I wrote my own idle that spins fifo at priority 1, I thought
this would fix things but it seemed to have no effect.

What is the mechanism by which APM gets invoked?

I don’t think QNX4 call the APM. I think the only thing that idle
does is call the halt instructions, hence saving power.

Previously, Armin Steinhoff wrote in qdn.public.qnx4:

Hi Ken,

could it be that the handler of the SMI (System Management
Interrupt) does a lot at your machine?
This happens if you have enabled a lot of e.g. power
management actions on the board.

The SMI handler is located in the BIOS … I would try
to minimize all power management and similar activities.

Armin

Ken Schumm wrote:

We’re having some trouble getting consistent interrupt latency on
a QNX 4.25 embedded PC/104 product of ours. Usually the latency is
around 10-15 us as measured on a dso. Sometimes, though, maybe
.001% of the time, this latency stretches out to as much as 120 us.
We need a reliable 4 kHz collection rate, so these 120 us
disturbances often cause data to be lost.

Our product is based around an Ampro 4DXi board (486/133), with an
Ampro MiniModule/LCD II vga card and a custom data acquisition card
of our own design.

I think we have eliminated photon and the graphics subsystem
from consideration. We removed the video card and ran the system
without photon and our gui software with no improvement.

We thought perhaps that the cpu was being put into low power mode
by the idle process, so we wrote our own idle, that spins at
priority one. This made no difference.

Our data collection process is running at priority 29, and proc
at 28. We have rotated the data collection interrupt, using the
-i 7 option to proc, to make it the highest priority interrupt
in the box. We tried both -zn and -zN options to proc to no
avail.

We have also tried killing off most everything except the
main data collection process (supervisor) and this made no
difference.

Ideas are appreciated, sin info is below.

--------------------- sin ------------------------------------
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 10448 0
0 1 sys/Proc32 28f READY — 118k 811k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r RECV 0 77k 409k
0 5 usr/local/tffs/Fsys.doc 10r RECV 0 36k 53k
0 8 /bin/Dev32 24f RECV 0 32k 90k
0 9 /bin/Dev32.ansi 20r RECV 0 40k 49k
0 10 idle 0r READY — 0 0
0 19 //2/bin/nameloc 20o RECV 0 6144 20k
0 20 //2/bin/nameloc 20o REPLY 0 6144 16k
0 24 //2/minya/bin/speaker 10o RECV 0 4096 12k
0 27 //2/minya/bin/dbmgr 10o RECV 0 20k 28k
0 28 //2//bin/supervisor 29f RECV 0 53k 24k
0 35 //2//photon/bin/Photon 10r READY — 57k 28k
0 37 //2//vesabios.ms 10o RECV 0 40k 28k
0 39 //2//drivers/Pg.vga4 12r REPLY 35 118k 118k
0 42 //2//bin/phfontall 10r RECV 0 159k 442k
0 50 //2//bin/Input.mdi8000 12o RECV 0 26k 28k
0 51 //2/minya/bin/gui 10o READY — 122k 114k
0 54 //2/*/bin/Input.mdi8000 10o RECV 0 26k 28k
0 58 //2/bin/Dev32.ser 20r RECV 0 16k 32k
0 64 //2/bin/tinit 10o WAIT -1 16k 28k
0 66 //2/minya/bin/hostif 10o REPLY 8 57k 32k
0 70 //2/bin/dumper 28o RECV 0 16k 20k
1 71 //2/bin/login 10o REPLY 8 24k 20k
2 72 //2/bin/sh 10o WAIT -1 94k 45k
2 84 //2/bin/sin 10o REPLY 1 45k 49k

-------------------- sin ver ---------------------------------
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25I Nov 25 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24S Jul 16 1998
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.aha7scsi scsi 4.24M Mar 23 1998
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.par Dev32.par 4.23G Oct 04 1996
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Mouse Mouse 4.24A Aug 22 1997
//1/bin/Iso9660fsys Iso9660fsys 4.23B Jun 10 1998
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Net Net 4.25B Jul 27 1998
//1/bin/Net.ether1000 Net.ether100 4.24B Jul 24 1998
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1//bin/phfontpfr Photon Font 1.13A Jul 07 1998
//1//usr/ucb/Socklet Socklet 4.25G Dec 08 1998
//1//photon/bin/Photon Photon 1.13D Sep 03 1998
//1//4.25/usr/ucb/Dns Dns 1.00C Jun 30 1998

------------------ sin info -----------------------------------
Node CPU Machine Speed Memory Ticksize Display
Flags
2 486/487 AT 9708 4161k/7962k 10.0ms VGA
Color -3-±---------8P

Heapp Heapf Heapl Heapn Hands Names Sessions Procs Timers Nodes
Virtual
0 0 23256 0 64 100 64 500 125 4
6M/ 25M

Boot from Hard at — – --:-- Locators: 2

------------------ sin irq ------------------------------------
IRQ PID PROGRAM CS:IP DS
-1 8 /bin/Dev32 0005:005760 000D
-1 9 /bin/Dev32.ansi 0005:005DC0 000D
-1 58 //2/bin/Dev32.ser 0005:0024FC 000D
0 1 sys/Proc32 00F0:004CB3 00F8
1 9 /bin/Dev32.ansi 0005:00690C 000D
3 58 //2/bin/Dev32.ser 0005:00177C 000D
4 58 //2/bin/Dev32.ser 0005:0017A4 000D
7 28 //2/*/bin/supervisor 0005:00AE70 000D
13 1 sys/Proc32 00F0:004C77 00F8

Rennie_Allen2 · March 12, 2001, 5:31pm

Previously, Rennie Allen wrote in qdn.public.qnx4:

Perhaps the kernel filters these out for IRQ7, but I can’t imagine
that this simple check would take 100+ us.

Yes. The kernel is supposed to filter the glitches for you, and
yes this will take some time, and yes 100usec would seem to be an
excessively long time.

Augie_Henriques · March 12, 2001, 6:04pm

Just some ideas/questions.

What did you set you ticksize to?

Is it possible to use IRQ 3 instead of 7 (and don’t change the IRQ
priorities)? We tried to change IRQ priorities here, but didn’t work all
that well.

Are you checking interrupt latency or proxy latency?

Did you strip down your IRQ handler to just the part that checks the
latency?

Can you post your IRQ handler code?

Augie Henriques

“Ken Schumm” <kwschumm@qsolv.com> wrote in message
news:Voyager.010309091816.3820A@dilbert…

We’re having some trouble getting consistent interrupt latency on
a QNX 4.25 embedded PC/104 product of ours. Usually the latency is
around 10-15 us as measured on a dso. Sometimes, though, maybe
.001% of the time, this latency stretches out to as much as 120 us.
We need a reliable 4 kHz collection rate, so these 120 us
disturbances often cause data to be lost.

Our product is based around an Ampro 4DXi board (486/133), with an
Ampro MiniModule/LCD II vga card and a custom data acquisition card
of our own design.

I think we have eliminated photon and the graphics subsystem
from consideration. We removed the video card and ran the system
without photon and our gui software with no improvement.

We thought perhaps that the cpu was being put into low power mode
by the idle process, so we wrote our own idle, that spins at
priority one. This made no difference.

Our data collection process is running at priority 29, and proc
at 28. We have rotated the data collection interrupt, using the
-i 7 option to proc, to make it the highest priority interrupt
in the box. We tried both -zn and -zN options to proc to no
avail.

We have also tried killing off most everything except the
main data collection process (supervisor) and this made no
difference.

Ideas are appreciated, sin info is below.

--------------------- sin ------------------------------------
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 10448 0
0 1 sys/Proc32 28f READY — 118k 811k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r RECV 0 77k 409k
0 5 usr/local/tffs/Fsys.doc 10r RECV 0 36k 53k
0 8 /bin/Dev32 24f RECV 0 32k 90k
0 9 /bin/Dev32.ansi 20r RECV 0 40k 49k
0 10 idle 0r READY — 0 0
0 19 //2/bin/nameloc 20o RECV 0 6144 20k
0 20 //2/bin/nameloc 20o REPLY 0 6144 16k
0 24 //2/minya/bin/speaker 10o RECV 0 4096 12k
0 27 //2/minya/bin/dbmgr 10o RECV 0 20k 28k
0 28 //2//bin/supervisor 29f RECV 0 53k 24k
0 35 //2//photon/bin/Photon 10r READY — 57k 28k
0 37 //2//vesabios.ms 10o RECV 0 40k 28k
0 39 //2//drivers/Pg.vga4 12r REPLY 35 118k 118k
0 42 //2//bin/phfontall 10r RECV 0 159k 442k
0 50 //2//bin/Input.mdi8000 12o RECV 0 26k 28k
0 51 //2/minya/bin/gui 10o READY — 122k 114k
0 54 //2/*/bin/Input.mdi8000 10o RECV 0 26k 28k
0 58 //2/bin/Dev32.ser 20r RECV 0 16k 32k
0 64 //2/bin/tinit 10o WAIT -1 16k 28k
0 66 //2/minya/bin/hostif 10o REPLY 8 57k 32k
0 70 //2/bin/dumper 28o RECV 0 16k 20k
1 71 //2/bin/login 10o REPLY 8 24k 20k
2 72 //2/bin/sh 10o WAIT -1 94k 45k
2 84 //2/bin/sin 10o REPLY 1 45k 49k

-------------------- sin ver ---------------------------------
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25I Nov 25 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24S Jul 16 1998
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.aha7scsi scsi 4.24M Mar 23 1998
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.par Dev32.par 4.23G Oct 04 1996
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Mouse Mouse 4.24A Aug 22 1997
//1/bin/Iso9660fsys Iso9660fsys 4.23B Jun 10 1998
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Net Net 4.25B Jul 27 1998
//1/bin/Net.ether1000 Net.ether100 4.24B Jul 24 1998
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1//bin/phfontpfr Photon Font 1.13A Jul 07 1998
//1//usr/ucb/Socklet Socklet 4.25G Dec 08 1998
//1//photon/bin/Photon Photon 1.13D Sep 03 1998
//1//4.25/usr/ucb/Dns Dns 1.00C Jun 30 1998

------------------ sin info -----------------------------------
Node CPU Machine Speed Memory Ticksize Display
Flags
2 486/487 AT 9708 4161k/7962k 10.0ms VGA
Color -3-±---------8P

Heapp Heapf Heapl Heapn Hands Names Sessions Procs Timers Nodes Virtual
0 0 23256 0 64 100 64 500 125 4 6M/
25M

Boot from Hard at — – --:-- Locators: 2

------------------ sin irq ------------------------------------
IRQ PID PROGRAM CS:IP DS
-1 8 /bin/Dev32 0005:005760 000D
-1 9 /bin/Dev32.ansi 0005:005DC0 000D
-1 58 //2/bin/Dev32.ser 0005:0024FC 000D
0 1 sys/Proc32 00F0:004CB3 00F8
1 9 /bin/Dev32.ansi 0005:00690C 000D
3 58 //2/bin/Dev32.ser 0005:00177C 000D
4 58 //2/bin/Dev32.ser 0005:0017A4 000D
7 28 //2/*/bin/supervisor 0005:00AE70 000D
13 1 sys/Proc32 00F0:004C77 00F8

\

Ken_Schumm1 · March 12, 2001, 10:06pm

Previously, Augie Henriques wrote in qdn.public.qnx4:

Just some ideas/questions.

What did you set you ticksize to?
It doesn’t matter. We tried down to .5 ms, but left it at 10ms. 10 ms

is adequate for all the other processes, and the ISR preempts them.

Is it possible to use IRQ 3 instead of 7 (and don’t change the IRQ
priorities)? We tried to change IRQ priorities here, but didn’t work all
that well.
Rotating priority 7 to the highest priority helped reduce jitter

in latency when the com ports are in use, but it didn’t do anything
for this 100 us delay. We can’t use 3 or 4 (in use by on-board
serial ports in the target system). One thing we might try is
jumper 7 & 5 together and mask 5 off in the pic. The hardware
is hard-wired to use IRQ7.

I did monitor the pic for glitches on IRQ7, and never saw one.

Are you checking interrupt latency or proxy latency?
Interrupt latency. One scope probe is on IRQ7 on the bus, the

other is on data pin 1 of the parallel port. We do an outp(0x378,1)
as the first instruction in the ISR, and an outp(0x378,0) as the
last. This lets us check both interrupt latency and ISR duration
with the scope.

Did you strip down your IRQ handler to just the part that checks the
latency?
Can you post your IRQ handler code?
I posted the ISR once before in this thread. It’s pretty short.

Here it is again:

-------------- snip --------------------

#include <stdio.h>
#include <conio.h>
#include <i86.h>
#include <sys/stat.h>
#include <unistd.h>

#include <supervisor.h>

#pragma off (check_stack);

pid_t far AsyncInt( VOID )
{
outp( 0x378, 1 ) ;

/*

Read ISR first, to keep read of dppr from clearing it.
*/

Gbl.isr = Gbl.fpga->isr ;

if( Gbl.isr & DPI )
{
Gbl.imr &= ~DPIE ; // Disable data packet arrival interrupts
Gbl.fpga->imr = Gbl.imr ; // Make it so
}

Gbl.dpsr = Gbl.fpga->dpsr ;
Gbl.dppr = Gbl.fpga->dppr & 0x3fff ;
Gbl.dptr = Gbl.fpga->dptr ;
Gbl.dpcsr= Gbl.fpga->dpcsr;

Gbl.prrh = Gbl.fpga->prrh & 0x000000ff ;
Gbl.prrl = Gbl.fpga->prrl ;

outp( 0x378, 0 ) ;
return( Gbl.iproxy ) ;

} // end AsyncInt()

#pragma on (check_stack);

Augie Henriques

“Ken Schumm” <> kwschumm@qsolv.com> > wrote in message
news:Voyager.010309091816.3820A@dilbert…
We’re having some trouble getting consistent interrupt latency on
a QNX 4.25 embedded PC/104 product of ours. Usually the latency is
around 10-15 us as measured on a dso. Sometimes, though, maybe
.001% of the time, this latency stretches out to as much as 120 us.
We need a reliable 4 kHz collection rate, so these 120 us
disturbances often cause data to be lost.

Our product is based around an Ampro 4DXi board (486/133), with an
Ampro MiniModule/LCD II vga card and a custom data acquisition card
of our own design.

I think we have eliminated photon and the graphics subsystem
from consideration. We removed the video card and ran the system
without photon and our gui software with no improvement.

We thought perhaps that the cpu was being put into low power mode
by the idle process, so we wrote our own idle, that spins at
priority one. This made no difference.

Our data collection process is running at priority 29, and proc
at 28. We have rotated the data collection interrupt, using the
-i 7 option to proc, to make it the highest priority interrupt
in the box. We tried both -zn and -zN options to proc to no
avail.

We have also tried killing off most everything except the
main data collection process (supervisor) and this made no
difference.

Ideas are appreciated, sin info is below.

--------------------- sin ------------------------------------
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 10448 0
0 1 sys/Proc32 28f READY — 118k 811k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r RECV 0 77k 409k
0 5 usr/local/tffs/Fsys.doc 10r RECV 0 36k 53k
0 8 /bin/Dev32 24f RECV 0 32k 90k
0 9 /bin/Dev32.ansi 20r RECV 0 40k 49k
0 10 idle 0r READY — 0 0
0 19 //2/bin/nameloc 20o RECV 0 6144 20k
0 20 //2/bin/nameloc 20o REPLY 0 6144 16k
0 24 //2/minya/bin/speaker 10o RECV 0 4096 12k
0 27 //2/minya/bin/dbmgr 10o RECV 0 20k 28k
0 28 //2//bin/supervisor 29f RECV 0 53k 24k
0 35 //2//photon/bin/Photon 10r READY — 57k 28k
0 37 //2//vesabios.ms 10o RECV 0 40k 28k
0 39 //2//drivers/Pg.vga4 12r REPLY 35 118k 118k
0 42 //2//bin/phfontall 10r RECV 0 159k 442k
0 50 //2//bin/Input.mdi8000 12o RECV 0 26k 28k
0 51 //2/minya/bin/gui 10o READY — 122k 114k
0 54 //2/*/bin/Input.mdi8000 10o RECV 0 26k 28k
0 58 //2/bin/Dev32.ser 20r RECV 0 16k 32k
0 64 //2/bin/tinit 10o WAIT -1 16k 28k
0 66 //2/minya/bin/hostif 10o REPLY 8 57k 32k
0 70 //2/bin/dumper 28o RECV 0 16k 20k
1 71 //2/bin/login 10o REPLY 8 24k 20k
2 72 //2/bin/sh 10o WAIT -1 94k 45k
2 84 //2/bin/sin 10o REPLY 1 45k 49k

-------------------- sin ver ---------------------------------
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25I Nov 25 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24S Jul 16 1998
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.aha7scsi scsi 4.24M Mar 23 1998
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.par Dev32.par 4.23G Oct 04 1996
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Mouse Mouse 4.24A Aug 22 1997
//1/bin/Iso9660fsys Iso9660fsys 4.23B Jun 10 1998
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Net Net 4.25B Jul 27 1998
//1/bin/Net.ether1000 Net.ether100 4.24B Jul 24 1998
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1//bin/phfontpfr Photon Font 1.13A Jul 07 1998
//1//usr/ucb/Socklet Socklet 4.25G Dec 08 1998
//1//photon/bin/Photon Photon 1.13D Sep 03 1998
//1//4.25/usr/ucb/Dns Dns 1.00C Jun 30 1998

------------------ sin info -----------------------------------
Node CPU Machine Speed Memory Ticksize Display
Flags
2 486/487 AT 9708 4161k/7962k 10.0ms VGA
Color -3-±---------8P

Heapp Heapf Heapl Heapn Hands Names Sessions Procs Timers Nodes Virtual
0 0 23256 0 64 100 64 500 125 4 6M/
25M

Boot from Hard at — – --:-- Locators: 2

------------------ sin irq ------------------------------------
IRQ PID PROGRAM CS:IP DS
-1 8 /bin/Dev32 0005:005760 000D
-1 9 /bin/Dev32.ansi 0005:005DC0 000D
-1 58 //2/bin/Dev32.ser 0005:0024FC 000D
0 1 sys/Proc32 00F0:004CB3 00F8
1 9 /bin/Dev32.ansi 0005:00690C 000D
3 58 //2/bin/Dev32.ser 0005:00177C 000D
4 58 //2/bin/Dev32.ser 0005:0017A4 000D
7 28 //2/*/bin/supervisor 0005:00AE70 000D
13 1 sys/Proc32 00F0:004C77 00F8

\

Mitchell_Schoenbrun · March 13, 2001, 6:20am

Hey Ken,

Have you thought of running DejaView a trying to catch the
bugger?

Mitchell

Mitchell Schoenbrun --------- maschoen@pobox.com

Andrew_Thomas1 · March 13, 2001, 12:20pm

Previously, Augie Henriques wrote in qdn.public.qnx4:

If the time spent in the Proxy handler is too long (longer than IRQ
frequency), then you can get an IRQ and trigger the proxy again and again,
etc… Unless the Proxy handler is reentrant, this needs to be taken care
of. Am I wrong?

Yes, you are wrong. The proxy is queued until the next time your
process calls Receive(), at which time the proxy is delivered. The
proxy will never interrupt running code. If you get multiple
interrupts while you are busy processing, you will get multiple
proxies queued. If you need to clear these extra proxies, you can do:
while (Creceive (proxyid, NULL, 0) == proxyid);

If interrupts are occurring faster than you can handle them, then the
proxies will get delivered only on the next Receive(), which may show
up as “latency” depending on where you measure. The downside of using
proxies as bottom-half handlers for interrupts is that the interrupt
handling code is subject to the scheduler instead of being run
effectively at a higher priority than any task (in the interrupt
handler). This is also the upside of using proxies for interrupt
handling.

Cheers,
Andrew

Augie_Henriques · March 13, 2001, 1:54pm

“Ken Schumm” <kwschumm@qsolv.com> wrote in message
news:Voyager.010312140631.9475A@dilbert…

Previously, Augie Henriques wrote in qdn.public.qnx4:
Just some ideas/questions.

What did you set you ticksize to?
It doesn’t matter. We tried down to .5 ms, but left it at 10ms. 10 ms
is adequate for all the other processes, and the ISR preempts them.

You are triggering a proxy at the end of you IRQ. Your ticksize will
determine the proxy latency time.

You should/must make sure that you are not in the proxy when you enter the
IRQ. This would be a problem.

I would recomend taking making things as simple as possible until you find
the problem. I would commenting out all the unnecessary code in the IRQ
handler. I would make the proxy return and do nothing. Take out the serial
stuff, you don’t want IRQ 3 and 4 in the picture at this time. Disable the
serial ports. I would try a different IRQ.

I don’t suppose you can try this on another system (a regular PC)?

We did a lot of extra work here when did this!

Good Luck.

Augie

Is it possible to use IRQ 3 instead of 7 (and don’t change the IRQ
priorities)? We tried to change IRQ priorities here, but didn’t work
all
that well.
Rotating priority 7 to the highest priority helped reduce jitter
in latency when the com ports are in use, but it didn’t do anything
for this 100 us delay. We can’t use 3 or 4 (in use by on-board
serial ports in the target system). One thing we might try is
jumper 7 & 5 together and mask 5 off in the pic. The hardware
is hard-wired to use IRQ7.

I did monitor the pic for glitches on IRQ7, and never saw one.

Are you checking interrupt latency or proxy latency?
Interrupt latency. One scope probe is on IRQ7 on the bus, the
other is on data pin 1 of the parallel port. We do an outp(0x378,1)
as the first instruction in the ISR, and an outp(0x378,0) as the
last. This lets us check both interrupt latency and ISR duration
with the scope.

Did you strip down your IRQ handler to just the part that checks the
latency?
Can you post your IRQ handler code?
I posted the ISR once before in this thread. It’s pretty short.
Here it is again:

-------------- snip --------------------

#include <stdio.h
#include <conio.h
#include <i86.h
#include <sys/stat.h
#include <unistd.h

#include <supervisor.h

#pragma off (check_stack);

pid_t far AsyncInt( VOID )
{
outp( 0x378, 1 ) ;

/*

Read ISR first, to keep read of dppr from clearing it.
*/

Gbl.isr = Gbl.fpga->isr ;

if( Gbl.isr & DPI )
{
Gbl.imr &= ~DPIE ; // Disable data packet arrival interrupts
Gbl.fpga->imr = Gbl.imr ; // Make it so
}

Gbl.dpsr = Gbl.fpga->dpsr ;
Gbl.dppr = Gbl.fpga->dppr & 0x3fff ;
Gbl.dptr = Gbl.fpga->dptr ;
Gbl.dpcsr= Gbl.fpga->dpcsr;

Gbl.prrh = Gbl.fpga->prrh & 0x000000ff ;
Gbl.prrl = Gbl.fpga->prrl ;

outp( 0x378, 0 ) ;
return( Gbl.iproxy ) ;

} // end AsyncInt()

#pragma on (check_stack);

Augie Henriques

“Ken Schumm” <> kwschumm@qsolv.com> > wrote in message
news:Voyager.010309091816.3820A@dilbert…
We’re having some trouble getting consistent interrupt latency on
a QNX 4.25 embedded PC/104 product of ours. Usually the latency is
around 10-15 us as measured on a dso. Sometimes, though, maybe
.001% of the time, this latency stretches out to as much as 120 us.
We need a reliable 4 kHz collection rate, so these 120 us
disturbances often cause data to be lost.

Our product is based around an Ampro 4DXi board (486/133), with an
Ampro MiniModule/LCD II vga card and a custom data acquisition card
of our own design.

I think we have eliminated photon and the graphics subsystem
from consideration. We removed the video card and ran the system
without photon and our gui software with no improvement.

We thought perhaps that the cpu was being put into low power mode
by the idle process, so we wrote our own idle, that spins at
priority one. This made no difference.

Our data collection process is running at priority 29, and proc
at 28. We have rotated the data collection interrupt, using the
-i 7 option to proc, to make it the highest priority interrupt
in the box. We tried both -zn and -zN options to proc to no
avail.

We have also tried killing off most everything except the
main data collection process (supervisor) and this made no
difference.

Ideas are appreciated, sin info is below.

--------------------- sin ------------------------------------
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 10448 0
0 1 sys/Proc32 28f READY — 118k 811k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r RECV 0 77k 409k
0 5 usr/local/tffs/Fsys.doc 10r RECV 0 36k 53k
0 8 /bin/Dev32 24f RECV 0 32k 90k
0 9 /bin/Dev32.ansi 20r RECV 0 40k 49k
0 10 idle 0r READY — 0 0
0 19 //2/bin/nameloc 20o RECV 0 6144 20k
0 20 //2/bin/nameloc 20o REPLY 0 6144 16k
0 24 //2/minya/bin/speaker 10o RECV 0 4096 12k
0 27 //2/minya/bin/dbmgr 10o RECV 0 20k 28k
0 28 //2//bin/supervisor 29f RECV 0 53k 24k
0 35 //2//photon/bin/Photon 10r READY — 57k 28k
0 37 //2//vesabios.ms 10o RECV 0 40k 28k
0 39 //2//drivers/Pg.vga4 12r REPLY 35 118k 118k
0 42 //2//bin/phfontall 10r RECV 0 159k 442k
0 50 //2//bin/Input.mdi8000 12o RECV 0 26k 28k
0 51 //2/minya/bin/gui 10o READY — 122k 114k
0 54 //2/*/bin/Input.mdi8000 10o RECV 0 26k 28k
0 58 //2/bin/Dev32.ser 20r RECV 0 16k 32k
0 64 //2/bin/tinit 10o WAIT -1 16k 28k
0 66 //2/minya/bin/hostif 10o REPLY 8 57k 32k
0 70 //2/bin/dumper 28o RECV 0 16k 20k
1 71 //2/bin/login 10o REPLY 8 24k 20k
2 72 //2/bin/sh 10o WAIT -1 94k 45k
2 84 //2/bin/sin 10o REPLY 1 45k 49k

-------------------- sin ver ---------------------------------
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25I Nov 25 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24S Jul 16 1998
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.aha7scsi scsi 4.24M Mar 23 1998
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.par Dev32.par 4.23G Oct 04 1996
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Mouse Mouse 4.24A Aug 22 1997
//1/bin/Iso9660fsys Iso9660fsys 4.23B Jun 10 1998
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Net Net 4.25B Jul 27 1998
//1/bin/Net.ether1000 Net.ether100 4.24B Jul 24 1998
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1//bin/phfontpfr Photon Font 1.13A Jul 07 1998
//1//usr/ucb/Socklet Socklet 4.25G Dec 08 1998
//1//photon/bin/Photon Photon 1.13D Sep 03 1998
//1//4.25/usr/ucb/Dns Dns 1.00C Jun 30 1998

------------------ sin info -----------------------------------
Node CPU Machine Speed Memory Ticksize Display
Flags
2 486/487 AT 9708 4161k/7962k 10.0ms VGA
Color -3-±---------8P

Heapp Heapf Heapl Heapn Hands Names Sessions Procs Timers Nodes
Virtual
0 0 23256 0 64 100 64 500 125 4
6M/
25M

Boot from Hard at — – --:-- Locators: 2

------------------ sin irq ------------------------------------
IRQ PID PROGRAM CS:IP DS
-1 8 /bin/Dev32 0005:005760 000D
-1 9 /bin/Dev32.ansi 0005:005DC0 000D
-1 58 //2/bin/Dev32.ser 0005:0024FC 000D
0 1 sys/Proc32 00F0:004CB3 00F8
1 9 /bin/Dev32.ansi 0005:00690C 000D
3 58 //2/bin/Dev32.ser 0005:00177C 000D
4 58 //2/bin/Dev32.ser 0005:0017A4 000D
7 28 //2/*/bin/supervisor 0005:00AE70 000D
13 1 sys/Proc32 00F0:004C77 00F8

\

Ken_Schumm1 · March 13, 2001, 3:27pm

Previously, Mitchell Schoenbrun wrote in qdn.public.qnx4:

Hey Ken,

Have you thought of running DejaView a trying to catch the
bugger?

I thought of that, but I was thinking that DejaView wouldn’t
help much with interrupt latency. As I think of it, though,
maybe something is disabling interrupts. I’ll give it a go.
Thank!

[…]

Mario_Charest1 · March 13, 2001, 3:58pm

“Augie Henriques” <augiehenriques@hotmail.com> wrote in message
news:98knm4$31n$1@inn.qnx.com…

“Ken Schumm” <> kwschumm@qsolv.com> > wrote in message
news:Voyager.010312140631.9475A@dilbert…
Previously, Augie Henriques wrote in qdn.public.qnx4:
Just some ideas/questions.

What did you set you ticksize to?
It doesn’t matter. We tried down to .5 ms, but left it at 10ms. 10 ms
is adequate for all the other processes, and the ISR preempts them.

You are triggering a proxy at the end of you IRQ. Your ticksize will
determine the proxy latency time.

Not at all Augie, upon existing the ISR a rescheduling occurs and if
priorities
allows the process to which the proxy should be delivered will receiving it
“immedialtely”. The delivery of the proxy has nothing to do with tick size,
they are asynchrounous.

You should/must make sure that you are not in the proxy when you enter the
IRQ. This would be a problem.

I don’t understand that statement “not in the proxy when you enter the IRQ”

I would recomend taking making things as simple as possible until you find
the problem. I would commenting out all the unnecessary code in the IRQ
handler. I would make the proxy return and do nothing. Take out the
serial
stuff, you don’t want IRQ 3 and 4 in the picture at this time. Disable
the
serial ports. I would try a different IRQ.

I don’t suppose you can try this on another system (a regular PC)?

We did a lot of extra work here when did this!

Good Luck.

Augie

Is it possible to use IRQ 3 instead of 7 (and don’t change the IRQ
priorities)? We tried to change IRQ priorities here, but didn’t work
all
that well.
Rotating priority 7 to the highest priority helped reduce jitter
in latency when the com ports are in use, but it didn’t do anything
for this 100 us delay. We can’t use 3 or 4 (in use by on-board
serial ports in the target system). One thing we might try is
jumper 7 & 5 together and mask 5 off in the pic. The hardware
is hard-wired to use IRQ7.

I did monitor the pic for glitches on IRQ7, and never saw one.

Are you checking interrupt latency or proxy latency?
Interrupt latency. One scope probe is on IRQ7 on the bus, the
other is on data pin 1 of the parallel port. We do an outp(0x378,1)
as the first instruction in the ISR, and an outp(0x378,0) as the
last. This lets us check both interrupt latency and ISR duration
with the scope.

Did you strip down your IRQ handler to just the part that checks the
latency?
Can you post your IRQ handler code?
I posted the ISR once before in this thread. It’s pretty short.
Here it is again:

-------------- snip --------------------

#include <stdio.h
#include <conio.h
#include <i86.h
#include <sys/stat.h
#include <unistd.h

#include <supervisor.h

#pragma off (check_stack);

pid_t far AsyncInt( VOID )
{
outp( 0x378, 1 ) ;

/*

Read ISR first, to keep read of dppr from clearing it.
*/

Gbl.isr = Gbl.fpga->isr ;

if( Gbl.isr & DPI )
{
Gbl.imr &= ~DPIE ; // Disable data packet arrival interrupts
Gbl.fpga->imr = Gbl.imr ; // Make it so
}

Gbl.dpsr = Gbl.fpga->dpsr ;
Gbl.dppr = Gbl.fpga->dppr & 0x3fff ;
Gbl.dptr = Gbl.fpga->dptr ;
Gbl.dpcsr= Gbl.fpga->dpcsr;

Gbl.prrh = Gbl.fpga->prrh & 0x000000ff ;
Gbl.prrl = Gbl.fpga->prrl ;

outp( 0x378, 0 ) ;
return( Gbl.iproxy ) ;

} // end AsyncInt()

#pragma on (check_stack);

Augie Henriques

“Ken Schumm” <> kwschumm@qsolv.com> > wrote in message
news:Voyager.010309091816.3820A@dilbert…
We’re having some trouble getting consistent interrupt latency on
a QNX 4.25 embedded PC/104 product of ours. Usually the latency is
around 10-15 us as measured on a dso. Sometimes, though, maybe
.001% of the time, this latency stretches out to as much as 120 us.
We need a reliable 4 kHz collection rate, so these 120 us
disturbances often cause data to be lost.

Our product is based around an Ampro 4DXi board (486/133), with an
Ampro MiniModule/LCD II vga card and a custom data acquisition card
of our own design.

I think we have eliminated photon and the graphics subsystem
from consideration. We removed the video card and ran the system
without photon and our gui software with no improvement.

We thought perhaps that the cpu was being put into low power mode
by the idle process, so we wrote our own idle, that spins at
priority one. This made no difference.

Our data collection process is running at priority 29, and proc
at 28. We have rotated the data collection interrupt, using the
-i 7 option to proc, to make it the highest priority interrupt
in the box. We tried both -zn and -zN options to proc to no
avail.

We have also tried killing off most everything except the
main data collection process (supervisor) and this made no
difference.

Ideas are appreciated, sin info is below.

--------------------- sin ------------------------------------
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 10448 0
0 1 sys/Proc32 28f READY — 118k 811k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r RECV 0 77k 409k
0 5 usr/local/tffs/Fsys.doc 10r RECV 0 36k 53k
0 8 /bin/Dev32 24f RECV 0 32k 90k
0 9 /bin/Dev32.ansi 20r RECV 0 40k 49k
0 10 idle 0r READY — 0 0
0 19 //2/bin/nameloc 20o RECV 0 6144 20k
0 20 //2/bin/nameloc 20o REPLY 0 6144 16k
0 24 //2/minya/bin/speaker 10o RECV 0 4096 12k
0 27 //2/minya/bin/dbmgr 10o RECV 0 20k 28k
0 28 //2//bin/supervisor 29f RECV 0 53k 24k
0 35 //2//photon/bin/Photon 10r READY — 57k 28k
0 37 //2//vesabios.ms 10o RECV 0 40k 28k
0 39 //2//drivers/Pg.vga4 12r REPLY 35 118k 118k
0 42 //2//bin/phfontall 10r RECV 0 159k 442k
0 50 //2//bin/Input.mdi8000 12o RECV 0 26k 28k
0 51 //2/minya/bin/gui 10o READY — 122k 114k
0 54 //2/*/bin/Input.mdi8000 10o RECV 0 26k 28k
0 58 //2/bin/Dev32.ser 20r RECV 0 16k 32k
0 64 //2/bin/tinit 10o WAIT -1 16k 28k
0 66 //2/minya/bin/hostif 10o REPLY 8 57k 32k
0 70 //2/bin/dumper 28o RECV 0 16k 20k
1 71 //2/bin/login 10o REPLY 8 24k 20k
2 72 //2/bin/sh 10o WAIT -1 94k 45k
2 84 //2/bin/sin 10o REPLY 1 45k 49k

-------------------- sin ver ---------------------------------
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25I Nov 25 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24S Jul 16 1998
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.aha7scsi scsi 4.24M Mar 23 1998
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.par Dev32.par 4.23G Oct 04 1996
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Mouse Mouse 4.24A Aug 22 1997
//1/bin/Iso9660fsys Iso9660fsys 4.23B Jun 10 1998
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Net Net 4.25B Jul 27 1998
//1/bin/Net.ether1000 Net.ether100 4.24B Jul 24 1998
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1//bin/phfontpfr Photon Font 1.13A Jul 07 1998
//1//usr/ucb/Socklet Socklet 4.25G Dec 08 1998
//1//photon/bin/Photon Photon 1.13D Sep 03 1998
//1//4.25/usr/ucb/Dns Dns 1.00C Jun 30 1998

------------------ sin info -----------------------------------
Node CPU Machine Speed Memory Ticksize Display
Flags
2 486/487 AT 9708 4161k/7962k 10.0ms VGA
Color -3-±---------8P

Heapp Heapf Heapl Heapn Hands Names Sessions Procs Timers Nodes
Virtual
0 0 23256 0 64 100 64 500 125 4
6M/
25M

Boot from Hard at — – --:-- Locators: 2

------------------ sin irq ------------------------------------
IRQ PID PROGRAM CS:IP DS
-1 8 /bin/Dev32 0005:005760 000D
-1 9 /bin/Dev32.ansi 0005:005DC0 000D
-1 58 //2/bin/Dev32.ser 0005:0024FC 000D
0 1 sys/Proc32 00F0:004CB3 00F8
1 9 /bin/Dev32.ansi 0005:00690C 000D
3 58 //2/bin/Dev32.ser 0005:00177C 000D
4 58 //2/bin/Dev32.ser 0005:0017A4 000D
7 28 //2/*/bin/supervisor 0005:00AE70 000D
13 1 sys/Proc32 00F0:004C77 00F8

\

Augie_Henriques · March 13, 2001, 4:55pm

“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:98lg8e$7fv$1@nntp.qnx.com…

“Augie Henriques” <> augiehenriques@hotmail.com> > wrote in message
news:98knm4$31n$> 1@inn.qnx.com> …

“Ken Schumm” <> kwschumm@qsolv.com> > wrote in message
news:Voyager.010312140631.9475A@dilbert…
Previously, Augie Henriques wrote in qdn.public.qnx4:
Just some ideas/questions.

What did you set you ticksize to?
It doesn’t matter. We tried down to .5 ms, but left it at 10ms. 10 ms
is adequate for all the other processes, and the ISR preempts them.

You are triggering a proxy at the end of you IRQ. Your ticksize will
determine the proxy latency time.

Not at all Augie, upon existing the ISR a rescheduling occurs and if
priorities
allows the process to which the proxy should be delivered will receiving
it
“immedialtely”. The delivery of the proxy has nothing to do with tick
size,
they are asynchrounous.

Thanks for the correction, Mario. We had problems here with proxy latency,
I posted on QUICS and that was the reply I got from someone at QSSL. I will
have to give this a try sometime.

You should/must make sure that you are not in the proxy when you enter
the
IRQ. This would be a problem.

I don’t understand that statement “not in the proxy when you enter the
IRQ”

If the time spent in the Proxy handler is too long (longer than IRQ
frequency), then you can get an IRQ and trigger the proxy again and again,
etc… Unless the Proxy handler is reentrant, this needs to be taken care
of. Am I wrong?

Augie Henriques

I would recomend taking making things as simple as possible until you
find
the problem. I would commenting out all the unnecessary code in the IRQ
handler. I would make the proxy return and do nothing. Take out the
serial
stuff, you don’t want IRQ 3 and 4 in the picture at this time. Disable
the
serial ports. I would try a different IRQ.

I don’t suppose you can try this on another system (a regular PC)?

We did a lot of extra work here when did this!

Good Luck.

Augie

Is it possible to use IRQ 3 instead of 7 (and don’t change the IRQ
priorities)? We tried to change IRQ priorities here, but didn’t
work
all
that well.
Rotating priority 7 to the highest priority helped reduce jitter
in latency when the com ports are in use, but it didn’t do anything
for this 100 us delay. We can’t use 3 or 4 (in use by on-board
serial ports in the target system). One thing we might try is
jumper 7 & 5 together and mask 5 off in the pic. The hardware
is hard-wired to use IRQ7.

I did monitor the pic for glitches on IRQ7, and never saw one.

Are you checking interrupt latency or proxy latency?
Interrupt latency. One scope probe is on IRQ7 on the bus, the
other is on data pin 1 of the parallel port. We do an outp(0x378,1)
as the first instruction in the ISR, and an outp(0x378,0) as the
last. This lets us check both interrupt latency and ISR duration
with the scope.

Did you strip down your IRQ handler to just the part that checks the
latency?
Can you post your IRQ handler code?
I posted the ISR once before in this thread. It’s pretty short.
Here it is again:

-------------- snip --------------------

#include <stdio.h
#include <conio.h
#include <i86.h
#include <sys/stat.h
#include <unistd.h

#include <supervisor.h

#pragma off (check_stack);

pid_t far AsyncInt( VOID )
{
outp( 0x378, 1 ) ;

/*

Read ISR first, to keep read of dppr from clearing it.
*/

Gbl.isr = Gbl.fpga->isr ;

if( Gbl.isr & DPI )
{
Gbl.imr &= ~DPIE ; // Disable data packet arrival interrupts
Gbl.fpga->imr = Gbl.imr ; // Make it so
}

Gbl.dpsr = Gbl.fpga->dpsr ;
Gbl.dppr = Gbl.fpga->dppr & 0x3fff ;
Gbl.dptr = Gbl.fpga->dptr ;
Gbl.dpcsr= Gbl.fpga->dpcsr;

Gbl.prrh = Gbl.fpga->prrh & 0x000000ff ;
Gbl.prrl = Gbl.fpga->prrl ;

outp( 0x378, 0 ) ;
return( Gbl.iproxy ) ;

} // end AsyncInt()

#pragma on (check_stack);

Augie Henriques

“Ken Schumm” <> kwschumm@qsolv.com> > wrote in message
news:Voyager.010309091816.3820A@dilbert…
We’re having some trouble getting consistent interrupt latency on
a QNX 4.25 embedded PC/104 product of ours. Usually the latency is
around 10-15 us as measured on a dso. Sometimes, though, maybe
.001% of the time, this latency stretches out to as much as 120
us.
We need a reliable 4 kHz collection rate, so these 120 us
disturbances often cause data to be lost.

Our product is based around an Ampro 4DXi board (486/133), with an
Ampro MiniModule/LCD II vga card and a custom data acquisition
card
of our own design.

I think we have eliminated photon and the graphics subsystem
from consideration. We removed the video card and ran the system
without photon and our gui software with no improvement.

We thought perhaps that the cpu was being put into low power mode
by the idle process, so we wrote our own idle, that spins at
priority one. This made no difference.

Our data collection process is running at priority 29, and proc
at 28. We have rotated the data collection interrupt, using the
-i 7 option to proc, to make it the highest priority interrupt
in the box. We tried both -zn and -zN options to proc to no
avail.

We have also tried killing off most everything except the
main data collection process (supervisor) and this made no
difference.

Ideas are appreciated, sin info is below.

--------------------- sin ------------------------------------
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 10448 0
0 1 sys/Proc32 28f READY — 118k 811k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r RECV 0 77k 409k
0 5 usr/local/tffs/Fsys.doc 10r RECV 0 36k 53k
0 8 /bin/Dev32 24f RECV 0 32k 90k
0 9 /bin/Dev32.ansi 20r RECV 0 40k 49k
0 10 idle 0r READY — 0 0
0 19 //2/bin/nameloc 20o RECV 0 6144 20k
0 20 //2/bin/nameloc 20o REPLY 0 6144 16k
0 24 //2/minya/bin/speaker 10o RECV 0 4096 12k
0 27 //2/minya/bin/dbmgr 10o RECV 0 20k 28k
0 28 //2//bin/supervisor 29f RECV 0 53k 24k
0 35 //2//photon/bin/Photon 10r READY — 57k 28k
0 37 //2//vesabios.ms 10o RECV 0 40k 28k
0 39 //2//drivers/Pg.vga4 12r REPLY 35 118k 118k
0 42 //2//bin/phfontall 10r RECV 0 159k 442k
0 50 //2//bin/Input.mdi8000 12o RECV 0 26k 28k
0 51 //2/minya/bin/gui 10o READY — 122k 114k
0 54 //2/*/bin/Input.mdi8000 10o RECV 0 26k 28k
0 58 //2/bin/Dev32.ser 20r RECV 0 16k 32k
0 64 //2/bin/tinit 10o WAIT -1 16k 28k
0 66 //2/minya/bin/hostif 10o REPLY 8 57k 32k
0 70 //2/bin/dumper 28o RECV 0 16k 20k
1 71 //2/bin/login 10o REPLY 8 24k 20k
2 72 //2/bin/sh 10o WAIT -1 94k 45k
2 84 //2/bin/sin 10o REPLY 1 45k 49k

-------------------- sin ver ---------------------------------
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25I Nov 25 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24S Jul 16 1998
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.aha7scsi scsi 4.24M Mar 23 1998
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.par Dev32.par 4.23G Oct 04 1996
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Mouse Mouse 4.24A Aug 22 1997
//1/bin/Iso9660fsys Iso9660fsys 4.23B Jun 10 1998
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Net Net 4.25B Jul 27 1998
//1/bin/Net.ether1000 Net.ether100 4.24B Jul 24 1998
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1//bin/phfontpfr Photon Font 1.13A Jul 07 1998
//1//usr/ucb/Socklet Socklet 4.25G Dec 08 1998
//1//photon/bin/Photon Photon 1.13D Sep 03 1998
//1//4.25/usr/ucb/Dns Dns 1.00C Jun 30 1998

------------------ sin info -----------------------------------
Node CPU Machine Speed Memory Ticksize Display
Flags
2 486/487 AT 9708 4161k/7962k 10.0ms VGA
Color -3-±---------8P

Heapp Heapf Heapl Heapn Hands Names Sessions Procs Timers Nodes
Virtual
0 0 23256 0 64 100 64 500 125 4
6M/
25M

Boot from Hard at — – --:-- Locators: 2

------------------ sin irq ------------------------------------
IRQ PID PROGRAM CS:IP DS
-1 8 /bin/Dev32 0005:005760 000D
-1 9 /bin/Dev32.ansi 0005:005DC0 000D
-1 58 //2/bin/Dev32.ser 0005:0024FC 000D
0 1 sys/Proc32 00F0:004CB3 00F8
1 9 /bin/Dev32.ansi 0005:00690C 000D
3 58 //2/bin/Dev32.ser 0005:00177C 000D
4 58 //2/bin/Dev32.ser 0005:0017A4 000D
7 28 //2/*/bin/supervisor 0005:00AE70 000D
13 1 sys/Proc32 00F0:004C77 00F8

\

Randy_Martin · March 13, 2001, 8:07pm

possibly not as powerful a tool as your scope, but you can see exactly when
the kernel gets your interrupt by using the tools in sysdbg.tgz in the
contributed software section of our site.

one of those tools in there is a mechanism that will allow for a kernel
callout on any defined interrupt… along with a rtdsc timestamp (or
an 8254 timestamp).
this will let you know what the exact kernel latency is before any process
latency comes in to play.

i’d still be concerned though about smm. does ampro tell you anything about
this? our experience on x86 has been that any machine that has this enabled
(laptops are especially bad) will see large latency whenever the smi goes
off (system management interrupt) and then the cpu is held by the smm
firmware until the interrupt is serviced. this is independent of any
operating system in place.

on my laptop, where i can’t disable smm mode, i can see wide latencies of
~ 100-150 microseconds regardless of anything i do with interrupt or
processor priorities.

another note that has been mentioned is that although qnx4 is ‘quite good’
at not running int handlers for too long, all interrupts are not deferred
to process priority. some drivers still do a fair bit of processing in their
isr’s. the serial driver is one… it needs to do a fair bit in the isr in
order to keep data rates high.

Ken Schumm <kwschumm@qsolv.com> wrote:

Previously, Hugh Brown wrote in qdn.public.qnx4:
Well I must say that that’s pretty good performance from a 486/133!
You don’t mention how you are performing your data collection, but
have you tried the system without the ethernet driver, as the NE2000
is not the best solution if you are looking for performance? Also
Fsys.doc could be causing some delays as well.

Hugh.

The ethernet card was installed, and Net started, only to take the
‘sin’ snapshots. It is not present in the target system, which is
a handheld non-networked device. All of the time measurements we
observed were without Net running and without the ethernet card
installed.

I also killed off Fsys.doc (it is only used to boot off of), and
it made no difference.

Our interrupt handler is hooked to IRQ 7, which is the highest
priority interrupt (via Proc’s -i7 option). It is about a dozen
lines long. All it does is read four registers from an fpga, stuff
the values in some global variables, and return a proxy. Below
is the interrupt handler. The outp() instructions are present
only to toggle a pin on the serial port which we monitor with
the scope.

// ------------------- cut here -----------------------

#include <stdio.h
#include <conio.h
#include <i86.h
#include <sys/stat.h
#include <unistd.h

#include <supervisor.h

#pragma off (check_stack);

pid_t far AsyncInt( VOID )
{
outp( 0x378, 1 ) ;

/*

Read ISR first, to keep read of dppr from clearing it.
*/

Gbl.isr = Gbl.fpga->isr ;

/*

For “probe data arrived” interrupts, disable the interrupt

until the probe data can be processed. These are reenabled

in hwint.c when a pulse has been completely handled.
*/

if( Gbl.isr & DPI )
{
Gbl.imr &= ~DPIE ; // Disable data packet arrival interrupts
Gbl.fpga->imr = Gbl.imr ; // Make it so
}

Gbl.dpsr = Gbl.fpga->dpsr ;
Gbl.dppr = Gbl.fpga->dppr & 0x3fff ;
Gbl.dptr = Gbl.fpga->dptr ;
Gbl.dpcsr= Gbl.fpga->dpcsr;

Gbl.prrh = Gbl.fpga->prrh & 0x000000ff ;
Gbl.prrl = Gbl.fpga->prrl ;

outp( 0x378, 0 ) ;
return( Gbl.iproxy ) ;

} // end AsyncInt()

#pragma on (check_stack);

// ------------------------- cut here -------------------------

[…]

–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

Ken_Schumm1 · March 14, 2001, 12:50am

Previously, Randy Martin wrote in qdn.public.qnx4:

possibly not as powerful a tool as your scope, but you can see exactly when
the kernel gets your interrupt by using the tools in sysdbg.tgz in the
contributed software section of our site.

one of those tools in there is a mechanism that will allow for a kernel
callout on any defined interrupt… along with a rtdsc timestamp (or
an 8254 timestamp).
this will let you know what the exact kernel latency is before any process
latency comes in to play.

Thanks for the pointer, Randy. I’ll check out these tools.

i’d still be concerned though about smm. does ampro tell you anything about
this? our experience on x86 has been that any machine that has this enabled
(laptops are especially bad) will see large latency whenever the smi goes
off (system management interrupt) and then the cpu is held by the smm
firmware until the interrupt is serviced. this is independent of any
operating system in place.

I can’t get Ampro to answer any questions. They are arguing with each
other about whose job it is to answer my questions, but no answers have
been forthcoming.

on my laptop, where i can’t disable smm mode, i can see wide latencies of
~ 100-150 microseconds regardless of anything i do with interrupt or
processor priorities.

Ouch!

another note that has been mentioned is that although qnx4 is ‘quite good’
at not running int handlers for too long, all interrupts are not deferred
to process priority. some drivers still do a fair bit of processing in their
isr’s. the serial driver is one… it needs to do a fair bit in the isr in
order to keep data rates high.

We are seeing these latencies even without the serial driver running.
However, I’m sure I’ll have to do some reengineering of the serial
driver to reduce the interrupt processing. Maximizing serial throughput
is simply not a big issue on this project.

[…]

Alex1 · March 14, 2001, 4:23pm

Does a 586 (133 MHz 486) have SMM?

Randy Martin wrote:

possibly not as powerful a tool as your scope, but you can see exactly when
the kernel gets your interrupt by using the tools in sysdbg.tgz in the
contributed software section of our site.

one of those tools in there is a mechanism that will allow for a kernel
callout on any defined interrupt… along with a rtdsc timestamp (or
an 8254 timestamp).
this will let you know what the exact kernel latency is before any process
latency comes in to play.

i’d still be concerned though about smm. does ampro tell you anything about
this? our experience on x86 has been that any machine that has this enabled
(laptops are especially bad) will see large latency whenever the smi goes
off (system management interrupt) and then the cpu is held by the smm
firmware until the interrupt is serviced. this is independent of any
operating system in place.

on my laptop, where i can’t disable smm mode, i can see wide latencies of
~ 100-150 microseconds regardless of anything i do with interrupt or
processor priorities.

another note that has been mentioned is that although qnx4 is ‘quite good’
at not running int handlers for too long, all interrupts are not deferred
to process priority. some drivers still do a fair bit of processing in their
isr’s. the serial driver is one… it needs to do a fair bit in the isr in
order to keep data rates high.

Rennie_Allen2 · March 14, 2001, 5:35pm

We are seeing these latencies even without the serial driver running.
However, I’m sure I’ll have to do some reengineering of the serial
driver to reduce the interrupt processing. Maximizing serial
throughput
is simply not a big issue on this project.

If you have simple serial handling requirements, then I would suggest
just doing your own handler. The last project I worked on I did this,
it had some very tight (deterministic) protocol handling had to be done,
and although it would have been doable with Dev.ser, it was just easier
to do with my own uart handler which handled the deterministic parts of
the protocol (very few lines of code) in the handler.

Ian_M_Zagorskih · March 14, 2001, 6:02pm

“Alex” <acellarius@systems104.co.za> wrote in message
news:3AAFB71A.51E8ED57@systems104.co.za…

Does a 586 (133 MHz 486) have SMM?

guess no

Randy Martin wrote:

possibly not as powerful a tool as your scope, but you can see exactly
when
the kernel gets your interrupt by using the tools in sysdbg.tgz in the
contributed software section of our site.

one of those tools in there is a mechanism that will allow for a kernel
callout on any defined interrupt… along with a rtdsc timestamp (or
an 8254 timestamp).
this will let you know what the exact kernel latency is before any
process
latency comes in to play.

i’d still be concerned though about smm. does ampro tell you anything
about
this? our experience on x86 has been that any machine that has this
enabled
(laptops are especially bad) will see large latency whenever the smi
goes
off (system management interrupt) and then the cpu is held by the smm
firmware until the interrupt is serviced. this is independent of any
operating system in place.

on my laptop, where i can’t disable smm mode, i can see wide latencies
of
~ 100-150 microseconds regardless of anything i do with interrupt or
processor priorities.

another note that has been mentioned is that although qnx4 is ‘quite
good’
at not running int handlers for too long, all interrupts are not
deferred
to process priority. some drivers still do a fair bit of processing in
their
isr’s. the serial driver is one… it needs to do a fair bit in the isr
in
order to keep data rates high.

// wbr

Randy_Martin · March 14, 2001, 7:35pm

good point.
i forgot that he was not on a pentium. no, the 486 would not have smm.

Alex <acellarius@systems104.co.za> wrote:

Does a 586 (133 MHz 486) have SMM?

Randy Martin wrote:

possibly not as powerful a tool as your scope, but you can see exactly when
the kernel gets your interrupt by using the tools in sysdbg.tgz in the
contributed software section of our site.

one of those tools in there is a mechanism that will allow for a kernel
callout on any defined interrupt… along with a rtdsc timestamp (or
an 8254 timestamp).
this will let you know what the exact kernel latency is before any process
latency comes in to play.

i’d still be concerned though about smm. does ampro tell you anything about
this? our experience on x86 has been that any machine that has this enabled
(laptops are especially bad) will see large latency whenever the smi goes
off (system management interrupt) and then the cpu is held by the smm
firmware until the interrupt is serviced. this is independent of any
operating system in place.

on my laptop, where i can’t disable smm mode, i can see wide latencies of
~ 100-150 microseconds regardless of anything i do with interrupt or
processor priorities.

another note that has been mentioned is that although qnx4 is ‘quite good’
at not running int handlers for too long, all interrupts are not deferred
to process priority. some drivers still do a fair bit of processing in their
isr’s. the serial driver is one… it needs to do a fair bit in the isr in
order to keep data rates high.

–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

Armin_Steinhoff1 · March 14, 2001, 8:21pm

Randy Martin wrote:

good point.
i forgot that he was not on a pentium. no, the 486 would not have smm.

That’s not true for all 486 CPUs … the 486 from e.g. Cyrix have
SMM.

Armin

Alex <> acellarius@systems104.co.za> > wrote:
Does a 586 (133 MHz 486) have SMM?

Randy Martin wrote:

possibly not as powerful a tool as your scope, but you can see exactly when
the kernel gets your interrupt by using the tools in sysdbg.tgz in the
contributed software section of our site.

one of those tools in there is a mechanism that will allow for a kernel
callout on any defined interrupt… along with a rtdsc timestamp (or
an 8254 timestamp).
this will let you know what the exact kernel latency is before any process
latency comes in to play.

i’d still be concerned though about smm. does ampro tell you anything about
this? our experience on x86 has been that any machine that has this enabled
(laptops are especially bad) will see large latency whenever the smi goes
off (system management interrupt) and then the cpu is held by the smm
firmware until the interrupt is serviced. this is independent of any
operating system in place.

on my laptop, where i can’t disable smm mode, i can see wide latencies of
~ 100-150 microseconds regardless of anything i do with interrupt or
processor priorities.

another note that has been mentioned is that although qnx4 is ‘quite good’
at not running int handlers for too long, all interrupts are not deferred
to process priority. some drivers still do a fair bit of processing in their
isr’s. the serial driver is one… it needs to do a fair bit in the isr in
order to keep data rates high.

–
Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

Armin_Steinhoff1 · March 14, 2001, 8:24pm

Armin Steinhoff wrote:

Randy Martin wrote:

good point.
i forgot that he was not on a pentium. no, the 486 would not have smm.

That’s not true for all 486 CPUs … the 486 from e.g. Cyrix have
SMM.

Let me add an additionl one …

http://eu.st.com/stonline/books/ascii/docs/4197.htm

Armin

Armin

Alex <> acellarius@systems104.co.za> > wrote:
Does a 586 (133 MHz 486) have SMM?

Randy Martin wrote:

possibly not as powerful a tool as your scope, but you can see exactly when
the kernel gets your interrupt by using the tools in sysdbg.tgz in the
contributed software section of our site.

one of those tools in there is a mechanism that will allow for a kernel
callout on any defined interrupt… along with a rtdsc timestamp (or
an 8254 timestamp).
this will let you know what the exact kernel latency is before any process
latency comes in to play.

i’d still be concerned though about smm. does ampro tell you anything about
this? our experience on x86 has been that any machine that has this enabled
(laptops are especially bad) will see large latency whenever the smi goes
off (system management interrupt) and then the cpu is held by the smm
firmware until the interrupt is serviced. this is independent of any
operating system in place.

on my laptop, where i can’t disable smm mode, i can see wide latencies of
~ 100-150 microseconds regardless of anything i do with interrupt or
processor priorities.

another note that has been mentioned is that although qnx4 is ‘quite good’
at not running int handlers for too long, all interrupts are not deferred
to process priority. some drivers still do a fair bit of processing in their
isr’s. the serial driver is one… it needs to do a fair bit in the isr in
order to keep data rates high.

–
Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

Armin_Steinhoff1 · March 14, 2001, 8:40pm

… and at the end: the AMD CPU at Ken’s PC/104 board has SMM

http://www.amd.com/products/epd/processors/6.32bitproc/11.am486fami/12.am486dx/index.html

Armin

Alex1 · March 15, 2001, 4:31am

Good get Armin!
I think the mystery may be resolved…

Armin Steinhoff wrote:

… and at the end: the AMD CPU at Ken’s PC/104 board has SMM >

http://www.amd.com/products/epd/processors/6.32bitproc/11.am486fami/12.am486dx/index.html

Armin