RealTime Systems

1
Real-Time Systems
Extensions on

• Microsoft Windows NT

2
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• RialtoNT.
• comparison

3
Real Time Extension General Architecture
4
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• 1. Background
• 2. Dreams Model
• 3. Overrun
• 4. Implementation
• RTX.
• Vassal.
• RialtoNT.
• comparison

5
Dreams

• Distributed Real-time Extensions with Application
  to Multimedia Systems
• Extend conventional operating systems to support
  distributed real-time applications
• Paradigm preserving

6
Key Paradigm Differences

• Multiple competing applications
• Temporal protection
• Absence of a priori knowledge
• Different kinds of applications
• Subsystems (servers)
• Interrupts
• Dynamic distribution

7
2. The Dreams Model

• Transient Periodic Processes
• Periodic Invocations
• Specified
• Period
• Deadline
• Execution Time

8
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• 1. Background
• 2. Dreams Model
• 3. Overrun
• 4. Implementation
• RTX.
• Vassal.
• RialtoNT.
• comparison

9
The Dreams Model
9
10
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• 1. Background
• 2. Dreams Model
• 3. Overrun
• 4. Implementation
• RTX.
• Vassal.
• RialtoNT.
• comparison

11
3. Overrun Concepts

• System guarantee
• A real-time task will receive its reserved
  resources between each invocations start-time
  and deadline
• A task which consumes its reserved capacity
  without completing has overrun
• Only overrun tasks can miss their deadlines
• Task continues in overrun state
• Overrun tasks receive refreshed resources at the
  start of their next period

12
Scheduling and Overrun
Waiting
Invocation Completion
Invocations Start Time
Scheduled Thread
Runnable
Invocation Overrun
Overrun Try
Overrun
Overrun Leave
12
13
Sample Schedule
Process Period Reservation Av. Execution
Time first scheduled T1 100 20
20 70 T2 250 110
100 70 T3 1000 440
400 480
. 10ms
0 100 200 300
400 Time ID 01234567890123456789012345678901234567
890123456789 ---- 4500 1 .......RC........RC.....
...RC........RC........R1O 4500 2
.......SR2222222C...............R22222R22C........
4500 3 33333333........R3R333333333R3333........
R333333.R 5000 1 .......C.........R1O..RC...R1C.
......R1O..C....R1O 5000 2 .......R2222222C......
..........R22222.R22C....... 5000 3
33333333.......R33.R33C.........................SR
5500 1 .......C.........R1O.......C.........R1O
.......C.. 5500 2 .......R2222222C...............
.R22222.R22C....... 5500 3 33333333.......R33.R33
33333R33333.........R3333R33
Legend(S)tart(time) (R)un (scheduled)
(C)ompleted (O)verrun Multiple
14
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• 1. Background
• 2. Dreams Model
• 3. Overrun
• 4. Implementation
• RTX.
• Vassal.
• RialtoNT.
• comparison

15
4. Implementation

• Windows NT implementation
• Minimal impact on
• Non-real-time execution
• Existing operating system code
• Programming paradigm

16
Dreams Client
Win32 Client
Applications
Protected subsystems (servers)
Dreams Subsystem
Win32 Subsystem
User mode
Kernel mode
Executive
System services
I/O manager
Virtual Memory Manager
Security Reference Monitor
Local Procedure Call
Object Manager
Process Manager
File systems
Cache manager
Device drivers
Kernel
Network drivers
Hardware abstraction layer
Message Passing / Shared Memory
System Trap
16
17
Dreams Subsystem Memory Space
Dreams Client Application Memory Space
Reservation Manager
Application Process
Real-Time Thread Manager
API Call
Dreams DLL
Procedure call via named pipes
Blocking Access
Non real-time priority
Shared Data Area Requests / Process Table
Create Thread
Real-time priority
Non blocking access
Real-Time Thread
Real-Time Scheduler Enforcer
Non blocking communication
API Call
Periodic Invocation
Dreams DLL
Shared Memory
Kernel Call
Window NT Kernel
Scheduling via NT Priority Control
Kernel Mode Dreams
17
18
Implementation Experience

• Dreams extensions in a subsystem
• Meet implementation goals
• Simpler development, modification, and testing
• Priority inheritance
• Useful in all operating systems (not just
  real-time)
• Performance improvement
• Two tiered scheduler (with priority inheritance)
• Hides scheduling complexities
• Simpler scheduling
• Simpler schedulability model
• Simpler timing and enforcement

19
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Introduction.
• RTX Features.
• RTX architecture.
• Conclusion.
• Vassal.
• RialtoNT.
• comparison

20
RTX The Real-time Extension

• Adds a real-time sub-system (RTX) to Windows XP
• Independent RTX thread scheduler runs ahead of
  all Windows XP interrupt, DPC and thread
  processing
• Provides high-speed and deterministic RTX
  response times
• Worst-case IST jitter of 22 ?s (8 ?s on dedicated
  MP systems)
• No changes to Windows Kernel, HAL or device
  drivers
• Real-time HAL extender for interrupt isolation,
  fast timers, and kernel STOP interception
• RTX supports RtWinAPI calls and Visual Studio IDE

21
RtWinAPI The Real-time API

• Defines a common Real-time Windows-based API
• Supports real-time applications and device
  drivers
• Same on ETS, Windows CE, and Windows XP with RTX
• Uses Microsoft C/C compiler and runtime
  libraries
• Carefully selected set of 200 Win32 calls
• Most useful calls that provide the best real-time
  performance
• Multi-process, multi-thread and Dynamic Link
  Libraries (DLL)
• IPC, File IO and full Structured Exception
  Handling (SEH)
• Device Management
• Thread-based interrupt management with auto
  interrupt masking
• Bus enumeration, bus-mastering DMA and port IO
  support

22
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Introduction.
• RTX Features.
• RTX architecture.
• Conclusion.
• Vassal.
• RialtoNT.
• comparison

23
Key RTX Features

• RTX applications
• Can start early during booting (seconds after
  logo screen)
• Can be notified and continue after a Windows STOP
  (blue screen management)
• Provides IPC between Win32 and RTX processes
• 128 priority levels per-thread selectable time
  quantum
• Works with Windows Power Management and PnP
• ACPI, MPS and Standard PC platform support
• MP support (dedicated or shared RTX processor)

24
An Additional Scheduler Benefit in term of
Reliability !

• Continued Execution under Most Conditions
• System Loading will NOT Effect Operation
• Hard Disk Failures will NOT Effect Operation
• NT Peripheral Failures will NOT Effect Operation
• RTX Offers a Mission Critical Environment
  Combined with the Open and Infinitely Variable
  Capabilities of Windows NT Embedded

25
Security and Reliability Add-ons

• Blue Screen Management
• Software Watchdog
• Emergency Mode
• Blue Screen Management RT TCP/IP
• High Speed Redundancy
• Writing easily any driver
• Easy Design!
• Real time timer
• ..

26
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Introduction.
• RTX Features.
• RTX architecture.
• Conclusion.
• Vassal.
• RialtoNT.
• comparison

27
RTX Architecture

Real-time process 1
Real-time process N
Win32 Process with RTX IPC
Win32 Process
RtWinAPI
RTX.DLL
Windows XP Kernel and Device Drivers

Win32 Subsystem
TCP/IP DLL
DCX DLL
RTX Driver
LPC
RTX RTSS (RtWinAPI)
Windows HAL
RTX Real-time HAL Extender
IA32 PC UP or MP Hardware Platform
28
RTX Architecture
29
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Introduction.
• RTX Features.
• RTX architecture.
• Conclusion.
• Vassal.
• RialtoNT.
• comparison

30
RTX Conclusion

• RTX provides the basis to dramatically improve
  the reliability of your systems
• By combining the Blue Screen Management API, our
  additional independent scheduler, and our
  Real-Time TCP/IP stack, a lot of solutions are
  available depending on your needs
• Software Watchdog, Emergency Mode, High Speed
  Redundancy,
• RTX helps the development with simple design

31
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

32
Windows NT Scheduling

• Schedulable unit thread
• Priority-based thread scheduling
• Two policies, in distinct priority ranges
• Variable (dynamic priority round-robin)
• Real-Time (fixed priority round-robin)

33
NT Scheduling Precedence

• 1. Interrupts
• 2. Deferred Procedure Calls (DPCs)
• 3. Threads

• Not all time gets scheduled based on priorities
• Scheduling predictability is limited

34
NT Scheduling Events

• Scheduling decisions triggered by
• End of thread quantum
• Priority or affinity changes
• Transition to Wait state
• Wakeups

35
Windows NT Timers

• Hardware Abstraction Layer (HAL) provides kernel
  with a periodic timer
• Resolution selectable from 1 to 15 ms (default
  10 or 15 ms)
• Not all HALs implement all values
• MP HAL provides 1, 2, 4, 8, 16 ms
• Some HALs just implement 10 ms

36
Separate Policy from Mechanism

• NT scheduler thread dispatcher with scheduling
  policies interspersed
• Vassal separate scheduling and dispatching
  modules
• Schedulers policy modules that decide which
  threads to run
• Dispatcher runs threads selected by schedulers

37
Details of Present Prototype

• Standard NT policies remain in kernel
• Schedulers are in a hierarchy
• Give loaded scheduler first choice
• Ask native scheduler if loaded scheduler makes no
  choice
• Could easily support deeper hierarchy
• By default, threads use NT policies

38
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

39
Vassal Entities

• Schedulers
• Register decision making routines with dispatcher
• Dispatcher
• Invokes decision routines when scheduling events
  occur
• Threads
• Communicate with schedulers to request services

40
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

41
Vassal Architecture
Hardware Abstraction Layer (HAL)
Drivers
42
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

43
Windows NT Kernel Changes

• Added 188 lines of C code
• Added 61 assembly instructions
• Replaced 6 assembly instructions

44
Writing a Scheduler

• Proof-of-concept real-time scheduler
• 116 lines of C code
• No assembly language
• Only need to code the policy

45
Interface Modifications

• Extend driver interface for schedulers
• RegisterScheduler
• SetSchedulerEvent
• Extend syscall interface for threads
• MessageToScheduler

46
Registering a Scheduler

• RegisterScheduler(scheduler identifier,
• decision making routine,
• message dispatcher
• routine)

• Invoked by driver at initialization time
• Dispatcher checks for conflicts and updates
  scheduler hierarchy
• Dispatcher queries scheduler by invoking the
  decision making routine

47
Communicating with a Scheduler

• MessageToScheduler (scheduler identifier,
• message buffer,
• message length)

• Thread sends message to specific scheduler
• Corresponding schedulers message dispatcher
  extracts message from buffer and responds

48
Precisely Timed Events

• SetSchedulerEvent (scheduler identifier,
• absolute time value)

• Scheduler requests control of CPU at certain
  absolute time
• Dispatcher invokes schedulers decision routine
  at specified time

49
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

50
Vassal Interfaces
Application Thread
User space
MessageToScheduler
External Scheduler
Thread Dispatcher
RegisterScheduler
Kernel
SetSchedulerEvent
Hardware Abstraction Layer (HAL)
Drivers
51
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

52
Execution of Sample Code
T
53
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

54
Context Switch Times
Context switch times on original and modified
systems (µs, P-133)

• No significant difference when external
  schedulers not loaded
• 8 overhead on untuned prototype when using
  loaded schedulers

55
Periodic Wakeup Times
Wakeup times using multimedia timers on vanilla
system and sample scheduler on Vassal (µs,
P-133). Desired value is 1000.

• No early wakeups when using our scheduler
• Predictability significantly improved
• Believe late samples due to unscheduled activities

56
Vassal Take-Home

• Demonstrates viability and effectiveness of
  loadable schedulers
• Frees OS from anticipating all possible
  application scheduling requirements
• Encourages scheduling research by making it easy
  to develop and test new policies
• Insignificant performance impact

57
Limitations and Future Work

• Timing precision limited by HAL
• Predictability limited by interrupts and DPC
  activity
• Only one loaded scheduler supported
• External schedulers not fully MP aware

58
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• Introduction.
• Entities.
• Architecture.
• Modifications.
• Interfaces.
• Sample Code.
• Context Switch Times.
• Related Work.
• RialtoNT.
• comparison

59
Related Work

• Solaris scheduler class drivers
• Must map scheduling decisions onto global thread
  priority space
• Extensible OS work
• Spin, Exokernel, Vino
• Hierarchical schedulers
• Utah CPU inheritance scheduling
• UIUC Windows NT soft real-time scheduler

60
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• RialtoNT.
• Introduction.
• Rialto Background.
• Windows NT Implementation.
• Performance and Traces.
• Related Work and Conclusions.
• comparison

61
What We Did

• Created Rialto/NT
• Based on Windows 2000
• Added CPU Reservations Time Constraints
• Abstractions originally developed within Rialto
  real-time system at Microsoft Research
• Whats new
• Coexistence with Windows NT scheduler
• Multiprocessor capability
• Periodic clock
• As opposed to fine-grained individually scheduled
  interrupts

62
Real-Time

• Real-time computations have deadlines
• Examples
• Fly-by-wire aircraft
• Missed deadline may endanger the aircraft
• Soft modem
• Missed deadline may reset the connection
• Video conferencing
• Missed deadline degrades audio or video quality

63
Why not use Windows NT as is?

• Real-time using priorities requires global
  coordination
• Windows is an open system
• Priority inflation
• No path for timing information
• There are scheduling algorithms that do not
  require global coordination
• CPU Reservations and Time Constraints
• Apps state timing requirements directly
• Independently developed apps can run concurrently

64
Teaser Capability

• Apps can ask scheduler
• Can I do 5ms of work betweennow30ms and
  now40ms?
• Scheduler answers either
• I guarantee it or
• You probably cant
• Guaranteeing this 5ms work in future 10ms
  interval does not require reserving 50 of CPU
  for next 40ms

65
How did we do it?

• Explicitly represent future time
• Map app declarations of timing needs into grants
  of future time

• Enables
• Advance guarantees to applications, or
• Denial of requests up front

66
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• RialtoNT.
• Introduction.
• Rialto Background.
• Windows NT Implementation.
• Performance and Traces.
• Related Work and Conclusions.
• comparison

67
Abstraction CPU Reservation

• Guaranteed execution rate and granularity for a
  thread
• X units of time out of every Y units, e.g.
• 1ms every 5ms
• 7.5ms every 33.3ms
• one second every minute

68
Abstraction Time Constraint

• Deadline-based thread execution
• Guarantees execution within interval, or
• Proactively denies constraint request

schedulable BeginConstraint (time_interval,
estimate) if (schedulable) then Do normal work
under constraint else Transient overload -- shed
load if possible time_taken EndConstraint ()
69
Implementation Precomputed Scheduling Plan

• Tree-based periodic map of time
• Supports widely varying periods
• Allocation of future time intervals
• Ongoing for CPU Reservations
• One-shot for Time Constraints
• Enables efficient
• Scheduling decisions
• Feasibility analysis for constraints
• Guarantees for reservations, constraints

70
Scheduling Plan Example
71
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• RialtoNT.
• Introduction.
• Rialto Background.
• Windows NT Implementation.
• Performance and Traces.
• Related Work and Conclusions.
• comparison

72
Using the Windows NT Scheduler

• Rialto/NT uses existing priority scheduler to
  schedule its threads
• Rialto/NT elevates thread priorities to cause
  dispatching
• Existing apps, abstractions work as before
• Windows NT scheduler also can schedule Rialto/NT
  threads

73
Multiprocessor Issues

• One scheduling plan per processor
• Tree walking happens on all plans
• Heuristic add new reservation to plans in
  increasing order of processor utilization
• Plans not pinned to particular CPUs
• Allow NT scheduler to choose CPU
• Rely on schedule properties, affinity to run
  threads mostly on same CPU
• Permits opportunistic scheduling on other
  processors by existing scheduler

74
Affinity vs. Priority

• Rialto/NT counts on priority elevation to cause
  thread dispatching
• No contention because at most one elevated
  (Rialto/NT) thread per CPU
• On MP highest priority threads not always
  scheduled
• Heuristics sometimes elevate thread affinity over
  thread priority
• Changed scheduler to immediately dispatch
  Rialto/NT elevated-priority threads when ready

75
Discrete Time

• Windows NT clock interrupts on periodic basis
• Typically 10-15ms, HAL-dependent
• Can usually be set to 1ms period
• Discrete interrupts limit enforceable scheduling
  granularity
• So, Rialto/NT
• Initializes interrupt period to 1ms
• Aligns rescheduling with clock interrupts

76
Implementation Details

• Reschedule runs in DPC context
• Use NT kernel timers to schedule DPCs
• Rialto/NT threads run at priority 30
• Second highest Windows NT priority
• Other values could be chosen
• New plans for reservations computed in requesting
  thread context
• Optimistic concurrency control to avoid
  perturbing existing schedule

77
Non-invasive Implementation

• Easier to argue correctness
• Modified only two kernel routines
• Changed behavior of one
• Added to the kernel
• 6000 lines of C
• 4 system calls

78
Complication Unpredictable Dispatch Latency

• When latency occurs we
• Penalize the running thread
• Keep the schedule on time
• Causes of scheduling latency
• Interrupt handlers
• Kernel code running at high IRQL
• Long DPCs
• Latencies controllable through concerted latency
  testing discipline

79
Better Living Through Simulation

• Rialto/NT runs in simulator in addition to kernel
• Exactly the same sources
• Makes some debugging much easier
• Reproducible runs
• Better tools
• No race conditions
• Reboot time not in critical path

80
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• RialtoNT.
• Introduction.
• Rialto Background.
• Windows NT Implementation.
• Performance and Traces.
• Related Work and Conclusions.
• comparison

81
Test Platform

• 333 MHz Pentium II PCs
• 128MB RAM
• Intel EtherExpress Pro
• Adaptec SCSI
• Single- and dual-processor

82
Context Switch Time

• Tested
• 10 threads on released Windows 2000 beta 3
• 10 Rialto/NT threads with CPU Reservations
• Rialto/NT adds 8µs to median context switch time
• 0.8 overhead at 1ms scheduling granularity

83
Time to Acquire Reservations

• Reasonable even in pathological cases

• Times to begin simultaneous reservations

84
Time to Acquire Constraints

• Reasonable even in pathological cases

• Times to begin simultaneous constraints

85
Reservations with a Background Thread

• Threads run only during time assigned to their
  reservations

• 1 processor, 3 threads with reservations, 1
  high-priority competitor thread

86
Reservations and Constraints

• Thread 3 gains additional time with constraints

• 1 processor, 3 threads with reservations (one
  also using constraints), 1 high-priority
  competitor thread

87
Dual Processor Traces

• Without affinity change thread 3 not always
  scheduled

• With affinity change all threads properly
  scheduled

88
Context Switch Time

• Adds 8µs to median at most 0.8 overhead

• Rialto/NT vs. native context switch times

89
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• RialtoNT.
• Introduction.
• Rialto Background.
• Windows NT Implementation.
• Performance and Traces.
• Related Work and Conclusions.
• comparison

90
Related Work

• Real-time add-ins for Windows NT
• RTX from VenturCom, INtime from RadiSys,
  Hyperkernel from Imagination Systems
• Lin et. al 98
• Windows NT soft real-time scheduling server
• Candea Jones 98
• Vassal loadable scheduler framework
• Lots of reservation- and deadline-based
  scheduling work

91
Further Research

• Evaluate when applied to real apps
• Add activity abstraction
• Reservation shared among threads
• Gang scheduling
• Lots of policy issues
• Resource management
• Placement of reservations among CPUs

92
Conclusions

• Scheduling plan effective on MPs
• Plan adapted to use periodic clock
• New scheduler cooperatively coexists with, uses
  Windows NT scheduler
• Rialto/NT brings CPU Reservations and Time
  Constraints to Windows NT

93
Index

• Real Time Extension
• - General Architecture
• Extensions
• Dream.
• RTX.
• Vassal.
• RialtoNT.
• comparison

94
real-time extensions comparisonRTX vs. Win32
shows the execution time and speed of system
calls related to semaphore, RtReleaseSemaphore
and RtWaitForSingleObject on RTX, and
ReleaseSemaphore and WaitForSingleObject on
Win32. The upper value is the execution cycles of
the call per second while the lower value is the
execution time of the call. The result shows the
speed of the call on RTX is three times and more
faster than that on Win32. This is a great
advantage of RTX.
95
real-time extensions comparisonRTX vs. Win32
compares the above result with other
results.RTPC-604 is PowePC604 100MHz (512KB L2
cache) with LynxOS2.4. The value is a total time
of the Lock and Unlock. VMIC has the same
frequency of CPU as RTPC-604. The Dhrystone value
of RTPC-604 is 208,000 while that of VMIC on
Win32 is 186,000. The integer performance of
RTPC-604 is slightly faster than that of VMIC
while the single process speed of RTPC-604 is
also slightly faster than that of VMIC on Win32.
However, the single process on RTX is twice and
more faster than that on RTPC-604.
96
real-time extensions comparisonRTX vs. Win32
thread switching speed
The thread switch occurs twice per loop. So, the
execution time of Lock and Unlock includes thread
switching time in this case. The thread switching
time and speed can be calculated because the
execution times of Lock and Unlock were already
measured. From the results, the execution speed
including thread switch is linear to the
frequency of CPU on RTX and Win32. And, the speed
on RTX was about 50 faster than that on Win32.
However, the thread switching speed on RTX was
slower than that on Win32 in both PC and VMIC.
This is an interesting point.
97
real-time extensions comparisonRTX vs. Win32
Process switching
process switching speed between Win32 and RTX was
very slow. Thus, the communication is not
efficient
98
real-time extensions comparisonRTX vs.
Win32Semaphore ping-pong time
When DAQ programs communicate with each other,
the total time of Lock and Unlock with thread
switch, that is, ping-pong time is important from
view point of the performance. Even if the thread
switching time on RTX was slower than that on the
LynxOS, the ping-pong speed on RTX was faster
than that on the LynxOS. Dhrystone represents
integer performance. The performance of system
call is not linear to that of Dhrystone according
to the result. Namely, the results show Dhrystone
is not index to performance of the system call.
99
performance metrics for Windows XP with RTX 5.1
running on a 800 MHz Pentium III processor with
an ACPI compliant chipset.
100
real-time extensions comparison