Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?: (11 Items)
   
io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
From a .kev file from a customer's target (via tracelogger):

io-pkt-v4-hc handles interrupt 0x1C (EPIT-1 on imx35 platform, "Enhanced
periodic interrupt timer"), which occurs regularly every 1 ms.
What kind of processing is going on by io-pkt-v4-hc? Is it necessary?  If not, how can we decrease the frequency of io-
pkt's interrupt handler being executed?
This does not cause io-pkt to run, however, but it takes time to enter and exit this handler. The only other process 
that handles this interrupt is procnto-v6-instr

Thanks
Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
On Thu, Feb 11, 2010 at 02:58:18AM -0500, Andrew Sherk wrote:
> From a .kev file from a customer's target (via tracelogger):
> 
> io-pkt-v4-hc handles interrupt 0x1C (EPIT-1 on imx35 platform, "Enhanced
> periodic interrupt timer"), which occurs regularly every 1 ms.
> What kind of processing is going on by io-pkt-v4-hc? Is it necessary?  If not, how can we decrease the frequency of io
-pkt's interrupt handler being executed?
> This does not cause io-pkt to run, however, but it takes time to enter and exit this handler. The only other process 
that handles this interrupt is procnto-v6-instr
> 

It's attaching to the timer interrupt to handle all
its timers.  It's necessary as currently architected.

Regards,

-seanb
RE: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
> attaching to the timer interrupt to handle all
> its timers.  It's necessary

Is a one millisecond timer really necessary for
protocol timeouts and drivers?  On powerful x86
boxes you can probably get away with it, but esp
on low-power embedded CPU's, 10ms might be a better
choice. 

--
aboyd
Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
On 11/02/10 09:17 AM, Andrew Boyd wrote:
>    
>> attaching to the timer interrupt to handle all
>> its timers.  It's necessary
>>      
> Is a one millisecond timer really necessary for
> protocol timeouts and drivers?  On powerful x86
> boxes you can probably get away with it, but esp
> on low-power embedded CPU's, 10ms might be a better
> choice.
>
> --
> aboyd
>    
I suspect the underlying requirement is on timer resolution for TCP's 
fast timeout, but I'd have to do some investigation to verify...
/P
Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
On Thu, Feb 11, 2010 at 09:17:34AM -0500, Andrew Boyd wrote:
> 
> > attaching to the timer interrupt to handle all
> > its timers.  It's necessary
> 
> Is a one millisecond timer really necessary for
> protocol timeouts and drivers?  On powerful x86
> boxes you can probably get away with it, but esp
> on low-power embedded CPU's, 10ms might be a better
> choice. 

It attaches to the timer interrupt, whose default
frequency is 1ms, but it doesn't raise an actual
event at that frequency.

-seanb
RE: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
 
Please correct my misunderstanding but it would seem from tracelogs that
io-pkt ISR is entered every millisecond. Does that not count as an
"event"? But I suppose you would need to use a secondary timer with that
fires an interrupt at say 10 ms if you wanted io-pkt's ISR to be entered
1/10th of the current frequency.

Thanks all for your quick replies--most appreciated.
 -asherk
 
-----Original Message-----
From: Sean Boudreau [mailto:community-noreply@qnx.com] 
Sent: Thursday, February 11, 2010 11:33 PM
To: technology-networking
Subject: Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this
frequency required?

On Thu, Feb 11, 2010 at 09:17:34AM -0500, Andrew Boyd wrote:
> 
> > attaching to the timer interrupt to handle all
> > its timers.  It's necessary
> 
> Is a one millisecond timer really necessary for
> protocol timeouts and drivers?  On powerful x86
> boxes you can probably get away with it, but esp
> on low-power embedded CPU's, 10ms might be a better
> choice. 

It attaches to the timer interrupt, whose default
frequency is 1ms, but it doesn't raise an actual
event at that frequency.

-seanb



_______________________________________________

Technology
http://community.qnx.com/sf/go/post47134
Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
On Thu, Feb 11, 2010 at 09:57:09AM -0500, Andrew Sherk wrote:
> 
>  
> Please correct my misunderstanding but it would seem from tracelogs that
> io-pkt ISR is entered every millisecond. Does that not count as an
> "event"? But I suppose you would need to use a secondary timer with that
> fires an interrupt at say 10 ms if you wanted io-pkt's ISR to be entered
> 1/10th of the current frequency.
> 

It's a kernel event but a sigevent isn't returned
from the isr at that frequency: userland code isn't
scheduled at 1ms.

Regards,

-seanb
Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
Do we have any specific reason of not using a user configurable software timer? This does cause quite bit overhead for 
low end system.
RE: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
Customer understands that this 1 ms second processing (enter and exit
io-pkt ISR) is necessary and that it would be difficult to prevent it
due to the architecture.

The target is armle, cpu clock is 400 mhz 

Please let me know if I can convey any other information.

~asherk
Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
On Thu, Feb 11, 2010 at 10:10:56PM -0500, Lichun Zhu wrote:
> Do we have any specific reason of not using a user configurable software timer? This does cause quite bit overhead for
 low end system.

PR 10963 was the original reason.

-seanb
Re: io-pkt handles interrupt 0x1C EPIT-1 every 1 ms - is this frequency required?  
Thanks, Sean.
This PR is already fixed. It would be nice to have a configurable way to deal with this. The real ISR does cause at 
least a context switch, for a low end, especially a ARM platform, we can see quite a bit of overhead. Do we have any 
plan on this in the near future?