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: Mon, 28 Jan 2002 10:46:11 +0530 Lines: 72 Message-ID: References: <3c52e29b DOT sandmann AT clio DOT rice DOT edu> NNTP-Posting-Host: ppp-200-1-253.bng.vsnl.net.in (203.200.1.253) X-Trace: fu-berlin.de 1012196382 38992961 203.200.1.253 (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 Sat, 26 Jan 2002 11:08:43 CST, Charles Sandmann wrote: >> Could anyone tell me what is the order of delay (in clocks) required for >> the CWSDPMI server to reflect a hardware interrupt from Real mode to the >> protected mode handler ? > >It depends on the chip you're using. A bunch. >Say a few thousand clocks. A couple of thousand clocks 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 - Wonder if my hardware (the chipset) is crummy - but reprogramming the DMA controller (Basically 8 "out dx,al" instructions) was taking close to 12 microsecs to execute !! (Timing using the rdtsc instruction) - whereas I was expecting something like a max of 300 ns per out instruction. >> I need to write a Hardware Interrupt handler where latency is very >> critical. Any suggestion regarding which DPMI server would provide me >> the best latency figures would also be welcome. (The application need >> not be portable - and I can specify the environment). > >PMODE 1.3 is probably the fastest. > >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 ? [snip] >Anything is possible since the source is freely available :-) >In CWSDPMI all the mode switch and selector setup is done in mswitch.asm >so it should be fairly simple to set up one of the selectors to do the >"unreal" flat mode 32-bit real mode hack. You would need to know about >the physical to virtual translations with page tables under CWSDPMI. Thanks, I'll check this out. Physical to Virtual mapping shouldn't be a problem since I need to anyway have the physical addresses of the extended memory buffers for setting it up as a DMA buffer. So once I can get into Flat mode, I hope I wouldn't have problems accessing it using the physical address. >PMODE would not need to worry about page table remapping issues, but I >don't offhand know where to set up the unreal segments there. Looking at the sources, PMODE seemed to be simpler to modify since it uses only the GDT. There seems to be a selector named SELREAL, and I think I'll first try patching its values to limit = 0xFFFFF and Granularity = 1. >In any case, if you get it working you can always contribute it. Will certainly do so. Thanks for all the pointers. Regards, BK