Technical Note
Measuring the Interrupt Latency of ZTP/RZK
TN004901-0206
Introduction
One of the important characteristics of a real-time operating system is the interrupt latency, which is the time taken for a system to launch an interrupt service routine, or in a multitasking system, to schedule an interrupt handler task. Measuring interrupt latency can provide valuable insight into the way a system will perform when running real-time applications. Interrupt latency indicates the performance capabilities and the effectiveness of a real time operating system that deals with extremely high-priority interrupts. This technical note discusses the method for measuring the best and the worst case interrupt latency of ZTP1.6 on RZK1.2.1.
Interrupt Latency
Interrupt latency is defined as the time elapsed between an interrupt and the execution of the first instruction in the corresponding interrupt service routine. In other words, it refers to the amount of time or delay between when an interrupt is triggered and when the interrupt is served by the CPU and software. Generally this delay depends on the machine state at the moment the interrupt was acknowledged by the CPU. Some of the factors that affects the interrupt latency are listed below: • Context switch time • Time caused by blocking • Time caused by preemption • Data dependency • Criticality of tasks Interrupt latency do not have a fixed length. By definition, interrupt latency is an asynchronous event and depends on the state of the machine. This state of machine is a function of both the hardware and the software used in the system. An embedded system application may have different types of interrupts as a result of using many hardware devices or the processors on-chip resources. Some interrupt have higher priority and require a faster response time than others.
ZiLOG Worldwide Headquarters • 532 Race Street • San Jose, CA 95126 Telephone: 408.558.8500 • Fax: 408.558.8300 • www.ZiLOG.com Measuring the Interrupt Latency of ZTP/RZK Technical Note
All the maskable interrupts are disabled when internal kernel data structure is being manipulated. The system’s interrupt latency is directly related to the length of the longest critical section in the kernel.
The Figure 1 shows a pictorial representation of the interrupt latency.
t1 t2 Time
A B
Interrupt Service Interrupt Task Routine Latency Thread Latency #1: Figure 1. Representation of Interrupt Latency
In Figure 1, t1- represents the time at which the hardware asserts the IRQ input (that is an interrupt is triggered). t2- represents the time at which the interrupt thread starts its execution.
Measuring the Interrupt Latency
This section discusses the method for measuring the interrupt latency using Timer 2 interrupt. Timer 2 registers are initialized to generate interrupt at every 50 ms. The code snippet listed in the appendix causes an interrupt to be generated when Timer 2 register overflows. In the Timer 2 interrupt service routine, the current value of the hardware timer count is stored in a global variable tmr2_data.The interrupt generation is disabled and the interrupt task is scheduled for execution. The interrupt task then compares the last count value obtained in the interrupt service routine with the lowest value obtained. If the current value is less, it becomes the new lowest value and the interrupt task displays the new count. Once the complete comparison is done, timer interrupt generation is re-enabled. The timer is set to a reload value of 0 and a div16 prescaler is used. The timer will cycle from 0 to 65536 values with the following time-out period: 16*65536 / 50000000 = 20.97152 ms
TN004901-0206 2 Measuring the Interrupt Latency of ZTP/RZK Technical Note
Therefore, almost 50 Timer 2 interrupts are generated for each second and each timer tick corresponds to 320 ns. While running the stack, the lowest value that is displayed will be 0xFF61, corresponding to an interrupt latency: = (0 - 0xFF61) ticks * 320 ns per tick = 159 * 0.32 µs = just over 50 µs
Measuring the Best Case Latency
Download the complete ZTP demo to the eZ80F91 development kit. The code resides in RAM area and the best case interrupt latency number provided in this technical note is for the codes executing in the RAM area. While measuring the best case latency no threads other than Timer 2 and the system timer thread are in execution (System timer generates base timings for RZK).
Best case interrupt latency value The best case interrupt latency: 2 to 3 µs
Measuring the Worst Case Latency
Worst case interrupt latency is measured by loading the ZTP stack with maximum traffic. As maximum traffic is very specific to the application that is being used, the term worst case interrupt latency becomes a relative term. In this technical note, a particular example is considered for measuring the worst case interrupt latency. Here the system is loaded by gradually increasing the network traffic using the following methods: • Pinging • Continuously downloading the web page hosted on eZ80® through hypertext transfer protocol (HTTP) • Connecting through point to point protocol (PPP)
Pinging Ping is a network tool used on TCP/IP networks (such as the Internet) to verify the IP-level connectivity. It verifies whether a particular target host is operating properly and is reachable on the network from the testing host. Ping provides estimates of the round-trip time and packet loss rate between the hosts. Ping works by sending Internet control message protocol (ICMP) echo request packets to the target host and waits for the ICMP echo response packets to be received.
TN004901-0206 3 Measuring the Interrupt Latency of ZTP/RZK Technical Note
All the machines supporting TCP/IP should be able to ping the ez80F91 web server (i.e., eZ80F91 development kit on which the ZTP stack has been loaded). Ping (send ICMP echo request packets) to the ez80F91 web server with an appropriate IP address and the ez80F91 web server responds to the pinging machine by sending the ICMP echo response packet. The network is kept busy by Pinging method as given below. On a host computer, run two instances of ping test over ethernet with the following settings: • Size of each ping packet:1400 bytes • Ping interval:10 ms • Time-out: 1000 ms On the same host computer, run one instance of ping test over ethernet with the following settings: • Size of each ping packet: 4000 bytes • Ping interval: 200 ms • Timeout:1000 ms Once the PPP connection is established between host computer and eZ80F91, from the host computer run three instance of DOS Ping (use the PPP interface IP address). Each ping should be 1400 bytes repeating at one second interval.
Invoking the PPP and continuous download of web page through HTTP Establish a PPP connection to a host computer using direct cable connection (DCC) and HyperTerminal setting at 57600 baud rate, no parity, 8 bit data and 1 stop bit and no flow control. DCC is used to eliminate slow down arising because of the modem. On a host computer, run one instance of the EtherPeek (ethernet network analyser software) HTTP throughput test (continuous refresh of HTTP web page) over ethernet. On the same host computer to which the PPP connection was established, run one instance of the EtherPeek HTTP throughput test over PPP. Make sure to execute the program for about 15 to 20 minutes, which is close to the breaking point of traffic that the stack can handle. You can see few no buffer avail messages indicating some dropped packets. Similarly, as no flow control is used over PPP, few serial overrun errors will appear. The key point over here is to not overload the stack, just bring it close to the breaking point. While the Ethernet and PPP traffic is running, note down the latency reported by the Timer 2 program.
TN004901-0206 4 Measuring the Interrupt Latency of ZTP/RZK Technical Note
Worst case interrupt latency value The worst case interrupt latency obtained using the above mentioned tests is 18us but this value may differ depending on the conditions like (different protocols being used, different thread priorities, number of applications being run on eZ80®). You can refer to appendix for the code snippets used to measure the interrupt latency.
Summary
It is always not possible to guarantee the best case or maximum interrupt latency for the ZTP/RZK, but it is possible to draw some general conclusions for a typical system. Measurement of interrupt latency amounts to making a measurement of an extreme condition. It is not a measure of the average performance of a CPU. i.e., it does not reflect the ability of a CPU to compute. Increasing the CPU’s clock speed increases the average performance level of a system but does not significantly affect the speed at which a CPU will respond to an asynchronous event, such as an interrupt.
TN004901-0206 5 Measuring the Interrupt Latency of ZTP/RZK Technical Note
Appendix - Code Snippets
The code snippets used for measuring the interrupt latency are listed below. /********************************************************************* * *Description: The code snippets used for measuring the interrupt *latency are listed below * *Copyright 2006 ZiLOG Inc. ALL RIGHTS RESERVED. * *This file contains unpublished confidential and proprietary *information of ZiLOG, Inc. *NO PART OF THIS WORK MAY BE DUPLICATED, STORED, PUBLISHED OR DISCLOSED *IN ANY FORM WITHOUT THE PRIOR WRITTEN CONSENT OF ZiLOG, INC. *This is not a license and no use of any kind of this work is *authorized in the absence of a written license granted by ZiLOG, Inc. *in ZiLOG's sole discretion *********************************************************************/
/**************Interrupt Latency task ****************************/ #include
///////////////////// Setup //////////////////////////////////// /* * Global Vars */
RZK_THREADHANDLE_t Tmr2IntTaskPID; // Interrupt Task PID for Port B Pin 0 UINT16 tmr2_data; UINT16 tmr2_max_data = 0xFFFF; UINT8 Tmr2Stack[1024];
/*
TN004901-0206 6 Measuring the Interrupt Latency of ZTP/RZK Technical Note
* Set up timer2 interrupt */ void Tmr2Init(void) { RZKInstallInterruptHandler(tmr2_isr, 0x5C); // Install the assembly ISR
TMR2_RR_L = 0x00; // Each tick is 320ns TMR2_RR_H = 0x00; TMR2_CTL = 0x8F; // Give Priority to Timer 2 INT_P1 = 0x01; TMR2_IER = 1; // TIER_IRQ_EOC_EN; Tmr2IntTaskPID = RZKCreateThread ( (UINT8 *) "T2 Int Task", Tmr2IntTask, NULL, &Tmr2Stack[1024], 8, 0, RZK_THREAD_PREEMPTION | RZK_THREAD_INTERRUPT, 0 ); }
////////////////////////"C" Interrupt Task //////////////////////////// void Tmr2IntTask ( void ) { UINT8 Data; while(1) { if(tmr2_data < tmr2_max_data) { tmr2_max_data = tmr2_data; printf("Latency is %x\n”, tmr2_max_data); } asm("di\n”); TMR2_IER = 1; // TIER_IRQ_EOC_EN; Data = TMR2_IIR; RZKSuspendInterruptThread();
TN004901-0206 7 Measuring the Interrupt Latency of ZTP/RZK Technical Note
asm("ei\n”); } } /*********************End****************************/
;********************************************************************* ; ;Description: Timer 2 ISR routine ; ;Copyright 2006 ZiLOG Inc. ALL RIGHTS RESERVED. ; ;This file contains unpublished confidential and proprietary ;information of ZiLOG, Inc. ;NO PART OF THIS WORK MAY BE DUPLICATED, STORED, PUBLISHED OR DISCLOSED ;IN ANY FORM WITHOUT THE PRIOR WRITTEN CONSENT OF ZiLOG, INC. ;This is not a license and no use of any kind of this work is authorized ;in the absence of a written license granted by ZiLOG, Inc. in ZiLOG's ;sole discretion ; **********************************************************************
/*******Timer2 ISR************************************/ .extern _RZKSystemTimerISR .extern _RZKISRProlog .extern _RZKISREpilog .extern _hSysIsrThread .extern _hCurrentThread .extern _RZKResumeInterruptThread .extern _Tmr2IntTaskPID .extern _tmr2_data .extern _g_hTimer1Thread .include "ez80F91.inc" .assume adl=1 .def _tmr2_isr
;////////////////////////// HW ISR //////////////////////////////////// _tmr2_isr: push af push bc push de push hl push ix push iy
;*** Store the Current Count ***
TN004901-0206 8 Measuring the Interrupt Latency of ZTP/RZK Technical Note
ld hl, _tmr2_data in0 a, (TMR2_DR_L) ld (hl), a inc hl in0 a, (TMR2_DR_H) ld (hl), a
;*** Disable the interrupt by reading Tmr2 IIR in0 a, (TMR2_IIR) ld a, 0
;*** No more interrupts out0 (TMR2_IER), a call _RZKISRProlog
;*** Activate the Interrupt task for non-time critical event processing ld hl, (_Tmr2IntTaskPID) push hl call _RZKResumeInterruptThread pop hl call _RZKISREpilog pop iy pop ix pop hl pop de pop bc pop af ei reti
TN004901-0206 9 Measuring the Interrupt Latency of ZTP/RZK Technical Note
This publication is subject to replacement by a later edition. To determine whether a later edition exists, or to request copies of publications, contact:
ZiLOG Worldwide Headquarters 532 Race Street San Jose, CA 95126 Telephone: 408.558.8500 Fax: 408.558.8300 www.zilog.com
ZiLOG is a registered trademark of ZiLOG Inc. in the United States and in other countries. All other products and/or service names mentioned herein may be trademarks of the companies with which they are associated.
Information Integrity The information contained within this document has been verified according to the general principles of electrical and mechanical engineering. Any applicable source code illustrated in the document was either written by an authorized ZiLOG employee or licensed consultant. Permission to use these codes in any form, besides the intended application, must be approved through a license agreement between both parties. ZiLOG will not be responsible for any code(s) used beyond the intended application. Contact the local ZiLOG Sales Office to obtain necessary license agreements.
Document Disclaimer ©2006 by ZiLOG, Inc. All rights reserved. Information in this publication concerning the devices, applications, or technology described is intended to suggest possible uses and may be superseded. ZiLOG, INC. DOES NOT ASSUME LIABILITY FOR OR PROVIDE A REPRESENTATION OF ACCURACY OF THE INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED IN THIS DOCUMENT. ZiLOG ALSO DOES NOT ASSUME LIABILITY FOR INTELLECTUAL PROPERTY INFRINGEMENT RELATED IN ANY MANNER TO USE OF INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED HEREIN OR OTHERWISE. Except with the express written approval ZiLOG, use of information, devices, or technology as critical components of life support systems is not authorized. No licenses or other rights are conveyed, implicitly or otherwise, by this document under any intellectual property rights.
TN004901-0206 10