I am looking for interrupt latency numbers for PowerPC architectures, if possible for e500v2.Looking at below postings, there is a mentioning of "TBD" microseconds as maximum period ... and a variable "na" to describe the value of MHz.Can you please share your experience ? https://docs.rtems.org/releases/4.0.0/doc/support/c_powerpc/a00070.html: The maximum period with traps disabled or the processor interrupt level set to it's highest value inside RTEMS is less than TBD microseconds including the instructions which disable and re-enable interrupts. The time required for the PowerPC to vector an interrupt and for the RTEMS entry overhead before invoking the user's trap handler are a total of 61 microseconds. These combine to yield a worst case interrupt latency of less than TBD + 61 microseconds at na Mhz. [NOTE: The maximum period with interrupts disabled was last determined for Release 4.0.0-lmco.] The maximum period with interrupts disabled within RTEMS is hand-timed with some assistance from PSIM. The maximum period with interrupts disabled with RTEMS occurs was not measured on this target. The interrupt vector and entry overhead time was generated on the PSIM benchmark platform using the PowerPC's decrementer register. This register was programmed to generate an interrupt after one countdown. https://docs.rtems.org/releases/rtemsdocs-4.6.6/share/rtems/html/supplements/powerpc/powerpc00059.html: Interrupt latency is the delay between the CPU's receipt of an interrupt request and the execution of the first application-specific instruction in an interrupt service routine. Interrupts are a critical component of most real-time applications and it is critical that they be acted upon as quickly as possible. Knowledge of the worst case interrupt latency of an executive aids the application designer in determining the maximum period of time between the generation of an interrupt and an interrupt handler responding to that interrupt. The interrupt latency of an system is the greater of the executive's and the applications's interrupt latency. If the application disables interrupts longer than the executive, then the application's interrupt latency is the system's worst case interrupt disable period. The worst case interrupt latency for a real-time executive is based upon the following components: the longest period of time interrupts are disabled by the executive,the overhead required by the executive at the beginning of each ISR,the time required for the CPU to vector the interrupt, andfor some microprocessors, the length of the longest instruction.The first component is irrelevant if an interrupt occurs when interrupts are enabled, although it must be included in a worst case analysis. The third and fourth components are particular to a CPU implementation and are not dependent on the executive. The fourth component is ignored by this document because most applications use only a subset of a microprocessor's instruction set. Because of this the longest instruction actually executed is application dependent. The worst case interrupt latency of an executive is typically defined as the sum of components (1) and (2). The second component includes the time necessry for RTEMS to save registers and vector to the user-defined handler. RTEMS includes the third component, the time required for the CPU to vector the interrupt, because it is a required part of any interrupt. Many executives report the maximum interrupt disable period as their interrupt latency and ignore the other components. This results in very low worst-case interrupt latency times which are not indicative of actual application performance. The definition used by RTEMS results in a higher interrupt latency being reported, but accurately reflects the longest delay between the CPU's receipt of an interrupt request and the execution of the first application-specific instruction in an interrupt service routine. The actual interrupt latency times are reported in the Timing Data chapter of this supplement
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
