X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: DPMI Interrupt latency ? Date: Tue, 29 Jan 2002 21:26:03 CST Organization: Rice University, Houston TX Lines: 59 Message-ID: <3c5767cb.sandmann@clio.rice.edu> References: <3c559481 DOT sandmann AT clio DOT rice DOT edu> NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1012361949 25557 128.42.105.3 (30 Jan 2002 03:39:09 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: 30 Jan 2002 03:39:09 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 > 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. Right, it reprograms the pic. Sorry, forgott to warn you about that. > 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. > 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 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... > 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. > 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. > Thanks for all the help. Certainly. Thanks for the test results.