Mail Archives: djgpp/2002/01/30/06:00:17
On Tue, 29 Jan 2002 21:26:03 CST, Charles Sandmann <sandmann AT clio DOT rice DOT edu> 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
- Raw text -