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: Wed, 30 Jan 2002 16:13:56 +0530 Lines: 70 Message-ID: References: <3c559481 DOT sandmann AT clio DOT rice DOT edu> <3c5767cb DOT sandmann AT clio DOT rice DOT edu> NNTP-Posting-Host: ppp-181-107.bng.vsnl.net.in (203.197.181.107) X-Trace: fu-berlin.de 1012387478 40708309 203.197.181.107 (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 Tue, 29 Jan 2002 21:26:03 CST, Charles Sandmann wrote: >> 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 ? > >It shouldn't. You can look at the sources. You're right - It was a goof on my part. I was trying to call the wrong interrupt. >> With CWSDPMI : Maximum 6500 clocks, minimum 3200, Average 3500 clocks >> >> With PMODE/DJ : Maximum 3100 clocks, minimum 1200, Average 1250 clocks > >Very interesting. I'm surprised there is that much variability (nested >interrupts?) The averages are pretty close to what I had tested or >had reported to me in the past (around 2-4K for CWSD, 1-2K for PMDJ), >I had expected a little over 2X speed difference. The Min/average >show the maximums are fairly rare - in pmodes case about 2/100 or less? > >> I assume the reason for the maximum numbers being much larger than the >> average could be because of instruction cache misses ?? > >A few cache misses wouldn't add up that badly. It's something more >terrible... I added another couple of tests with simulation through Software Interrupts. The only difference I noticed is that the values of Minimum and Average latencies are less by about 300 to 400 clocks if you invoke it through a software interrupt instead of a genuine hardware interrupt. And you're right in saying that the maximum values being seen cannot be due to Cache misses alone. I checked out once again and found that the maximum points are not always among the first few samples (which should be the case for cache miss situation). It also cannot be because of another hardware interrupt occurring because the code masks OFF all other interrupt sources during the hardware IRQ test. Could probably be some subtle bug in my test program, because the maximums look suspiciously close to twice the average value. Maybe you can spot it when you look at the code. >> Hope this information is useful to someone. >Very much so. Hard facts make good references. I don't suppose you >could re-run the test for CWSDPR0? :-) For completeness/documentation. Tried it with CWSDPR0. Doesn't seem to be very different from the CWSDPMI numbers. >> 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. > >Plese send, I'd like for my test suite. Since I am not sure about the policy of binary uploads on this group, I'll mail it to you directly. A copy of the test program with sources is also available at http://www.sankya.com/djgpp/latency.zip Regards, BK