Hello!
I’m creating a piece of s/w which has to react quickly in response to
some external messages from another CPU. My arch is XScale PXA255 @ 200
MHz, Neutrino 6.3. I have attached a pulse interrupt handler (via
AttachInterruptEvent) for a GPIO interrupt, then a thread does a
MsgReveive, reads the message MsgReplies to another thread which waited
for the message.
I measured the times and they don’t look nice. First delay is between
the interrupt occurs and the thread receives a pulse. It takes 50us.
Another huge delay is between calling MsgReply and actually receiving
the reply – another almost 50us. I tried a low level interrupt handler
(InterruptAttach) and the latency was 21us. However it was only for
testing, since I can’t do much in this handler, and it’s still very
long. So I’m stuck with total 100us delay, which is ages for me. Why are
the times so long? 100us is almost 20k CPU instructions, what’s
happening there? And the most important – how can make it closer to 10us?
The whole thing goes like this:
- IRQ signal asserted
… 21 us
- low level handler which only returns a pulse to thread
… 37 us
- my handler starts reading a message
… 7.3 us
- handler finishes, MsgReply calls
… 42.5 us
- a thread receives a reply
regards
–
Wojciech Piechowski http://www.mandra.pl/
RADMOR S.A. ul. Hutnicza 3, 81-212 Gdynia, Poland
+48 58 6996735 Wojciech.Piechowski@radmor.com.pl
“Wojciech Piechowski” <wojciech.piechowski@radmor.com.pl> wrote in message
news:ee31tl$qk6$1@inn.qnx.com…
Hello!
I’m creating a piece of s/w which has to react quickly in response to some
external messages from another CPU. My arch is XScale PXA255 @ 200 MHz,
Neutrino 6.3. I have attached a pulse interrupt handler (via
AttachInterruptEvent) for a GPIO interrupt, then a thread does a
MsgReveive, reads the message MsgReplies to another thread which waited
for the message.
I measured the times and they don’t look nice. First delay is between the
interrupt occurs and the thread receives a pulse. It takes 50us. Another
huge delay is between calling MsgReply and actually receiving the reply -
another almost 50us. I tried a low level interrupt handler
(InterruptAttach) and the latency was 21us. However it was only for
testing, since I can’t do much in this handler, and it’s still very long.
So I’m stuck with total 100us delay, which is ages for me. Why are the
times so long? 100us is almost 20k CPU instructions, what’s happening
there?
Not if you take 100ns to fetch an instruction. Which is a distinct
possibility if you miss the cache. Which is a distinct possibility if they
have to clean/flush it on context switches (that may or may not be the
case). Flush/clean by itself may be expensive too, regardless of the future
penalty on instruction fetches.
On top of that you have interrupt latency. And then your pulse goes through
system-wide queue and you get hit by scheduling latency. And then you get by
it again to retrieve the message.
And the most important - how can make it closer to 10us?
Have a thread wait for interrupt explicitly, that will get you better
performance. But I doubt you’ll get anywhere close to 10us on this hardware
if you need to do the handling in a thread. There’s a price to pay for using
a high level OS with full memory protection and message passing.
– igor
There is OS that would handle it. AceOS
Saludos,
Wojtek