QA
`76,54
`R59
`1999
`
`PROCEEDINGS OF THE FIFTH
`
`JUNE 2-4, 1999 • VANCOUVER, BRITISH COLUMBIA, CANADA
`
`SPONSORED BY
`THE IEEE COMPUTER SOCIETY TECHNICAL COMMITTEE ON REAL-TIME SYSTEMS
`
`IBEE~
`COMPUTER
`SOCIETY
`♦•
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 001
`
`

`

`PROCEEDINGS OF THE
`
`Fifth. IE,EE Real-Time Technolog:y and
`Applications Symposium
`
`Vancouver, British Columbia, Canada
`June 2 -4, 1999
`
`Sponsored by
`The IEEE Computer Society Technical Committee on Real-Time Systems
`
`IEEE~
`
`COMPUTER
`SOCIETY
`♦-
`
`Los Alamitos, California
`
`Washington
`
`•
`
`Brussels
`
`•
`
`Tokyo
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 002
`
`

`

`Copyright © 1999 by The Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved
`
`Copyright and Reprint Permissions: Abstracting is permitted with credit to the source. Libraries
`may photocopy beyond the limits of US copyright law, for private use of patrons, those articles in
`this volume that carry a code at the bottom of the first page, provided that the per-copy fee
`indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Drive,
`Danvers, MA 01923.
`
`Other copying, reprint, or republication requests should be addressed to: IEEE Copyrights
`Manager, IEEE Service Center, 445 Hoes _Lane, P.O. Box 133, Piscataway, NJ 08855-1331 .
`
`The papers in this book comprise the proceedings of the meeting mentioned on the cover and title
`page. They reflect the authors' opinions and, in the interests of timely dissemination, are
`published as presented and without change. Their inclusion in this publication does not
`necessarily constitute endorsement by the editors, the IEEE Computer Society, or the Institute of
`Electrical and Electronics Engineers, Inc.
`
`IEEE Computer Society Order Number PROO 194
`ISBN 0-7695-0194-X
`ISBN 0-7695-0195-8 (case)
`ISBN 0-7695-0196-6 (microfiche)
`ISSN Number 1080-1812
`
`Additional copies may be ordered from :
`
`IEEE Computer Society
`Customer Service Center
`10662 Los Vaqueros Circle
`P.O. Box 3014
`Los Alamitos, CA 90720-1314
`Tel : + 1-714-821 -8380
`Fax: + 1-714-821-4641
`E-mail: cs.books@computer.org
`
`IEEE Service Center
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`Tel: + 1-732-981 -0060
`Fax: + 1-732-981-9667
`mis.custserv@computer.org
`
`IEEE Computer Society
`Asia/Pacific Office
`Watanabe Bldg., 1-4-2
`Minami-Aoyama
`Minato-ku, Tokyo 107-0062
`JAPAN
`Tel: + 81-3-3408-3118
`Fax: + 81-3-3408-3553
`tokyo.ofc@computer.org
`
`Editorial production by Bob Werner
`
`Cover art production by Alex Torres
`
`Printed in the United States of America by Technical Communication Services
`
`IEEE~
`COMPUTER
`SOCIETY
`
`♦
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 003
`
`

`

`~i.)f
`QI+
`,(o /5'1.f
`Table of Contents
`Rc;-Oi
`v. I 'l'14
`Fifth IEEE Real-Time Technology and Applications Symposium-RTAS'99
`Message from the General Chair _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 1x
`Welcome ____________________________________ x
`xi
`Organizing Committee
`
`t}-76°/ ~(:, 1
`A1114 ys?,J?,,
`I
`
`Opening Remarks
`Azer Bestavros (General Chair) and Victor Fay Wolfe (Program Chair)
`
`Session I: Scheduling
`
`A Responsiveness Approach for Scheduling Fault Recovery in Real-Time Systems _ _ _ _ _ _ _ _ _ _ _ 4
`P. Mejia-Alvarez, D. Mosse
`
`Adaptive Scheduling: Overload Scheduling for Mission Critical Systems _ _ _ _ _ _ _ _ _ _ _ _ _ _ 14
`P. Richardson, S. Sarkar
`
`Scalable Scheduling Support for Loss and Delay Constrained Media Streams _ _ _ _ _ _ _ _ _ _ _ _ 24
`R. West, K. Schwan, C. Poellabauer
`
`Session II: Case Studies I
`
`A Dynamic Real-Time Benchmark for Assessment of QoS and Resource Management Technology _____ 36
`L. Welch, B. Shirazi
`
`Static Properties of Commercial Embedded Real-Time Programs, and Their Implication for
`Worst-Case Execution Time Analysis _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 46
`J. Engblom
`
`Implementation of a Transient-Fault-Tol~rance Scheme on DEOS -
`A Technology Transfer from an Academic System to an Industrial System _ _ _ _ _ _ _ _ _ _ _ _ _ 56
`L. Dong, R. Melhem, D. Mosse, S. Ghosh, W. Heimerdinger, A. Larson
`
`Session III: Languages and Timing Constraints
`
`Implementation of JEM -A Java Composite Event Package _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 68
`G. Liu, A. Mok
`
`Tighter Timing Predictions by Automatic Detection and Exploitation of
`Value-Dependent Constraints _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 79
`C. Healy, D. Whalley
`
`Timing Constraint Remapping to Avoid Time Discontinuities in Distributed Real-Time Systems _ _ _ _ _ 89
`M. Ryu, J. Park, S. Hong
`
`V
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 004
`
`

`

`Session IV: Databases and Operating Systems
`
`MIRROR: A State-Conscious Concurrency Control Protocol for Replicated Real-Time Databases _____ 100
`M . Xiong, K. Ramamritham, J. Haritsa, J. Stankovic
`
`Portable RK: A Portable Resource Kernel for Guaranteed and Enforced Timing Behavior ________ 111
`S. Oikawa, R. Rajkumar
`
`Experiences using RT-Linux to Implement a Controller for a High Speed Magnetic Bearing System ____ l21
`M. Humphrey, E. Hilton, P. Allaire
`
`Session V: Real-Time Windows NT
`
`Using Windows NT in Real-Time Systems _________________________ l32
`A. Baril
`
`Comparing the Real-Time Performance of Windows NT to an NT Real-Time Extension ________ 142
`K. Obenland, J. Kowalik, T. Frazier, J. Kim
`
`Session VI: Real-Time Middleware
`
`The Design and Performance ofa Real-Time 1/0 Subsystem ___________________ l54
`F. Kuhns, D. Schmidt, D. Levine
`
`User Level Scheduling of Communicating Real-Time Tasks ___________________ 164
`C. Shen, 0. Gonzalez, K. Ramamritham, I. Mizunuma
`
`An End-to-End QoS Management Architecture _______________________ 176
`M. Shankar, M. De Miguel, J. Liu
`
`Session VII: Real-Time Communication
`
`Statistical Real-Time Communication over Ethernet for Manufacturing Automation Systems _______ ! 92
`S. Kweon, K. Shin, Q. Zheng
`
`Analyzing Multimedia Traffic in Real-Time ATM Networks ___________________ 203
`M. Sjodin, H. Hansson
`
`QDMR: An Efficient QoS Dependent Multicast Routing Algorithm _______________ 2 I 3
`L. Guo, /. Matta
`
`Session VIII: Case Studies II
`
`An Event Channel-based Embedded Software Architecture for Developing Telemetric and
`Teleoperation Systems on the WWW ___________________________ 224
`J. Moon, J.Park, S. Kang
`
`General Purpose Architecture for Real-Time Feedback Control in Nuclear Fusion Experiments ______ 234
`A. Luchetta, G. Manduchi
`
`A Summary of Communication Middleware Requirements for
`Advanced Shipboard Computing Systems ________________________ 245
`M. Swick, J. White, M. Masters
`
`vi
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 005
`
`

`

`Timing Analysis of the X-38 Space Station Crew Return Vehicle Avionics _____________ 255
`L. Rice, A. Cheng
`
`Session IX: Quality of Service
`
`Adaptive QoS and Resource Management using a Posteriori Workload Characterizations ________ 266
`L. Welch, P. Werme, L. Fontenot, M. Masters, B. Shirazi, B. Ravindran, D. Mills
`
`On Quality of Service Optimization with Discrete QoS Options _________________ 276
`C. Lee, J. Lehoczky, R. Rajkumar, D. Siewiorek
`
`Invited Presentation
`
`*The Problems You're Having May Not Be the Problems You Think You're Having:
`Results from a Latency Study of Windows NT ________________________ 287
`M. Jones, J. Regehr
`
`Index of Authors ______________________________ 293
`
`*Originally published in the Proceedings of the Seventh Workshop on Hot Topics in Operating Systems (HotOS-Vll),
`Rio Rico, Arizona, IEEE Computer Society, March 1999.
`
`vii
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 006
`
`

`

`Using Windows NT in Real-time Systems
`
`Allan Baril
`Spar Aerospace Ltd.
`9445 Airport Road, Brampton, Ontario, Canada
`~baril@spar.ca
`
`Abstract
`
`gain insight into what limitations Windows NT places on
`the development of a real-time system.
`
`Due to Windows NT's widespread acceptance on
`desktops in business and industry,
`it is also being
`considered for use in real-time systems. The fact that
`Windows NT is a general-purpose operating system
`complicates its application into a real-time environment.
`We have performed an extensive performance evaluation
`of Windows NT to determine if we can use it in the
`development of future real-time systems. The evaluation
`involved measuring interrupt and defe"ed procedure call
`latencies as well as many other system performance
`aspects which would affect the performance of a real-time
`system. The results have provided us with insight on what
`types of real-time systems can and cannot be implemented
`with Windows NT
`
`1.
`
`Introduction
`
`the de-facto
`is quickly becoming
`Windows NT
`standard for desktops in business and industry. As such,
`many people are trying to apply Windows NT as a
`common operating system across all uses
`in
`their
`businesses, which includes use in real-time systems. For
`example,
`the OMAC, Open Modular Architecture
`Controls, Users Group [7] is looking at Windows NT for
`is a relatively mature
`this purpose. Windows NT
`operating system with an extensive programming
`interface. There are probably more developers who are
`familiar with the Win32 API than those provided by other
`operating systems.
`Of course, these strengths also lead to some of
`Windows NT's weaknesses when used in a real-time
`system. Windows NT was designed as a general-purpose
`operating system, with the goal to maximize visible
`performance to the user. To a real-time system, timely,
`predictable performance
`is much more crucial
`than
`overall system performance. An extensive performance
`analysis of Windows NT with respect to aspects that
`concern a real-time operating system was conducted to
`
`1080-1812/99 $10.00 © 1999 IEEE
`
`132
`
`1.1. Overview of Windows NT Architecture
`
`Before discussing the performance analysis conducted,
`it is important to have some understanding of Windows
`NT's internal architecture. Windows NT was originally
`based on a micro-kernel design, which is popular with
`many real-time operating systems (e.g. VxWorks, QNX).
`Its architecture has diverged from this though, mainly for
`performance reasons. For example the graphics subsystem
`has been incorporate into the kernel space.
`IROLs
`31
`30
`29
`28
`27
`26
`
`High
`Power Fail
`Interprocessor Int.
`Clock
`Profile
`Device n
`
`Device 1
`DPC
`APC
`
`Time Critical
`NIA
`Highest
`Above Normal
`Normal
`Below Normal
`Lowest
`NIA
`Idle
`
`Priority
`
`31
`
`26
`25
`24
`23
`22
`
`16
`
`ill
`
`!!!. t ,,
`g
`'< f 2
`
`3
`
`f
`j
`f 2
`
`3
`
`Time Critical
`
`Normal Foregmd
`
`Normal Backgrnd
`
`Idle
`Idle Thread
`
`Figure 1. Priority structure
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 007
`
`

`

`actual performance values or considers only a specific
`type of real-time system.
`Some previous performance evaluations of Windows
`NT have been conducted, [I], [2). These evaluations
`concentrate on aspects that measure Windows NT's
`performance as a general-purpose operating system,
`instead of focusing on aspects, which affect performance
`of a real-time system.
`
`2.
`
`Performance Evaluation
`
`Microsoft is very protective of the source code for
`Windows NT, so at best a black box approach to
`performance analysis can be conducted. The performance
`evaluation that was conducted concerned itself with
`performance aspects that affect the determinism and
`responsiveness of a real-time system. In particular, the
`aspects we concerned ourselves with included: interrupt
`latency, interrupt execution, DPC latency, context switch
`time, and the effects of paging on the system.
`
`3. Methodology
`
`3.1. Experimental System
`
`The testing was performed on Windows NT 4.0 with
`service pack 3 installed. The hardware on which the
`measurements were conducted consisted of a Ziatech
`5080,
`including a Ziatech ZT5510 Single Board
`Computer with I 66Mhz Pentium processor and 64MB of
`RAM. The system contained a ZT6620 Wide SCSI
`interface, ZT663 I Super VGA interface w/4MB running
`at 1024x768 with 16bit color, a ZT6610 quad serial
`interface, ZT5980 system utility board including a 3.2GB
`Hitachi DK226A-32 IDE hard drive, Sensoray 711 frame
`grabber, and a Seagate ZTl 5230WC 4.2GB SCSI hard
`drive.
`A second machine was used to induce interrupts on the
`Ziatech machine by sending information through the
`-serial ports. The second machine was a HP Vectra VL
`with Pentium l 33Mhz, 64MB of RAM, 4 serial ports and
`Windows NT 4.0 with service pack 3. A HP 1650 Logic
`Analyzer was used to conduct some of the measurements
`such as the ISR latency as signals on the CompactPCI bus
`needed to be measured. Figure 2 provides photographs of
`the equipment which was used.
`
`The scheduler is probably the most important piece of
`a real-time operating system as it is responsible for
`providing timely, deterministic time slices to the threads
`of a real-time system. Figure I illustrates the overall
`structure of the priority system provided by Windows NT.
`The highest priorities are given to the interrupt service
`routines (ISRs) for the system clock and other hardware
`devices. Next are the deferred procedure calls (DPCs)
`which are typically spawned from an ISR to continue
`work at a lower priority. Asynchronous procedure calls
`(APCs) are used to execute code in the context of a user
`thread. For example, the completion routine from an
`asynchronous file write (FileWriteEx) runs at this level.
`All of the priority levels discussed so far are only
`available to code running in kernel-mode (either the OS
`itself or a device driver).
`The user-mode priority levels are divided into two
`main groups: dynamic and real-time. In certain cases, the
`scheduler will boost the priority of threads running in the
`dynamic range (for example,
`if it belongs to
`the
`foreground window or has returned from a driver call).
`This makes the system appear more responsive to the
`user. Unfortunately it makes it difficult, if not impossible,
`to provide deterministic behavior. Hence Microsoft added
`the real-time priority spectrum to NT. The real-time
`priority spectrum includes priority levels 16 to 31
`(excluding 17 to 21 and 27 to 30 as these levels are
`unavailable). No priority boosting is conducted by the
`system to threads at these levels and priorities 31, 26, and
`25 are higher than the system threads. As will be seen,
`these levels do not provide deterministic behavior.
`Since NT was designed to be a general-purpose
`operating system, many design decisions were made to
`maximize overall system performance as seen by the end
`user. Of course some of these decisions are problematic at
`best to a real-time system. Windows NT uses paging to
`allow execution of applications which demand more
`memory than is physically available in the system. Paging
`in a real-time system can ruin all predictability. Worse,
`we have found that paging in one thread can affect the
`performance of other higher priority threads in the
`system. Windows NT also allows priority inversions. It
`attempts to solve them by boosting the priority of threads
`which have been starved for 3 to 4 seconds; not really a
`solution when dealing with events on the micro and
`millisecond scale.
`
`1.2. Related Work
`
`Interest in the topic of using Windows NT for real-time
`computation can be observed by the multitude of articles
`available in industry magazines, [3], [8], [12), from
`Microsoft, [5), and some previous research papers, [6],
`[9). Most of this previous work either does not include
`
`133
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 008
`
`

`

`Figure 2. Test equipment
`
`3.2. Applications
`
`Several applications were developed to conduct the
`performance evaluations and to generate different load
`conditions. All of the applications were developed with
`Visual C++ 5.0 and the custom device drivers were
`developed with the Windows NT 4.0 DOK.
`
`3.3. Load Conditions
`
`Load condition was one of the main factors varied
`between different levels on most of the tests. This allowed
`us to evaluate the effect that different load conditions
`have on the performance aspect being measured. Several
`applications were developed and used to provide standard
`load conditions.
`
`3.3.1. CPUStress
`
`The CPUS tress application is part of the Windows NT
`4.0 Resource Kit. It generates a specified level of
`utilization on the CPU. It was used in many of the test
`cases to generate a constant percentage of load on the
`CPU.
`
`3.3.2. Thrasher
`
`to produce a
`This application was developed
`continuous load on the hard drive by constantly reading
`and writing to a file . It is used in the disk load related tests
`
`3.3.3, NetThrasher
`
`The NetThrasher workload actually is composed of
`two separate programs. One, NetThrashC, is the client
`while NetThrashS is the server. The client sends a block
`of information to the server over a network connection.
`
`The server then returns the same block back to the client.
`Sockets are used as the means of communication between
`the two systems. The NetThrasher suite was developed to
`produce a _network load for several of the test cases.
`
`3.3.4. DisplaySim
`
`A workload, called DisplaySim, was designed to
`simulate a general application that displays information
`received from an interrupt-driven hardware interface. This
`workload uses a couple of applications. First a user
`application called MainDisp was run to update some text
`and bitmaps on the screen at a rate of 200ms. In the test
`system, four copies of a custom serial driver were run in
`conjunction with the quad serial port to simulate the
`interface to the hardware. Finally an application was
`the HP Vectra
`to periodically send
`developed for
`information over the different serial ports simulating the
`interaction with the interfaced hardware.
`
`4. Evaluation Results
`
`4.1. ISR Latency
`
`Interrupt latency is very important in a real-time
`operating system since normally the event which needs to
`be handled in a timely fashion is tied to a piece of
`hardware which interrupts the system to let it know when
`it is done and/or ready to be serviced. Typically this event
`needs to be handled as soon as possible to ensure that the
`results stored
`in
`the hardware's
`registers are not
`overwritten or lost.
`The test was conducted using two different methods.
`The first method used a custom serial device driver which
`handles interrupts at vector 11 from the serial port. During
`the driver's ISR, it reads the data register on the serial
`port a specified number of times and stores the results in
`
`134
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 009
`
`

`

`interface raises interrupts at vector I 0, so it will preempt
`the serial driver 's ISR which was at vector 11.
`
`ISRTlmerRnulta
`
`Noload
`
`0-,.,.)'Sim
`
`2&'1!.'-'CPU
`
`"°:-iCPU
`
`"'°:.ciCPU
`
`100:,.;F'U C~
`
`...
`
`Figure 3. ISRTimer results
`
`The results using ISRTimer, Figure 3, show that the
`maximum interrupt latency observed was 33 .78 µs , which
`occurred under the 40% CPU/net load at interrupt vector
`11 . Without network traffic, the maximum latency was
`almost a third less, at 12.3 7 µs.
`
`Interrupt Latency Samples with No Load at Vector 3
`
`5
`
`-~
`
`-
`
`-:--1--- -~ - -------+-----
`I
`
`I
`
`.
`
`-· .
`
`!
`I•
`! 4 +--- - - t - --.---, • .-+.- .- - 1-- -- --~
`I 3
`i::
`
`• •• •
`
`•
`
`• •
`
`200
`
`400
`
`600
`
`800
`
`1000
`
`Sample
`
`Figure 4. Interrupt latency samples
`The average interrupt latency across the different
`interrupt vectors is a respectable 4.28 µs . The coefficients
`of variance were calculate and found in all cases to be
`quite low, ranging from a low of 0.077 for interrupt 5
`with 40% CPU load to the highest value being 0.423 for
`interrupt 11 with 40% CPU and network load. These low
`coefficients of variance show that the values are fairly
`constant and predictable. Figure 4 illustrates the samples
`for the test conducted at vector 3 with no load. As can be
`seen, the values are pretty much grouped in the same
`region but there are several different layers. These layers
`are most likely due to interrupts, such as the system clock,
`preempting the interrupt of interest.
`
`memory. This simulates the reading of data from the
`interface. At the start of the ISR, a signal on one of the
`pins of the parallel port is raised. A probe from the logic
`analyzer was attached to this parallel port pin and another
`probe was then attached to the PCI interrupt pin on the
`back of the quad serial board. By measuring
`the
`difference between the time in which the PCI interrupt
`was issued on the bus to the raising of the parallel port
`signal, we were able to calculate the latency involved
`from the point in time of the hardware issuing the
`interrupt, to the interrupt service handler in Windows NT
`handling it. The software on the HP Vectra would
`periodically send information over the serial port to cause
`the interrupts on the Ziatech machine.
`The second method used another custom device driver
`called ISRTimer to measure the interrupt dispatching time
`of Windows NT without introducing hardware latency
`into the measurement. ISRTimer attaches itself to an
`interrupt vector, specified
`though
`the registry, and
`periodically issues an INT n call, where n is the interrupt
`vector it is attached to. This causes the processor to raise
`an interrupt which NT eventually routes to ISRTimer to
`handle. The time between raising the interrupt and its
`handling is measured by ISRTimer and stored internally
`in memory. The time stamp counter on the Pentium, as
`described in [ 4 ], [ JO] , is used to get the timings which
`provides an accuracy relative to the processor's speed
`(~6.02 ns resolution for a 166Mhz processor). The timing
`information was then retrieved from the device driver and
`stored in a file so it could be analyzed.
`The tests were conducted under several different load
`conditions. The tests were also conducted at different
`interrupt vectors of 3, 5, and 11 , under the second method
`with ISRTimer, to ascertain if the level has an effect on
`the performance.
`The following table summarizes the results using the
`custom serial driver:
`Load
`No load
`Displa_ySim
`25%CPU load
`40%CPU load
`70% CPU load
`100% CPU load
`40% CPU/disk load
`70% CPU/disk load
`Net load
`40% CPU/net load
`AVERAGE
`
`Avg. (us)
`7.985
`12.28
`8.267
`8.095
`8.435
`8.54
`12.46
`12.69
`11.83
`13.69
`10.43
`
`Max. (ps)
`10.52
`21 .38
`11.44
`11 .6
`9.52
`9.84
`21.16
`30.64
`40.96
`43.76
`21.08
`
`As can be seen, the maximum measured overall was
`43 .76 µs , while the average across all the load conditions
`was I 0.43 µs. It is important to note that the Ethernet
`
`135
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 010
`
`

`

`Effects of Interrupt Vector
`
`Sr-----------------,
`
`5 ----- - ---------------- - -----·- -
`
`0
`
`ISRTimer3
`
`ISRTimer5
`Vector
`
`ISRTimer11
`
`Figure 5. Effect of interrupt vectors
`
`We can also observe the effects of different interrupt
`vectors. This is illustrated graphically in Figure 5. On
`average, there appears to be a linear relationship between
`the priority and the time to service. Since NT gives higher
`priority to lower interrupt vectors, this confirms the
`priority structure that NT provides to interrupt service
`routines.
`From the results, it can be observed that differing CPU
`loads has no noticeable effect on the latency of interrupt
`handling. This is as we would expect since when an
`interrupt occurs, assuming interrupts are enabled, the
`processor puts what it is doing on hold and handles the
`interrupt immediately. With NT's priority scheme, as long
`as no higher priority interrupts are currently being
`serviced, the interrupt handler is immediately dispatched.
`We do observe some delay in servicing the interrupt when
`load is generated which causes other interrupts, like those
`from the disk and Ethernet.
`Finally, comparing the results from the ISRTimer
`values at vector 11 and those measured from the custom
`serial driver (which was also handling interrupts at vector
`11 ), we can make an estimate as to the latency introduced
`by the hardware when handling an
`interrupt. Since
`ISRTimer generates interrupts through software, it does
`not have the latency due to the programmable interrupt
`controller (PIC) and the PCI bus. The timings for the
`custom serial driver are measured from the point of the
`interrupt being raised on the CompactPCI bus to the
`device's ISR being issued. The results show that the
`average latency introduced by the hardware is 4.22 µs.
`This average was calculated using only the loads where
`no other interrupts occur since the maximums would skew
`the results. It is interesting to note that the maximum
`times measured with
`the custom serial driver were
`observed to be greater only when other interrupts were
`occurring (i.e.
`loads with disk and network access
`
`occurring). This is presumed to be the effect of the PIC
`disabling other interrupts in the system until the current
`one is serviced.
`
`4.2. ISR Execution
`
`We measured the length of time that the custom serial
`driver's ISR executed to verify Windows NT's priority
`structure. Since the ISRs have the highest priority in the
`system, they should only be preempted by higher priority
`ISRs. This would indicate that the ISR execution has a
`relatively small number of disturbances.
`The ISR execution for the custom serial driver was
`measured through some built-in instrumentation. At the
`start of the ISR, the custom serial driver would raise a
`signal on a parallel port pin and then lower the signal at
`the end of the ISR. The HP logic analyzer was then used
`to measure the length of time the signal was raised. The
`measurements were conducted under the same load
`conditions as for the ISR latency measurements.
`
`ISR Exocutlon Under Various Loads
`
`!-- - - -- - - - - ----------- ~-
`
`~
`7
`~
`
`■ Max )
`Figure 6. ISR execution under various loads
`
`/ OA,yg
`
`Figure 6 illustrates the resulting execution times
`measured under the different load conditions. As can be
`seen the average execution time is fairly stable. The
`maximum is fairly stable except when other interrupts are
`occurring. This makes sense since the custom serial driver
`interrupt vector is 11 and will be preempted by lower
`vector numbers, which includes the Ethernet driver. It is
`interesting to note that the disk appears to also have an
`effect on the ISR execution time which seems odd since
`the IDE controller was generating interrupts at vector 15.
`This could be explained by the fact that it is NT that is
`enforcing this priority scheme, not the hardware. So the
`IDE
`interrupt handler
`is
`immediately dispatched,
`preempting our driver, but as soon as the handler is
`dispatched, NT realizes the IDE ISR is lower priority than
`the currently executing one and returns back to our ISR.
`Unfortunately the logic analyzer used does not report
`standard deviations, but, as can be seen, the maximums
`
`136
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 011
`
`

`

`are fairly close to the averages which would lead us to
`conclude that the timings are fairly stable.
`Since higher priority ISRs will preempt lower priority
`ISRs, we felt it would be valuable to measure the
`execution time for the ISRs of the drivers included with
`Windows NT. This gives us an idea of how much we can
`expect execution of an ISR to be delayed due to the
`execution of other ISRs in the system.
`A custom device driver, Rewire, was developed to
`measure the execution length of different interrupt service
`routines in NT. Rewire replaces a targeted device driver's
`entry in the interrupt descriptor table (IDT) with its own
`interrupt handler. In its interrupt handler, it simply raises
`a signal level on the parallel port, sets up the stack so the
`targeted driver's interrupt handler will think it received
`the dispatch, calls the targeted interrupt handler which it
`replaced, and when the system returns from the call it
`lowers the signal level on the parallel port. Using the
`logic analyzer, we measured the length of the signal to
`determine the ISR execution time for various drivers.
`
`The next priority level after the ISRs, as seen in Figure
`1, is the DPC queue. Since only a limited amount of work
`can be done at the ISR level, most real-time systems will
`probably need to conduct some tasks at the DPC level or
`below.
`The custom serial device driver was used to measure
`the DPC latency. After completing the ISR, the driver
`issues a DPC, allowing us to measure its dispatch time.
`Instead of using the parallel port and logic analyzer, as we
`did for the ISR related timings, these measurements used
`the time stamp counter in the Pentium to measure the time
`between issuing the DPC and the start of execution of the
`DPC. The test was conducted several times under the
`same load conditions as the previous tests.
`
`DPC Latency Measurements
`
`ISR Execution of Various Ori-•
`
`TIIM(we)
`
`nM(u•)
`
`Figure 8. DPC latency measurements
`
`Figure 7. ISR execution of various drivers
`
`Figure 7 illustrates the results from the measurements.
`Measurements were conducted for the NT system clock,
`the Microsoft serial mouse driver, the standard IDE
`(ATAPI) driver,
`the Adaptec AIC-78xx PCI SCSI
`(AIC78xx) driver, the DEC 21140 Ethernet (DC21X4)
`driver, and the custom serial driver. As we can see, the
`interrupt service routines of these drivers are relatively
`short. Comparing the measurements generated with the
`instrumentation in the custom serial driver with those
`generated through the use of Rewire show they are
`similar, but about 5 µs higher in the case of Rewire's
`values. This indicates that the values generated through
`Rewire are fairly accurate and the extra time is most
`likely due to some overhead generated by Rewire and/or
`the instrumentation in the serial driver.
`
`4.3. DPC Latency
`
`Table 1. DPC latency standard deviation
`cov
`0.142
`10.051
`0.760
`0.138
`0.135
`0.146
`3.880
`3.969
`0.699
`0.743
`
`Load
`No load
`DisplaySim
`25% CPU load
`40% CPU load
`70% CPU load
`100% CPU load
`40% CPU/disk load
`70% CPU/disk load
`Net load
`40% CPU/net load
`
`StDev
`1.072
`1067.522
`6.197
`1.031
`0.962
`1.148
`198.532
`220.019
`9.499
`12.414
`
`Figure 8 and Table 1 summarize the results from the
`DPC _queue latency measurements. These measurements
`confirm the fact that the DPC queue is a FIFO queue;
`huge delays every so often are seen due to waiting for
`DPCs
`from other
`interrupts
`to execute. For
`the
`DisplaySim load, we note an enormous delay of 17.796
`ms, almost 180 times the average of 106.21 µs. The
`experiments later conducted regarding the effects of the
`page file indicate that these extreme times are most likely
`
`137
`
`MICROCHIP TECH. INC. - EXHIBIT 1007
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 012
`
`

`

`due to paging activity. The disk interrupts are seen to lead
`to large delays of up to 1.558 ms. The DPC queue latency
`appears unaffected by CPU load, as it should be, since the
`DPC queue has higher priority then any user priority
`threads. The standard deviations and their coefficients of
`variance of
`the
`loads with other
`interrupts are
`exceptionally high. This illustrates a lack of determinism
`for jobs issued at the DPC level. Since all user priorities
`are below the DPC level, this affects the determinism of
`those below as well.
`
`DloplaySlm Load
`
`......
`
`40% CPU/disk load
`
`I
`
`Tlme(ua)
`
`,oo -
`
`, I
`
`.:..
`
`since delays in a context switch will affect the timing and
`determinism of a system with multiple interacting threads.
`An application called CSwitch was developed to
`benchmark the context switching performance of both
`threads and processes in Windows NT. It creates either
`two processes or two threads upon startup. One of the
`threads/processes, the client, blocks on an event, while the
`other, the server, signals the other thread/process. Upon
`signaling the other thread/process, the server then waits
`on another event. This causes the NT scheduler to then
`schedule the client since it is now ready to run. Once the
`client executes, it signals the event that the serve