1.96k likes | 2.17k Views
OS: the state of the art. Module 2 Scheduling and memory management. Content of module 2. Introduction: what is an operating system RTOS architectures Scheduling Memory Management Conclusions. Documentation. This presentation Evaluation reports http://www.dedicated-systems.com
E N D
OS: the state of the art Module 2Scheduling and memory management
Content of module 2 • Introduction: what is an operating system • RTOS architectures • Scheduling • Memory Management • Conclusions
Documentation • This presentation • Evaluation reports • http://www.dedicated-systems.com • This course website • http://vub.dedicated-systems.com • Username: vubuser • Code: vubdse1!
OS: a definition • GENERAL PURPOSE OS (GPOS): • A GPOS is a collection of programs that acts as an intermediary between the hardware and its user(s), providing a high-level interface to low level hardware resources, such as the CPU, memory, and I/O devices.
GPOS: PURPOSE • To provide an environment with facilities and services that make the use of the hardware • Convenient • Efficient • Safe • Secure • Sharing of resources among users and/or programs
GPOS: facilities & services • Memory management • Process management • Communication facilities • A command language interpreter or GUI • A file system • ....
Response requirements Protection Requirements OS TYPES In 1980 off-line batch remote batch user- Program-mable on-line Timesharing personal computing data-base real-time non- Program-mable multi-user single-user
Mainframes Migration of OS concepts and features 1940 1950 1960 1970 1980 1990 2000 MULTICS no compilers time software shared multi-user batch resident monitors distributed systems UNIX Minicomputers no compilers time software shared multi-user resident monitors UNIX Microcomputers no compilers interactive software multi-user resident . monitors .
GPOS - RTOS • GPOS • Multiple applications on one system • Maximum resource usage • Average performance is important • RTOS • A single application on a system • Reliably • Predictability = time constraints on individual events
Real-Time OS: too many or too few? • An enormous quantity of RTOS are available today • Free – commercial – with/without source – experimental… • Some are competitive, others are complementary • The miss-choice of an RTOS may have dramatic results on a project
AMX (KADAK) CExecutive (JMI) CHORUS (Jaluna C5) CX/UX (HARRIS) eCos FlexOS (NOVELL) iRMX (Intel) LynxOS (Lynx) Linux flavours OSE (ENEA DATA) OS9 (Microware) PDOS (Eyring Research) (pSOS+) (WindRiver) QNX (QNX) Real/IX (Modcomp AEG) SPECTRA (VRTX) (Mentor Graphics) SMX (Micro Digital) SunOS (Sun) Symbian VXWorks (Wind River) Windows CE Windows XP embedded Some Embedded (Real-Time) OS
Thesis General purpose systems are migrating from mainframe to distributed Client-Server technologies. A Real-Time System is distributed by nature and is using this technology for some years already. Real-Time & General Purpose OS technology is melting together.
Scenario for the presentations (1) • What are the requirement for a good RTOS? Requirement
Scenario (2) • Examples: • Of real product situations • Some examples show product problems which are in most cases resolved by now • In new release • Except for NTe – XPe – Linux (because non RT!)
evaluation test platform • Pentium 200 MMX • Reference platform • Not really an embedded processor • Is faster than most embedded processors • PPC • ATX platform with MPC7410 PPC 400 MHz • ARM9 • ATX module: Integrator AP/CM920 T • Hardware logic analyser for measurements (10 ns resolution) • No tricks with on-boards timers • No resolution problems with these timers
Test examples • Platform calibration • To compare results with different processors • Performance measurements • Thread creation, switching, deletionInterrupt latencies under load conditions Semaphore/mutex creating, release,.. • Behaviour • Queues: Task/thread, Semaphore/mutex • Application simulation • Endurance tests
Test procedure • Starttime: Before starting an OS call write a trace to PCI bus – capture with (PCI) analyser • Start the call • Stoptime: At the end of the call – write again a trace to the PCI bus – capture with analyser • Do this as many times as possible – limited to the size of the analyser trace buffer • Do the same test in different circumstances • No other activity • A lot of other activity (processor load) • Event = system activity between start and stop • Eventtime = stoptime - starttime
Measurements:sample diagram All public tests on 200 MHz Pentium MMX motherboard platform
Good RTOS – REQ: OS structure A good RTOS needs a Client/Server architecture
OS STRUCTURE • Simple or monolithic structure • Layered Approach • Client/Server model
Software Layers (1) Applications Implemented in software System software Hardware
The RT way Applications System software Hardware
Software Layers (2) Applications Language translators Operating system Utility Programs System software Hardware
Software Layers (3) Applications Language translators Operating system Utility Programs System software Hardware Command interpreter Long-term scheduler Resource manager Short-term scheduler File manager I/O system Memory manager Kernel
Monolithic OS Application Program Application Program . . . User Mode Kernel Mode System Services Operating System Procedures Hardware
Client/server OS = REQ Client Application Memory Server Network Server Process Server File Server Display Server User Mode Kernel Mode Microkernel Send Hardware Reply
Client/server OS: advantages • OS components are small and self-contained • a single server may fail and be restarted (user mode) without corrupting the rest of the OS • different servers may run on different processors = easy distributed environments
Client/server examples • New approach • Chorus (now Jaluna C5) (EU) • QNX neutrino = QNX 6.x (CANADA) • VxWorks 6.x ??? (US) • Inherent (old) approach • OSE (EU) • VXWorks 5.x (US) • VRTX (US) • - ..
Good RTOS – REQ:OS architecture Whatever architecture is used, it should be clearly documented and published.
Example of different architectures • Basic NT architecture • RTX • INTIME
thread thread NT-Kernel I/O Mgr Dev.Dr. HAL Hardware Simplified Basic NT architecture process process process process thread thread Win32 Win32 Win32 Win32
thread thread NT-Kernel I/O Mgr Dev.Dr. RTX - our view process process thread thread RING 3 process process Win32 Win32 RT-API RING 0 RT-API RT-API scheduler HAL Timer - irq handling Hardware
thread thread NT-Kernel I/O Mgr Dev.Dr. INtime - our view process process process process thread thread RING 3 process process RT-API RT-API Win32 Win32 NTX scheduler NTX driver NTX driver RING 0 HAL Timer - irq handling Hardware MEM
M2c: Processor(s) Management Single processor issues • Scheduling in general • A simple introduction to OS-scheduling • Scheduling for RT-Systems Multiple processor issues (later – Module x)