X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-bounces using -f
From:	kala AT sankya DOT com (Babu Kalakrishnan)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: DPMI Interrupt latency ?
Date:	Tue, 29 Jan 2002 18:40:45 +0530
Lines:	50
Message-ID:	<slrna5d7ql.478.kala@ganga.sankya.com>
References:	<slrna5524i DOT 43o DOT kala AT ganga DOT sankya DOT com> <3c52e29b DOT sandmann AT clio DOT rice DOT edu> <slrna59nkq DOT a50 DOT kala AT ganga DOT sankya DOT com> <3c559481 DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host:	ppp-177-94.bng.vsnl.net.in (203.197.177.94)
X-Trace:	fu-berlin.de 1012309860 38847086 203.197.177.94 (16 [76750])
X-Orig-Path:	kala
User-Agent:	slrn/0.9.6.2 (Linux)
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

On Mon, 28 Jan 2002 12:12:17 CST, Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote:

[Regarding testing interrupt latency]

>Chaining can cause extra code to be run  - the easiest thing to do would be to
>install a PM interrupt handler for an unused hardware interrupt, spawn to
>dos (DJGPP image still in memory, still hooked) and write a small real mode
>image to see how long it takes to do the software interrupt.  You can then
>exit back to the DJGPP image and make sure you counted them all...

Tried the way you suggested - but it doesn't seem to work if I try
invoking the hardware interrupt through a software (INT XX) call. I
hooked INT0D (IRQ5) from protected mode. But on reaching the shell, The
interrupt vector of Int 0d was pointing to the initial Real mode value
in ROM. I then tried calling Int8D (where the master PIC vector seemed
to be redirected to), but still my interrupt handler didn't seem to get
called. Does the code check if the interrupt is a genuine hardware IRQ
and skip calling the handler if it isn't ?

Anyways, managed to do the tests by hooking IRQ8 (timer interrupt) and
writing a small Real mode routine which hangs on in Real mode till a
fixed number of Timer ticks ahve passed. On return from the Real mode
call, the delays were averaged. The results were as follows (for 100
samples, values are rounded to 50 clocks - CPU is P3 - 933 MHz)

With CWSDPMI  : Maximum 6500 clocks, minimum 3200, Average 3500 clocks

With PMODE/DJ : Maximum 3100 clocks, minimum 1200, Average 1250 clocks

If the same test is done using a Real mode handler, both PMODE and
CWSDPMI gave more or less the same numbers of min=410, max= 480 and
average = 440 clocks.

I assume the reason for the maximum numbers being much larger than the
average could be because of instruction cache misses ??

Hope this information is useful to someone.

The PMODE/DJ numbers seem to be more or less acceptable for my
application, and so not investigating the "Unreal" mode approach
immediately. May be later when I have some spare time.. 

If anyone is interested in the source code of the test program used to
do the above tests, pl. let  me know, I'll be glad to post it.

Thanks for all the help.

Regards,

BK

- Raw text -