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: References: <3c52e29b DOT sandmann AT clio DOT rice DOT edu> <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 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