精华公布栏

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

Key Areas of Concern with Extension Approaches

The previous sections of this paper discussed general background information r
egarding deterministic control requirements and provided a detailed assessment
of the performance, design, reliability and fault tolerance of Windows NT ope
rating systems.  This section discusses some of the key areas of concern that
we had when we reviewed alternative approaches to standard Windows NT operatin
g systems.  These alternatives included providing real-time extensions to the
Hardware Abstraction Layer (HAL) and subsequently combining a Windows NT opera
ting system with a real-time kernel.

Despite some confusion in their positioning, all of the extension approaches w
e reviewed, including VenturCom, Imagination Systems and Radisys, were very si
milar. All included modifications to the HAL, and introduced a proprietary rea
l-time kernel for scheduling real-time activities.  Over time, these approache
s have influenced one another and have become even more similar.  Though they
all claimed that their kernels were derivations of their previous products, al
l were, in fact, new code bases.  From the perspective of real-time extensions
, their approaches have converged.
General Schematic of Real-time Extensions for VenturCom and Imagination System
s
The most significant difference between the approaches was that Radisys INtime
provided a memory protection scheme between its real-time kernel and the Wind
ows NT operating system kernel, using the hardware-tasking model built into th
e Intel processor.  Unfortunately, this restricted INtime to Intel processors.
  In addition, INtime did not support symmetrical multiprocessing (SMP).  With
dual-processor SMP systems already widely available, and quad-processor syste
ms starting to emerge, this limitation is a major drawback.
While all three approaches promised to improve the deterministic control perfo
rmance of the Windows NT operating system, they also introduced key problem ar
eas with their designs, their complexity, their supportability and their long-
term viability.

Design Issues
To make sure that the Windows NT operating system could not interfere with the
response of the real-time systems, all the real-time kernels execute above th
e highest hardware IRQL. They operated as if they were the highest priority in
terrupt of the Windows NT operating system.  From the perspective of the opera
ting system, they can be considered as high priority interrupt service routine
s (ISRs). Typical drivers of the Windows NT operating system limit their ISRs
to code path lengths of less than 2,500 instructions, and delays of up to 80 m
icroseconds on a 200MHz Pentium Pro.
By executing extensive control applications at elevated IRQL, all of these app
roaches had the potential to violate Windows guidelines for well-designed driv
ers.  Many devices can only tolerate interrupts being blocked for a short peri
od of time before they lose data.  For instance, the 16550 UART has a
16-character FIFO queue.  At 19.2 Kbps, that queue can receive roughly 8 milli
seconds of data before it has to discard characters.  Similarly, network adapt
ers typically have 8K to 64K of RAM to queue received packets. If queue is exc
eeded, then new frames are discarded and reacquired later by the time-out logi
c.
Though some of these vendors had strategies for preventing starvation of the W
indows NT operating system, they typically involved time-slicing the system at
a fairly high frequency (every 250-500 microseconds) or requiring SMP systems
.  The time-slice approach would greatly increase the likelihood of pre-emptin
g critical sections of interrupt service routines, which was considered a desi
gn risk.  Standard drivers are designed so they can prevent preemption by elev
ating the IRQL. With these real-time extension systems that does not work. The
se drivers would be operating in an untested mode in which critical sections m
ay be pre-empted, and introduce undesirable behavior.  Furthermore, if preempt
ion problems existed, they would be extremely difficult to reproduce and isola
te, and they would manifest themselves as random system crashes.  As we have a
lready mentioned, SMP systems work very well without extensions, so why go to
the trouble of modifying the Windows NT operating system if you are going to a
lways use SMP systems anyhow?

In addition, at this elevated IRQL, there is no way to synchronize with the ke
rnel and to directly call kernel services, or for that matter, any device driv
ers or system libraries whatsoever.  Approaches that do not partition the real
-time systemˇs memory could use kernel services to load images from disk and
to load dynamic link libraries (DLLs) before they started their real-time thre
ads; however, the partitioned memory approach precluded even this arrangement.
  Consequently, these systems had to provide their own process and image loade
rs.
The inability to leverage existing device drivers was a major disadvantage of
this approach. Drivers for the hard disks, serial ports, parallel ports, and T
CP/IP networking are critical to writing soft control applications. Also, thes
e real-time executives required device-partitioning schemes that are not recog
nized or supported by detect feature on the Windows NT operating system, or th
e upcoming enhancements to plug and play system technology.
We expect the universal serial bus (USB) and FireWire (IEEE 1394) peripheral d
evice standards to play an important role in soft control, and these schemes p
reclude leveraging of Microsoftˇs class drivers for these subsystems.  USB is
slated to replace both the keyboard, printer and communications ports on mode
rn PCs. USB provides as many as 126 devices per port, with throughput rates of
4-12Mbps and built-in support for removal and insertion under power (RIUP).
FireWire is expected to provide high-speed interfacing of devices (200+ Mbps),
also with multi-drop and RIUP capabilities.
In all of the real-time environments, you could not link against static versio
ns of standard Microsoft run-time libraries because they include operating sys
tem synchronization and DLL dependencies. Consequently, the extension technolo
gy vendor has to provide their own fully re-entrant, multi-threaded, run-time
libraries including floating-point and transcendental function support, to all
ow their real-time kernelˇs threads and interrupt routines to use floating-po
int math. Reliance on the real-time system vendorsˇ libraries made it impossi
ble to incorporate key Microsoft technologies directly into the control produc
ts.  Our product plans view integration of the control system with Microsoft t
echnologies such as DLLs and component object model (COM) components including
ActiveX controls as two key driving forces for open control.  Other key drivi
ng forces include direct integration with Windows-based MMI and SQL database s
ystems.

Complexity Issues
Not only did the real-time executives introduce development constraints and th
e risk of unpredictable behavior, but they also increased system complexity.
For high-speed, floating-point intensive applications such as advanced General
Motion Control (GMC), Computer Numeric Control (CNC), and coordinated drive c
ontrol these improvements in determinism may be needed and are certainly desir
able.  Still, we felt there were much simpler alternatives available for perfo
rming these activities without assuming the risks associated with modifying th
e Windows NT operating system.
PCI bus-mastering coprocessor boards can perform extremely high-speed control
on the PC bus without interfering with the operation of the Windows NT operati
ng system.  This approach provides guaranteed real-time performance for advanc
ed GMC and CNC applications without constraining the control application runni
ng on the Windows NT operating system.  These coprocessor board approaches pro
vide more firewall than any of the real-time extension approaches since they c
an continue to run even if the main processor executes a hard stop (CLI; HLT;)
or encounters a critical NMI.
One final complexity issue involved the need to partition devices and drivers
into a real-time set and a set for the Windows NT operating system.  Though th
is may seem reasonable on the surface, it overlooks a common class of devices
that need to be shared between the real-time environment and the environment o
f the Windows NT operating system: the disk drives, the serial ports, the para
llel ports, and the network adapter.  In addition, it forces industrial interf
ace card vendors to provide two sets of device drivers: one for the Windows NT
operating system, and one for the real-time executive.
Providing a Local Procedure Call (LPC) mechanism between the real-time executi
ve and the call server of the Windows NT operating system can provide an inter
face between the two systems, but this also adds another layer of complexity t
o the puzzle.  LPC proxies and stubs available to access the services of the W
indows NT operating system.  Some vendors are providing routines to access the
registry, the disk drive, and the generic drivers of the Windows NT operating
system.  Of course, when the real-time thread uses services in the Windows NT
operating system, it is no longer real-time, and the real-time system is no l
onger independent of the operating system.

Reliability Issues
In terms of system reliability, we felt that, at best, an extended version of
the Windows NT operating system would be slightly less reliable than standard
Windows NT operating system.  With over 5,000,000 users, an extensive test pro
gram for its development, and an extensive OEM program for hardware compatibil
ity testing, we felt that the Windows NT operating system was extremely reliab
le.  Problems are often tracked to problem hardware or device drivers that are
not on the hardware compatibility list or may soon be taken off.
On the other hand, these real-time extensions are still in development or vers
ion 1.0 code.  Despite liberties taken by vendors to try to tie their reputati
ons to past projects, they all represent new designs. Since most of these syst
ems are still at the beta-test stage, it is impossible for us to determine the
ir reliability at maturity.  Given their corporate resources and the wide vari
ety of solution providers working with them, it is very unlikely that they wil
l have a platform certification program even comparable to the Microsoft progr
am.
Of the extension vendors, only Radisys INtime makes the claim that its environ
ment can survive unexpected kernel exceptions in the kernel or its device driv
ers.  We question whether continuing operation after this point is safe (as di
scussed earlier in the ¨Understanding the Blue Screen of the Windows NT Opera
ting System〃 section). For our soft control designs, INtime does not provide
a rich enough environment to host our entire control application. If we had ba
sed our system off of INtime, or any of the alternatives, we would have been d
ependent on the successful execution of both the Windows NT operating system a
nd the real-time extensions.

Support Issues
Perhaps the most distressing issue confronting these extension technologies wa
s long-term support.  In general, Microsoft does an outstanding job of issuing
service packs and providing information regarding their purpose and function.
  However, reliance on a third-party vendor to test the extended environment,
propagate the request through its solution providers, and then have the soluti
on provider provide a unified service pack to the customer was considered a su
pport nightmare.  The problem only gets worse for major revisions of the Windo
ws NT operating system. We felt the risk of poor support increased over time,
as technologies diverge from those that were installed, and the vendorsˇ inte
rests move to newer accounts.
Since all of the real-time executive vendors provide modified HALs, they also
have to deal with associated OEM HAL conflicts.  Microsoft licenses the HAL co
de to OEMs so they can add hardware-specific support for their advanced platfo
rms.  Features such as symmetrical multiprocessing, power management, multiple
busses, and the like may require HAL customization to be supported.  Unfortun
ately, the HAL is a monolithic DLL, and customizations cannot be merged.  Cons
equently, some OEM hardware will not be supported by these real-time extension
s, with advanced server platforms being the most likely category of incompatib
ility.
Furthermore, we felt the presence of intrusive real-time extension systems mig
ht invalidate Microsoftˇs and its OEMsˇ platform certification testing.  Sin
ce the real-time extensions introduce untested stalling and preemption activit
y into the standard device drivers, some of these drivers were considered like
ly to exhibit problems.  Furthermore, problem isolation and problem accountabi
lity were likely to be unusually difficult to resolve given this environment.

There is also a major initiative underway to improve the plug and play capabil
ities of Windows NT operating system version 5.0.  While this is an improvemen
t long awaited by end-users, it is likely to be a major support issue for real
-time extension vendors.  Since the device driver model for the Windows NT 5.0
operating system is going to change, there will be strong momentum to move to
the new platform. The plug and play system does not understand device partiti
oning and will have to be overridden or cleverly misdirected in order to confi
gure systems with real-time extensions.

Long-term Issues
Beyond the design constraints, the added complexity, the reliability issues, a
nd the expected support issues, are the long-term issues of technology evoluti
on.  First, the expected improvements in system performance of the Windows NT
operating system (as a result of Mooreˇs law, increases in processor speed fo
stered by Intel and others, and the increasing number of affordable SMP design
s) will naturally extend the operating system in terms of real-time performanc
e.  In addition, Microsoftˇs continued development of the Windows NT operatin
g system, including support of 64-bit architectures, will provide even further
performance advantages.  Over time, the niche-application driving forces for
modifying the Windows NT operating system will by degrees fade away.
A second evolutionary force critical to picking a good platform for soft contr
ol is the software maturation curve.  Soft control is in its infancy, and intr
oducing it into the highest-speed, most time-critical applications first, is s
imply not prudent.  Most of the current soft control discussions center on fac
tors that limit best-case performance.  However, at the state of product matur
ity in the marketplace these limits wonˇt be achieved.  The products need to
be field-tested and proven in a wide variety of applications before the pruden
t end-user will consider them for the most mission-critical applications.
Several vendors opted to collect one data point on the Windows NT operating sy
stem, present it out of context, and then claim that it is unacceptable for co
ntrol.  These vendors have now committed their R&D to a path of proprietary ex
tensions that will limit their ability to adopt standard Microsoft technologie
s.
Microsoft will soon introduce Wolfpack redundancy and clustering, and in the f
irst half of 1998, they will introduce OnNow technology with the Windows NT 5.
0 operating system.  This technology provides fast resume rebooting capability
, but is unlikely to work for a system that doesnˇt give the Windows NT opera
ting system access to all of its memory.  In addition, the Windows NT 5.0 oper
ating system will usher the next generation of Plug and Play (PnP), including
dynamic driver loading and removal and insertion under power (RIUP) for PCMCIA
, USB and FireWire devices.
It is very questionable whether a small vendor can keep pace with Microsoft in
the operating system marketplace. For instance one of the largest extension v
endors is a company of about 300 people however, and the majority of their rev
enue is derived from their hardware products. It is estimated that less than 2
0 people in this company are directly involved in the real-time extension proj
ect. It is key for these real-time extension vendors is to provide solutions t
hat build on, not around, the Windows NT operating system.
Other Areas for Improvement
Despite the many issues involved in extending the capabilities of the Windows
NT operating system, we still feel that there are many areas where real-time e
xtension vendors can add significant value.  We feel most of the vendors unfor
tunately have been myopically focused on deterministic control performance.  O
ther key issues impacting the use of the Windows NT operating system for soft
control include:
刋 simplifying software maintenance, both of the operating system and of the soft control system software
刋 speeding up boot times (Microsoft OnNow on the horizon)
刋 improving self-diagnostics
刋 supporting repair while running - removal and insertion under power, RIUP (Microsoft PnP for supports RIUP for USB, FireWire and PCMCIA)
刋 improving the mean-time-to-repair (MTTR) the system, by making the platform more of an appliance that can be swapped out (Microsoft�
 Zero Administration Windows [ZAW] is also trying to address this issue)

Summary
Vendors of real-time extension technologies and of control applications built
on these technologies have tried to represent the Windows NT operating system
as not being appropriate for soft control applications.  Based on our testing
and experience, we feel that the standard Windows NT operating system is adeq
uate for a wide variety of soft control applications, and we feel it is highly
preferable over less compatible, lower-volume options available from the real
-time extension vendors.
Though improvements beyond the current level of  performance are desirable fo
r some applications, extension technologies that push the Windows NT operating
system beyond its limits tend to be:
刋 Immature
刋 Limited in their degree of integration with the Windows NT product
刋 Increase system complexity
刋 Raise longer-term concerns about support and reliability.
We believe these technologies will be of interest for niche applications requ
iring tighter deterministic control performance, if they demonstr

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