精华公布栏

发信人: bigapple (红富士), 信区: NTM
标  题: NT for Soft Real-time Control(Performance)
发信站: 哈工大紫丁香 (Tue Jul 25 11:06:38 2000) , 转信

Performance of the Windows NT Operating System
For the purposes of soft real-time, the performance of ISRs and the performan
ce of real-time priority class threads running at the highest available level,
priority 31, are of the most interest to us.  Interrupt service routines offe
r the best soft real-time performance achievable with the standard Windows NT
operating system, but at the same time they restrict the maximum code path len
gth of the control algorithms so other device drivers� ISRs operate correctly.  In addition, I/O scanner adapters cannot be accessed at this level using a standard driver of the Windows NT operating system, so special I/O access must be provided when performing control in an ISR.
Real-time priority class threads running at priority 31 provide the highest l
evel of determinism achievable with the Windows NT operating system, without i
nterfering with hardware operations.  In addition, these threads can access de
vice drivers using standard mechanisms. I/O scanners can be written using stan
dard device driver models of the Windows NT operating system.  This increases
the level of standardization of the software and greatly reduces the risk of i
ntroducing hardware dependent problems into the system that may invalidate Mic
rosoft and OEM (Original Equipment Manufacturer) platform testing.
In addition to setting the thread抯 priority to the highest level, we must also force all of the thread�
s code and data to load into physical memory, and then we must lock it in plac
e, to guarantee that the thread is not delayed by page faulting.  The Windows
NT operating system provides APIs to help accomplish this.  Another advantage
of being a standard process running threads at the highest priority level is t
hat only the code and data associated with the control thread needs to be page
- locked into memory.  Less critical routines that are used to access the cont
roller for programming and supervisory access can be allowed to page fault as
usual without interfering with the operation of the control threads.

Interrupt Service Routine Performance
Minimum execution times for interrupt service routines on a 200MHz Pentium� Pro system were found to be on the order of 5 microseconds.  Assuming that the routine averaged 6 clocks per instruction, this translates to roughly 165 instructions, and is consistent with code path-length information provided by Microsoft. Since this execution time depends on the code path length, we would expect it to scale inversely with clock speed for a given chip architecture.  However, this represents only the minimum interrupt latency.
For low-priority hardware interrupts, maximum interrupt latencies on a 200MHz
Pentium Pro system were observed to be on the order of 75-80 microseconds, wh
ich translates to 450-480 microseconds on a 33Mhz 486.  At 6 clocks per instru
ction, these timings would represent maximum path lengths of ISRs on the order
of 2,500-2,700 instructions.  The occurrence of these longer path lengths may
have been due to preemption by multiple higher priority interrupts.
If interrupt service routines were to be used for soft control, restricting t
he control code path length to 2,500 instructions would likely ensure trouble-
free operation, however this would represent a fairly limited application capa
city.  Most likely, the fast Pentium Pro peripherals could tolerate interrupt-
dispatch latencies commonly seen on slower 486 equipment, so path lengths as l
ong as 15,000 instructions would probably be acceptable.  However, in general,
interrupt service routines should be reserved for only the most time-critical
portion of a control application.
The deterministic control performance of interrupt service routines, in terms
of repeatability, is on the order of 75-80 microseconds on 200Mhz Pentium Pro
systems. In order to perform predictably, a soft control application running
in the context of an ISR must restrict its path length (conservatively) to 2,5
00 instructions, or (optimistically) to 15,000 instructions to prevent it from
interfering with the normal operation of other devices.  On symmetrical multi
processing systems, ISRs can be active for longer periods of time since the ot
her processors can service the rest of the system while the ISR is dispatched.

Real-time Thread Performance
While interrupt service routines only need to worry about the performance of
other interrupt service routines, real-time priority class threads have to wor
ry about pre-emption from ISRs and their DPCs.  The performance of the DPCs is
the major cause of variation for real-time threads.  Our testing suggests tha
t the disk driver, the network driver and, to a lesser extent, the video drive
r, are the major sources of long DPCs.  These drivers may create significantly
sized buffer copies and perform other activities that require substantial cod
e path length.
We tested the performance of real-time threads on a variety of platforms.  Th
e tests indicated that the repeatability of periodic scan cycles was affected
by the presence of different networking and disk driver devices. With a set of
well-performing peripherals, performance scaled inversely with processor spee
d, and was dramatically improved in symmetrical multiprocessing (SMP) systems.

During disk and network stress tests on systems with well-performing peripher
als, we observed roughly 16-millisecond variability on 100Mhz single-processor
Pentium systems, dropping to roughly 8-milliseconds on 200Mhz single- process
or Pentium Pro systems.  These same test results improved dramatically for dua
l-processor systems.  Even 133Mhz dual-processor systems displayed variabiliti
es as low as 3-4 milliseconds with 200Mhz dual processor systems displayed var
iability as low 2-3 milliseconds.  The availability of a second processor seem
ed to improve performance dramatically.  We would expect this result to be eve
n more dramatic on quad-processor systems even though ISR behavior may be slig
htly worse due to inter-processor synchronization issues.

Need for Additional Hardware Performance Certification
During our testing, we did identify some network cards that behaved poorly, w
ith observable delays of 30-40 milliseconds during network stress testing. Vid
eo drivers displayed poor behavior on single processor systems when configured
for very high screen and color resolutions.  These observed variations were l
ikely to be device-driver dependent, driver-configuration dependent, as well a
s device dependent.  This indicates that a more stringent hardware and driver
certification program is needed, beyond Microsoft and its OEMs� basic testing, if the standard Windows NT operating system is to be used for soft control.  As a result, Rockwell Automation is developing standard tests to further certify hardware performance when using the Windows NT operating system for soft control applications.

System Performance in Relation to Control Requirements
The timing of the interrupt service routines was more than adequate for very
high-speed control applications.  However, there are limits to how large a con
trol application can be run in that context without becoming a badly-behaved d
evice driver. Any ISR-based control code requires special interfaces to the
I/O scanner cards, since it can抰 use the standard device driver access model of the Windows NT operating system.
Real-time control threads on well-performing systems demonstrated variations
of up to 8 milliseconds on 200Mhz single-processor Pentium Pro systems, and 16
milliseconds on 100Mhz single-processor Pentium systems.  These variabilities
are slightly below par relative to modern PLC performance but should be accep
table for a wide variety of basic control applications.  Regulatory control wi
th process time constants of greater than 250 milliseconds and interlock logic
without sub-second timing criticalities should not be a problem for these sys
tems.  Real-time control threads performed dramatically better on symmetrical
multiprocessing (SMP) systems.  These systems displayed scan variability that
was fairly good, even by PLC standards.

Summary
The deterministic control performance of the Windows NT operating system was
found to be more than adequate for many control applications.  The interrupt s
ervice routines on fast single processor systems and real-time threads on most
dual-processor systems performed as well as most modern PLC processors.
Real-time threads on single-processor systems performed just beyond the lower
ranges of modern PLC performance, but should be adequate for less time-critica
l process and discrete control applications.
Some video displays, peripherals, and device drivers behaved poorly relative
to other systems. The application of these poorly behaved systems can lead to
unacceptable control performance.  Despite extensive platform certification te
sting performed by Microsoft and its OEMs, Rockwell Automation felt that a hig
her certification standard needed to be set to verify that equipment would per
form adequately for soft control, regardless of operating system selection.  A
s a result, we are further developing our system stress tests to help evaluate
equipment for control applicability.  At this time w

--
※ 来源:．哈工大紫丁香WWW bbs.hit.edu.cn. [FROM: 203.123.2.2]