Welcome!

Open Source Cloud Authors: Yeshim Deniz, Liz McMillan, Pat Romanski, Elizabeth White, Zakia Bouachraoui

Related Topics: Open Source Cloud

Open Source Cloud: Article

Using Interrupts For Timing

Using Interrupts For Timing

This is an excerpt from Chapter 11 of Embedded Linux by Craig Hollabaugh, published by Addison-Wesley. ISBN 0672322269. No part of this excerpt may be reproduced, in any form or by any means without the prior written permission of the publisher. (c) 2002 Addison-Wesley.

The first snowfall at Silverjack filled the air with excitement. Soon the village would bustle and the slopes would open. As in past years, many skiers and snowboarders would race against the clock on the mountain's racecourse. This year, however, Project Trailblazer wants to collect, display, log, and post race results. Using embedded Linux for Silverjack race timing will reduce data entry errors, increase efficiency, and enhance the racers' experience.

This article series explores using Linux as an event timer with 1-millisecond resolution. The Project Trailblazer engineers need to develop interrupt handlers for the target boards-the MZ104, the MediaEngine, and the RPX-CLLF. Then they need to use these handlers to measure average interrupt latencies. The engineers need to design a race timer that uses a split interrupt approach with "top half" and "bottom half" handler routines, tasklets, and a self-rescheduling kernel timer.

Linux Timing Sources
Linux provides several mechanisms for event timing, ranging from 1-second down to submicrosecond resolution. This section discusses the following timing sources:

  • date-The resolution of date is 1s. Using the +%s formatter, date returns the number of seconds that have elapsed since 00:00:00, January 1, 1970.
  • jiffies-The resolution of jiffies is 10ms. On all platforms, Linux configures a hardware timer that interrupts the processor periodically-typically every 10ms (this value is defined in the kernel source as HZ). The timer interrupt routine increments the kernel variable jiffies by 1. Therefore, the value of jiffies represents the number of 10ms increments that have occurred since booting. It is possible to increase jiffies resolution by altering the HZ source declaration. However, this could ultimately lower overall system performance due to increased interrupt processing. Other mechanisms offer higher resolution.
  • PSR-The resolution of PSR (which stands for processor-specific registers) is various. Some newer processors contain two 32-bit counters that increment on every system clock cycle. The counters accessed through PSR provide resolutions that are dependent on processor clock speed. Kernel source code provides function calls to access the PSR. For example, the rdtsc function returns the timestamp counter (TSC) on Pentium and newer processors, and the get_tbl function returns the mftb register value on PowerPCs. 486 and ARM processors do not contain system clock counters.
  • get_cycles-The resolution of get_cycles is various. The get_cycles function, which is defined all on platforms, returns a count of system clock cycles that fit into a single CPU register. Typically this is the lower half of the two 32-bit counters mentioned previously. If the processor doesn't contain a clock counter, get_cycles returns 0. get_cycles returns 0 on 486 and ARM processors.
  • do_gettimeofday-The resolution of do_gettimeofday is about 1ms. The do_gettimeofday function fills a timeval data structure with the number of seconds and microseconds elapsed since booting. The x86 and PowerPC kernel source claim near-microsecond resolution for do_gettimeofday.

    The Project Trailblazer race timer needs to have 1ms resolution. This resolution eliminates using date and jiffies. The MZ104's 486 and the MediaEngine's ARM processors don't contain system clock counters, so the Project Trailblazer engineers also can't use PSR. The get_cycles function returns only a 32-bit counter value. On the slowest clocked target board, the RPX-CLLF (at 70MHz), the get_cycles function can only count 61 seconds' worth of microseconds. A typical race will be longer than 61 seconds, so the get_cycles function won't work for Project Trailblazer. This leaves the do_gettimeofday function. With near-microsecond resolution and a 32-bit counter of seconds (232 seconds = 49,710 days), the do_gettimeofday will provide accuracy for even the longest race. The race timer's interrupt routine can timestamp the race's start and finish by using do_gettimeofday. A scheduled task can later compute the race's overall time.

    Interrupt latency is a measure of the time between an event occurring (for example, the race start) and when the processor executes the interrupt handler code. Even with microsecond timing access, race timing won't have millisecond accuracy if the system interrupt latency exceeds a millisecond. The next section examines the Project Trailblazer engineers' development of interrupt handlers within a device driver to measure average interrupt latencies for the MZ104, MediaEngine, and RPX-CLLF target boards.

    Measuring Interrupt Latency
    Interrupt latency is comprised of hardware propagation time, register saving, and software execution. Propagation time and register saving occur extremely fast-on the order of 10s of nanoseconds. Software execution, on the other hand, can be extremely slow. The Linux kernel allows device drivers to disable interrupts by using the cli system call. While interrupts are disabled, other interrupts can occur, but their service routines are not executed until interrupts are re-enabled. Developers disable interrupts to protect critical sections of their code. For example, a video card driver might disable interrupts for 16ms while waiting for video sync. Or a serial card driver might disable interrupts during a byte transmission. Therefore, maximum interrupt latency is a combination of system hardware, peripherals, and the quality of the device driver software. Even with source code availability, this combination and the asynchronous nature of interrupts makes calculating the maximum interrupt latency a difficult, if not impossible, task. On a lightly loaded system with little or no peripherals, it's likely that the average interrupt latency is much smaller than the maximum. Even so, the Project Trailblazer engineers had no idea of the average interrupt latency magnitude. Was it microseconds or milliseconds? They decided to measure it for each target board.

    tip
    When you are writing device drivers, you should disable interrupts only when your driver requires absolutely no interruption. While interrupts are disabled, Linux does not update system timers, transfer network packets to and from buffers, or update video information. You should perform your interrupt task as quickly as possible. For lengthy tasks, you should split your handler and use tasklets to perform most of the processing.

    Each target board-the MZ104, the MediaEngine, and the RPX-CLLF-has external connections that are capable of generating processor interrupts. In addition, each board can generate an interrupt signal by using one of its own output ports. In the device driver code we're about to discuss, one function asserts the interrupt signal, which causes the interrupt handler to execute. The handler simply deasserts the interrupt signal and exits. The interrupt signal assertion and deassertion can be viewed on an oscilloscope, to determine the average interrupt latency.

    To measure the average interrupt latency, the Project Trailblazer engineers need to do the following: 1. Write a device driver that contains the following:

  • Configuration code for the board's interrupt controller, if necessary
  • A request for the interrupt from Linux
  • A function that asserts the interrupt signal
  • An interrupt handler that deasserts the interrupt signal
    2. Connect an output port pin to a processor interrupt pin and to the oscilloscope.
    3. Load the device driver.
    4. Assert the interrupt pin.
    5. Watch for the deassertion.
    6. Measure the interrupt latency.
    7. Repeat steps 4, 5, and 6 to determine the average interrupt latency.

    As discussed in the section "Linux Timing Sources," earlier, the do_gettimeofday function provides timing information with microsecond resolution. By using two calls to do_gettimeofday, the device driver itself can calculate its own instantaneous interrupt latency. (Instantaneous in this case refers to the interrupt latency associated with a single interrupt event.) The instantaneous interrupt latency value will not be the same for interrupt events. The average interrupt latency is the numerical average of several instantaneous interrupt latency values.

    The magnitude of the average interrupt latency is what the engineers want to determine for each of their target boards. They need to find out if it is greater than 1ms. A race timer with 1ms accuracy requires a timing source with interrupt latencies of less than 1ms. The engineers need to write an interrupt latency device driver for each of their target boards. They then need to execute this device driver several times, record the instantaneous interrupt latency values, and compute an average interrupt latency value for each board. Using the interrupt latency device driver's output combined with an oscilloscope measurement, the engineers can also verify the microsecond accuracy of the do_gettimeofday function.

    The three target board interrupt latency device drivers contain four functions: init, proc_read, interrupt_latency, and cleanup. The init function creates a /proc directory entry called interrupt_latency and configures the processor's interrupt controller and port settings. Reading from the interrupt_latency file calls the function proc_read, which generates an interrupt electrical signal. The device driver handles the interrupt by calling the interrupt_latency function. It then computes and prints the instantaneous interrupt latency value. The driver also maintains an interrupt counter to aid in debugging.

    Part 2 will cover measuring interrupt latency on the MZ104.

  • More Stories By Maureen O'Gara

    Maureen O'Gara the most read technology reporter for the past 20 years, is the Cloud Computing and Virtualization News Desk editor of SYS-CON Media. She is the publisher of famous "Billygrams" and the editor-in-chief of "Client/Server News" for more than a decade. One of the most respected technology reporters in the business, Maureen can be reached by email at maureen(at)sys-con.com or paperboy(at)g2news.com, and by phone at 516 759-7025. Twitter: @MaureenOGara

    Comments (1) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Michael Choo 12/15/03 02:15:00 AM EST

    Dear sir/madam,

    hi! If I write interrupt handler make it as long interrupt latency. I mean inside isr function, call many functions. after then, iret exit isr function. What will happen?

    my experience is:
    1. beginning, system will service interrupts few times. after then stop response even has inteerupt event in.

    2. some unpredicatable happen.

    What is your result? Do you have any document mention this kind of problem?

    Thank you!

    rgs,
    Michael Choo

    IoT & Smart Cities Stories
    Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
    DXWorldEXPO LLC announced today that ICOHOLDER named "Media Sponsor" of Miami Blockchain Event by FinTechEXPO. ICOHOLDER gives detailed information and help the community to invest in the trusty projects. Miami Blockchain Event by FinTechEXPO has opened its Call for Papers. The two-day event will present 20 top Blockchain experts. All speaking inquiries which covers the following information can be submitted by email to [email protected] Miami Blockchain Event by FinTechEXPOalso offers sp...
    Headquartered in Plainsboro, NJ, Synametrics Technologies has provided IT professionals and computer systems developers since 1997. Based on the success of their initial product offerings (WinSQL and DeltaCopy), the company continues to create and hone innovative products that help its customers get more from their computer applications, databases and infrastructure. To date, over one million users around the world have chosen Synametrics solutions to help power their accelerated business or per...
    DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    @DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time t...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
    Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
    SYS-CON Events announced today that IoT Global Network has been named “Media Sponsor” of SYS-CON's @ThingsExpo, which will take place on June 6–8, 2017, at the Javits Center in New York City, NY. The IoT Global Network is a platform where you can connect with industry experts and network across the IoT community to build the successful IoT business of the future.