X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DPMI Interrupt latency ?
Date: Mon, 28 Jan 2002 12:12:17 CST
Organization: Rice University, Houston TX
Lines: 34
Message-ID: <3c559481.sandmann@clio.rice.edu>
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>
NNTP-Posting-Host: clio.rice.edu
X-Trace: joe.rice.edu 1012244467 8385 128.42.105.3 (28 Jan 2002 19:01:07 GMT)
X-Complaints-To: abuse AT rice DOT edu
NNTP-Posting-Date: 28 Jan 2002 19:01:07 GMT
X-NewsEditor: ED-1.5.9
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> A couple of thousand clocks [for the mode switch] wouldn't bother me much 
> (I'm using a 1GHz P3) - My observation has been that even executing a few 
> I/O instructions take more time than that 

in's and out's can eat you alive when it comes to latency.  I've broken
decent latency response several times in CWSDPMI because of this (making
sure A20 is enabled, for example).  In general I try to get the hardware
setup the way I want it and leave it that way.  I don't know if you're
lucky enough to be able to do that.  If you find any unneeded slowdown
calls in either cwsdpmi or pmode let me know.

> >The best thing to do is some tests.  If you document it (or provide the
> >test programs) I'll add it to a summary somplace.

> I wanted to do this, but wasn't very sure how I'd go about it. Would the
> following sequence be a sufficient indicator ?

> a) Install a protected mode interrupt handler - read the TimeStampCounter
>    right at the beginning.

> b) Install a Real Mode interrupt handler, read the TSC on entry and
>    chain to the old real mode handler (This I suppose should reflect the 
>    interrupt to the PM handler ?)

> c) The time difference of (a) - (b) should give me the mode switch
>    overhead if the interrupt occurs in real mode ?   

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...