XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 69 Návrh a realizace úprav zvyšující determinovatelnost zpracování zvoleného požadavku IRQ v MS Windows NT/2000/XP využívající obvody PIC-8259A FOJTÍK, David, Ing., Katedra ATŘ-352, VŠB-TU Ostrava, 7. listopadu, Ostrava - Poruba, 708 33 david.fojtik@vsb.cz, http://fs.vsb.cz/~foj74 Abstrakt: Operační systémy MS Windows NT/2000/XP definují vlastní prioritní uspořádání požadavků IRQ, které nejsou na počítačích používající řadiče PIC (8259A) hardwarově realizovatelné a tudíž vyžadují softwarové řešení. Toto řešení je mírně odlišné mezi operačním systémem MS Windows NT a novějšími systémy MS Windows 2000/XP. Obě řešení však vždy shodně mapují tentýž požadavek IRQ s patřičnou úrovní IRQL, na které je pak vykonána jeho obsluha. Problémem však nastává v okamžiku kdy nám toto uspořádání nevyhovuje například z důvodu potřeb zpracovávat určitý požadavek IRQ přednostně před ostatními takzvaně v reálném čase. Příspěvek se zabývá návrhem a realizací možných zásahů do prioritního uspořádání těchto systému tak, aby konkrétní požadavek IRQ by mohl být vykonán přednostně před ostatními. Návrh vychází z detailní znalosti softwarové správy a byl ověřen sadou měření jejíž výsledky jsou také součástí příspěvku. Klíčová slova: PIC, 8259A, MS Windows NT/XP/2000, IRQ, IRQL Důvody a cíle navrhovaných úprav Operační systémy MS Windows NT/2000/XP definují vlastní prioritní uspořádání požadavků IRQ, které nejsou na počítačích používající řadiče PIC (8259A) hardwarově realizovatelné a tudíž vyžadují softwarové řešení. Toto řešení je mírně odlišné mezi operačním systémem MS Windows NT a novějšími systémy MS Windows 2000/XP. Obě řešení však vždy shodně mapují tentýž požadavek IRQ s patřičnou úrovní IRQL, na které je pak vykonána jeho obsluha. Problémem však nastává v okamžiku kdy nám toto uspořádání nevyhovuje například z důvodu potřeb zpracovávat určitý požadavek IRQ přednostně před ostatními takzvaně v reálném čase. Příkladem může být použití obsluhy přerušení jako softwarového regulátoru, kde vzorkovací perioda je zajištěna hardwarově periferním zařízení (multifunkční měřící karta s časovači), které přesně opakovaně generuje požadavky na přerušení. Připojíme-li požadavek na řízení v reálném čase ihned vzniká potřeba poupravit prioritní uspořádání a správu požadavků aplikovanou uvedenými operačními systémy. V příspěvku Správa požadavků na přerušení v MS Windows NT/2000/XP využívající obvody PIC-8259A je proveden rozbor interního mechanizmu správy přerušení včetně zhodnocení z pohledu systémů reálného času. Z příspěvku vyplývá potřeba určitých modifikací systému ke zkvalitnění determinovatelnosti správy a to především v MS Windows NT. Jelikož nelze bez zdrojových textů a práv měnit standardní chování systému (a to také není cílem), je nutné nalézt skulinky v systému, kterými je možné obsluhu přerušení vylepšit bez přepracování jádra tak, aby lépe vyhovoval našemu účelu.
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 70 Jak již bylo uvedeno, mají jednotlivé vstupy IR přiřazeny určité priority tzv. úrovně IRQL (viz tabulka ). Z těchto vstupů má nejvyšší úroveň IRQL přerušení časovače (IRQL 28), následován přerušením klávesnice (IRQL 26) a podřízeného obvodu. Tato zařízení mají pěvně přidělen vstup IR a tudíž kanály IR0, IR a IR2 není možné použít pro vlastní účely. Prvním volitelným kanálem, který je možné uživatelsky využít je až vstup IR3, který je standardně používán sériovými porty COM2/COM4. Máme-li měřící kartu, která umožňuje generovat přerušení IR3, lze tak standardním způsobem získat pro žádanou obsluhu úroveň přerušení IRQL 24. IRQL IRQ Popis 3 - Kritická chyba HW 30 - Výpadek napájení 29 - Přerušení pro víceprocesorovou synchronizaci 28 0 Přerušení časovače 27 - Profily 26 Klávesnice 25 2 Výstup INT podřízeného řadiče. 24 3 Sériové rozhraní COM2/COM4 23 4 Sériové rozhraní COM/COM3 22 5 Rezervováno/Zvuková karta 2 6 Disketová mechanika 20 7 Paralelní port 9 8 Hodiny reálného času 8 9,2 Původní IRQ2 nebo IRQ9 7 Rezervováno 6 Rezervováno 5 2 PS/2 Myš 4 3 Matematický koprocesor 3 4 Hard Disk 2 5 Rezervováno 4- - Nepoužité priority 3 - SW přerušení pro ladící účely 2 - SW přerušení pro DPC - SW přerušení pro APC 0 - SW úroveň přerušení, na které běží veškeré aplikace Win32 Tab. : Vztah mezi úrovněmi IRQL a žádostmi IRQ na počítačích s řadiči PIC Z našeho pohledu je však tato úroveň nedostačující, neboť jak vstup z klávesnice tak také přerušení časovače by neměl regulační algoritmus ovlivňovat. Také ne vždy máme k dispozici uvedený kanál, nebo měřící kartu, jenž tento kanál umí využít. Shrneme-li informace z příspěvku Správa požadavků na přerušení v MS Windows NT/2000/XP využívající obvody PIC-8259A doplníme-li je o zmíněný problém, dostaneme souhrn požadavků, které je nutno vyřešit:. Prvním požadavkem je nalézt způsob, jak přidělit obsluze jinou vyšší prioritu IRQL nežli tu, která je přidělena automaticky systémem (pro náš případ nejlépe na hodnotu IRQL 3).
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 7 2. Jak zajistit, aby rozpor mezi hardwarovou prioritou IR obvodu 8259A a softwarovou prioritou IRQL nezpůsoboval oddálení vykonání námi zvolené obsluhy v případě současného vzniku přerušení od dvou zdrojů. 3. U operačního systému MS Windows NT je také třeba zajistit, aby námi zvolená obsluha nemohla být přerušena jakýmkoliv jiným zdrojem IR, byť pouze na dobu vyhodnocení úrovně priority jako je tomu u standardního chování systému. 2 Návrh a realizace úprav 2. Přiřazení vlastní úrovně IRQL Každé obslužné rutině ISR je při její registraci systémem přidělena IRQL úroveň podle tabulky. Na této úrovni je pak daná obsluha vykonána. Vlastní registrace se ve Windows NT [MICROSOFT 998A] provádí ve dvou krocích:. mapování vektoru přerušení pro zvolený vstup IR, při kterém je systémem navrácena IRQL úroveň, 2. napojení obslužné rutiny ISR k získanému vektoru přerušení. MappedVector = HalGetInterruptVector(Isa, // Interface type 0, // Bus number irq, // Bus interrupt level irq, // Bus interrupt vector Systémem přidělená úroveň IRQL ); &irql, // IRQ level &Affinity // Affinity mask ioconnectstatus = IoConnectInterrupt( &extension->interruptobject,//interrupt Object LPTInterruptServiceRoutine, //Interrupt Service Routine extension->deviceobject, //Device Object NULL, //SpinLock MappedVector, //Mapped Vektor irql, //System IRQL RunIrql, //SynchronizeIrql Latched, //InterruptMode (is LevelSensitive or Latched) Skutečná úroveň FALSE, //ShareVector IRQL, na které Affinity, //ProcessorEnableMask obsluha poběží. FALSE //FloatingSave (For X86 FALSE) ); Obr. : Mapování vektoru a připojení obsluhy přerušení s nastavením IRQL ve Windows NT V systému MS Windows 2000/XP [MICROSOFT 2000] odpadá první krok, neboť systém Plung And Play provádí veškeré registrace automaticky podle údajů uvedených ve vlastnostech ovladače (dostupné prostřednictvím Device Manageru). Ovladač tak již obdrží hotovou strukturu, ve které jsou všechny potřebné údaje předány. V kódu ovladače se pouze provede fyzické napojení obslužné rutiny ISR (funkce IoConnectInterrupt) shodně jakou u MS Windows NT.
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 72 Obr. 2: Nastavení kanálu přerušení IR a bázové adresy v MS Windows 2000/XP Systémové funkci, která zajišťuje napojení rutiny k danému vektoru přerušení, se kromě jiného předává získaná úroveň IRQL z předchozího mapování a současně také synchronizační úroveň IRQL. Zatímco první hodnota musí být shodná se systémem přidělenou úrovní, druhá hodnota může být i vyšší úrovně IRQL. Synchronizační úroveň IRQL je ve skutečnosti úrovní, na které obslužná rutina bude fyzicky zpracována. Původní význam synchronizační úrovně IRQL spočívá v tom, že umožňuje definovat různé úrovně IRQL pro případ existence několika obslužných rutin přiřazených jednomu kanálu IR, k čemuž dochází při současném sdílení kanálu IR několika fyzickými zařízeními (na sběrnici PCI zcela obvyklé). Pro náš případ je zajímavé, že tento parametr ovlivňuje úroveň, na kterém je fyzicky obsluha vykonána, a že tuto úroveň lze bez problému nastavit až na hodnotu 3. 2.2 Změna hardwarových priorit V příspěvku Správa požadavků na přerušení v MS Windows NT/2000/XP využívající obvody PIC-8259A je uvedeno, že obvod 8259A spravuje žádosti jednotlivých vstupů podle priorit v tzv. úplném módu vnoření. Implicitně má vstup IR0 nejvyšší prioritu a vstup IR7 nejnižší prioritu. Tyto priority lze však programově ovlivnit a to několika způsoby. V našem případě je nejvhodnější použít příkaz nastavení priority, kterým je možné zvolenému vstupu IR přiřadit nejnižší prioritu. Priority ostatních vstupů se pak uspořádají tak, aby tvořily souvislou řadu. Například, nastavíme-li na nejnižší prioritu vstup IR 2, získá vstup IR3 nejvyšší prioritu (viz obr. 3). IR IR7 IR6 IR5 IR4 IR3 IR2 IR IR0 Priorita 4 3 2 0 7 6 5 Nejvyšší Nejnižší Obr. 3: Stav interních priorit obvodu 8259A po nastavení nejnižší priority na kanál IR2
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 73 Programový kód nízkoúrovňového ovladače běží v módu jádra a tudíž může přímo přistupovat k hardware počítače. Je tedy možné přímým zápisem na obvod 8259A provést změny hardwarových priorit a v kombinaci s nastavením úrovně IRQL přiřadit konkrétnímu vstupu nejvyšší prioritu jak hardwarovou tak softwarovou. Vlastní kód upravující hardwarové priority obvodu 8259A je vhodné nelépe umístit do zaváděcí rutiny ovladače. 2.3 Zabezpečení obsluhy před nežádoucím přerušením ve Windows NT Přerušení prováděné obsluhy žádostí s nižší úrovní IRQL je problémem mechanizmu použitého v MS Windows NT. Ve Windows 2000/XP je činnost obsluhy s úrovní IRQL 3 prakticky nepřerušitelná (veškeré vstupy jsou maskovány). Zabezpečení obsluhy před přerušením od žádosti vstupu s nižší úrovní IRQL, lze dosáhnout dvěma způsoby:. ihned po zahájení obsluhy nastavit masku (registr IMR) přímo obvodu přerušení 8259A a po ukončení jej vrátit nazpět do původní podoby, 2. zamaskovat vstup procesoru INTR ihned v prvním příkazu obslužné rutiny. První metoda je poměrně komplikovaná a časově náročná, neboť vyžaduje provést nejprve čtení a uchování aktuální masky nejlépe obou kaskádově řazených obvodů. Následně pak provést zápis nové masky a po ukončení obsluhy ji nastavit zpět. Oproti tomu zamaskování vstupu INTR lze provést jednoduchou instrukcí procesoru (CLI) bez nutnosti uchovávat původní stav. Navíc nedochází ke komunikaci s obvodem a tudíž k přístupu na sběrnici, co je o poznání rychlejší. Jelikož systém chrání vlastní interní mechanizmy před nežádoucím přerušením také na úrovni vstupu INTR, není nutné v posledním kroku obsluhy nazpět vstup povolovat (instrukce STI), neboť ihned poté prováděna systémová část obsluhy maskování opět zavede. BOOLEAN LPTInterruptServiceRoutine( IN PKINTERRUPT Interrupt, IN OUT PVOID Context) { UCHAR ReadData; UCHAR WriteData; PDEVICE_OBJECT DeviceObject; PLPT_DEVICE_EXTENSION extension; asm CLI //Maskovani vstupu INTR Obr. 4: Počáteční část obsluhy přerušení s maskování vstupu INTR procesoru Aplikací uvedených postupů na systém využívající přerušení k přesnému časování periodických činností lze dosáhnout z pohledu reálného času kvalitnějších výsledků. Přesto však ani po této úpravě nelze uvést, že námi definovaný vstup IR je zpracováván v reálném čase. K tomuto závěru vede hned několik důvodů:. Nejsou známé doby trvání systémových funkcí jádra operačního systému a tudíž nelze předem vypočíst maximální limit, do kterého bude rutina po vzniku přerušení zahájena. 2. Výrobce systémů uvádí [MICROSOFT 998B], že v určitých blíže nespecifikovaných případech činnosti jádra je maskován vstup procesoru INTR a tudíž jsou veškerá přerušení zakázána. Doba, po kterou jsou přerušení maskována není opět nikde specifikována, pouze je uvedeno, že jsou velmi krátká. 3. Taktéž nelze vyloučit, že tytéž postupy neužívá některý standardní ovladač z dílen Microsoftu nebo třetích stran. Tomu také nasvědčuje chování systému ohledně hodin reálného času, kdy kanál IR8 v rozporu s ostatními běží na vyšší úrovni (IRQL 28) nežli by podle uspořádaní vstupů měl mít přidělenou. Navíc zařízení.není v případě činnosti s úrovní IRQL nižší než 28 nikdy maskováno. 4. Uvedené úpravy nevylučují vznik inverze priorit. To znamená, že při aplikaci uvedených úprav nelze vyloučit stav, kdy obsluha s nižší prioritou IRQL bude po dobu své činnosti blokovat žádost o obsluhu s vyšší prioritou IRQL. Tento problém vzniká
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 74 při hardwarovém maskování přerušení, kdy systém zamaskuje IR kanál, kterým jsou vznášeny požadavky s uživatelsky zvýšenou prioritou IRQL, jež by při standardním použití měly úroveň nižší. Důvodem je, že konkrétně použitá maska je na platformě x86 spravovaná jádrem operačního systému a vztahuje se vždy ke standardně definovaným úrovním IRQL. Jádro systému má tak ke každé možné úrovni IRQL pevně přiřazenou masku, která odpovídá stavu, jakoby všechny obsluhy používaly pouze úrovně přidělené systémem. Paradoxně je to především problém systému MS Windows 2000/XP, neboť je zde pro každou obsluhu vždy pevně aplikovaná maska na obvodu 8259A tudíž četnost vzniku inverze priorit je v přímo úměrná s velikostí rozdílu mezi standardní úrovní a úrovní zvýšenou. Oproti tomu MS Windows NT masku aplikuje až v okamžiku vzniku kolize. Obr. 5: Vznik inverze priorit v případě vlastní definice úrovně IRQL ve Windows NT Například pro MS Windows NT uveďme situaci (viz obr. 5), kdy je naše kritická obsluha zahajována přes kanál IR3, který má námi nastavenou nejvyšší prioritu a současně je obsluha zpracovávaná na úrovni IRQL 3. Dále předpokládejme situaci, kdy vznese požadavek o obsluhu časovač (vstup IR0, IRQL 28) a ihned poté vznese požadavek na přerušení klávesnice (vstup IR, IRQL 26). Jelikož obsluha klávesnice běží na nižší úrovni IRQL nežli časovač, systém shodně s uvedeným postupem zamaskuje všechna přerušení na úrovni IR0 až IR7, pozastaví obsluhu klávesnice a opět předá chod obsluze časovače. Od této chvíle až do konce obsluhy časovače je hardwarově maskován vstup IR3 a tudíž naše obsluha, která má úroveň IRQL 3 je blokována obsluhou s úrovní IRQL 26. Teprve poté, co je obsluha časovače dokončena jsou opět přerušení povolena a tudíž systém vyhodnotí, že naše žádost má vyšší prioritu IRQL a zahájí její zpracování přednostně před obsluhou klávesnice. Na první pohled je řešení problému zcela jednoduché. Stačí upravit používanou masku tak, aby námi zvolený kanál nebyl nikdy maskován obdobně jako tomu je u hodin reálného času. Problém však je, že na platformě x86 je správa masky řešena na úrovni jádra operačního systému a není žádným způsobem programovacími prostředky zpřístupněná. Jediným možným způsobem tak zbývá modifikace jádra, co opět vyžaduje nedostupné zdrojové texty operačního systému. Přes uvedené problémy jsou tyto úpravy vzhledem k našemu problému zjevně pozitivní a to především u MS Windows NT. Nejlépe to vystihuje výsledek měření,
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 75 který porovnává dobu odezvy systému na vznik přerušení se standardním systémem obsluhy a s upraveným systémem. 3 Ověření navržených úprav Vlastní ověření spočívá v porovnání souborů naměřených dob odpovědí na systému používající neupravený a poté upravený mechanizmus správy přerušení (princip měření byl publikován [FOJTÍK, D. 2003]). K zdárnému porovnání je nutné naměřené hodnoty získat za shodných podmínek, kdy měřený systém je pro obě sady souborů shodně zatěžován. Konkrétně použitý měřený systém lze po hardwarové stránce charakterizovat takto: CPU Pentium 90MHz, Hard disk o kapacitě 4GB připojený přes SCSI řadič na PCI sběrnici (IRQ), 64 MB RAM, CD ROM 4x, připojený přes rozhraní ID (IRQ4) myš připojená přes standardní sériové rozhraní COM (IRQ4). K měření byly použity speciální ovladače paralelního portu (IRQ7) postupně nainstalované na operačních systémech se servisním balíčkem SP6A a MS Windows 2000 se servisním balíčkem SP3. Z důvodu shodné architektury s Windows 2000 nebyl zvláště testován Windows XP. V jednom souboru měření je vykonáno 600 000 dotazů sériově prováděných v intervalech cca 60 ms. Během jednoho souboru měření je systém buď: a) nezatížen to znamená, že v měřeném systému není spuštěna žádná aplikace a periferní zařízení nejsou uživatelsky používány, b) zatížen v systému běží program MS CPU Stress a je prováděno kopírování celého obsahu zvoleného CD na pevný disk. I v případě nezatíženého systému jsou kromě speciální měřící obsluhy navíc zpracovávány některé přerušení (zejména přerušení časovače IRQ0 a přerušení hodin reálného času IRQ8) a prováděny systémové úlohy. Samozřejmě, že všechny tyto činnosti také ovlivňují měření, nicméně jsou pro chod systému nezbytné a tudíž je nelze eliminovat. K získaní souboru dob odpovědí na zatíženém systému byla zvolena kombinace programu MS CPU Stress a kopírování celého obsahu CD na pevný disk. Konkrétní nastavení programu CPU Stress byl volen tak, aby procesor počítače byl na hranici 0% zatížení (viz obr. 6). Obr. 6: Použití programu MS CPU Stress
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 76 Program simuluje běh uživatelského software, který však běží s úrovní IRQL 0 a tudíž z principu nezasahuje do správy přerušení. Z tohoto důvodu byl navíc systém zatížen úlohou kopírováním obsahu CD na pevný disk. Tím do systému vstupují obsluhy přerušení IRQ4 a IRQ, které spolu s ostatními žádostmi již výrazně ovlivňují správu přerušení. Procentuální vytížení systému je nejlépe patrné z obrázku 7, který obsahuje snímek programu Performance Monitor během prováděného měření v systému MS Windows NT. Úroveň zatíženi ve Windows 2000 je podobné. Obr. 7: Vytížení systému dle programu Performance Monitor během měření ve Windows NT K zajištění objektivity byla před každým měřením předchozí kopírovaná data smazána, pevný disk defragmentován a počítač restartován. Jednotlivé soubory naměřených vzorků byly vyhodnocovány a graficky zpracovány. Hlavním vyhodnocovaným kritériem je doba, do které odpoví 99,9 % vzorků a doba nejpozději přijaté odpovědi. Každé měření bylo nejméně dvakrát opakováno, a přičemž jednotlivé soubory dat se v prvním sledovaném parametru lišily maximálně rozdílem jedné mikrosekundy. Níže uvedené grafy tak prezentují ty soubory dat u nichž byl nejdelší druhý sledovaný parametr představující dobu nejpozději přijaté odpovědi. Jako první bylo provedeno měření na systémech používající standardní mechanizmus správy přerušení (IRQL 20). Získané hodnoty zpracované do grafické podoby ve formě grafu jsou uvedeny jak pro nezatížené tak pro zatížené systémy na obrázcích 8 a 9.
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 77 MS Windows 2000 00000 00000 389440 295060 0000 Standardní mechanizmus - bez úprav Bez zatížení 0000 Standardní mechanizmus - bez úprav Nezatíženo 000 00 odpovědí do 3 s Všechny odpovědi přijaty do 33 s 000 00 odpovědí do 3 s Všechny odpovědi přijaty do 26 s 0 0 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 Obr. 8: Soubor naměřených dob odpovědí nezatíženého standardního systému MS Windows 2000 00000 00000 389440 295060 0000 Standardní mechanizmus - bez úprav Bez zatížení 0000 Standardní mechanizmus - bez úprav Nezatíženo 000 00 odpovědí do 3 s Všechny odpovědi přijaty do 33 s 000 00 odpovědí do 3 s Všechny odpovědi přijaty do 26 s 0 0 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 Obr. 9: Soubor naměřených dob odpovědí zatíženého standardního systému Ze srovnání uvedených grafů je patrný silný vliv zatížení systému především na nejpozději přijatou odpověď. Zatímco u nezatíženého systému byly všechny odpovědi přijaté do 33 µs, tak u zatíženého systému byla nejpozději přijatá odpověď v 97 µs, co odpovídá 300% nárůstu. Také doba, do které vzorků vykoná odpověď byla o 200% prodloužena z 3 µs na 26 µs. Obdobné závěry lze vysledovat také srovnáním grafů hodnot získaných na MS Windows 2000. Zde byla doba nejpozději přijaté odpovědi prodloužena o více než 400% z 26 na 5 µs a u kritéria 99,9 % odpovědí o téměř 60 % z 3 na 2 µs. Porovnáme-li však grafy napříč mezi operačními systémy, lze vypozorovat vliv rozdílné správy priorit. Co se týče kritéria nejdelší odpovědi je na tom lépe MS Windows NT. Naopak v druhém kritériu je na tom výrazně lépe MS Windows 2000. Jak již bylo uvedeno také v nezatíženém systému jsou vykonávány činnosti, které ovlivňují mechanizmus správy přerušení. Zajímavé je tak porovnat výše naměřené hodnoty se souborem dat získaných na systému, který má maskována všechna přerušení kromě vstupu klávesnice a vlastního měřeného paralelního portu. Tím je možné získat hodnoty odpovídající ideálnímu stavu, kdy zvolený kanál (IR7) není nikdy blokován a je vždy přednostně obsloužen (viz obrázek ). Měření s takto uživatelsky upravenou maskou je možné realizovat pouze v MS Windows NT, neboť zde systém oproti operačnímu systému MS Windows 2000 aplikuje vlastní masku až v okamžiku vzniku kolize.
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 78 00000 0000 32836 Všechna ostatní přerušení maskována - ideální stav 000 odpovědí do 8 s Všechny odpovědi přijaty do 9 s 00 0 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 Obr. : Soubor naměřených dob odpovědí ideálního systému (získáno v MS Windows NT) K uvedenému grafu je však třeba podotknout, že maskováním ostatních přerušení se stal systém nepoužitelný, neboť blokováním časovačů byl naprosto narušen multitasking nehledě na ostatní periferní zařízení, které jsou takto prakticky nefunkční (pevný disk, myš, síťová karta, matematický koprocesor apod.). Tudíž obdobné hodnoty nelze na reálně použitelném systému dosáhnout, neboť současné použití několika zdrojů přerušení vyžaduje jejich správu, která z principu musí být po dobu své činnosti chráněna před nežádoucím přerušením. Zaměřme se tedy na reálně použitelné úpravy, jejíž princip je zmíněn v předchozí kapitole. Veškeré navržené úpravy nabývají na významu až při vzniku několika žádostí současně, tedy pro náš případ při zatíženém systému. Jako první uveďme provedené měření zatíženého systému se změněnými hardwarovými prioritami vstupů obvodu 8259A. MS Windows 2000 00000 00000 0000 23553 Přiřazena nejvyšší priorita vstupu IR7 Zatíženo: CPU Stress, Kopírování CD -> HD 0000 28857 Přiřazena nejvyšší priorita vstupu IR7 Zatíženo: CPUStress a kopírování z CD na HD 000 00 0 odpovědí do 26 s Všechny odpovědi přijaty do 50 s 000 00 0 odpovědí do 20 s Všechny odpovědi přijaty do 88 s 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 Obr. : Soubor dob odpovědí zatíženého systému se změněnou prioritou vstupu IR Porovnáním nově získaných dat (obr. ) s naměřenými hodnotami standardního systému (obr. 9) je patrné, že uvedená úprava se u Windows NT pozitivně projevila zejména na době nejpozději přijaté odpovědi a to téměř zkrácením času na polovinu (z 97 µs na 50 µs). Oproti tomu doba, do které odpovědělo 99,9 % vzorků se vůči nezatíženému systému neliší. Podobně avšak s menším poměrem se úprava projevila na MS Windows 2000. Zde se doba nejpozději přijaté odpovědi zkrátila o více než 30% ze 5 µs na 88 µs.
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 79 Následující obrázek představuje výsledek měření s upravenou obsluhou přerušení, která oproti standardu během své činnosti maskuje vstup INTR a zabraňuje tak nežádoucímu přerušení. Tato úprava má význam pouze v prostředí MS Windows NT, neboť na úrovni IRQL 3 systém MS Windows 2000/XP již automaticky maskuje všechny kanály IR. 00000 0000 275488 Makování vstupu INTR během obsluhy Zatíženo: CPU Stress, Kopírování CD -> HD 000 00 0 odpovědí do 22 s Všechny odpovědi přijaty do 96 s 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 Obr. 2: Soubor dob odpovědí zatíženého systému MS Windows NT s obsluhou maskující vstup INTR Tentokráte vůči standardnímu použití nejsou žádná výrazná zlepšení patrná. Pouze došlo k mírnému zkrácení doby prezentující 99,9 % všech odpovědí (z 26 µs na 22 µs). Důvodem je, že odpovědní obsluha je poměrně velmi krátká, tudíž výhoda nepřerušitelnosti obsluhy se nemůže výrazněji projevit. Použitá úprava nabývá výraznějšího významu až v případě složitějších obsluh přerušení, kdy z důvodu delší činnosti je pravděpodobnost výskytu přerušení výrazně vyšší. Poslední navržená úprava je založená na vynuceném zvýšení úrovně IRQL obslužné rutině. MS Windows 2000 00000 00000 0000 295363 Zvýšena úroveň IRQL na 3 Zatíženo: CPU Stress, Kopírování CD -> HD 0000 84924 Upravený mechanizmus - úroveň IRQL 3 Zatíženo: CPUStress a kopírování z CD na HD 000 00 odpovědí do 4 s Všechny odpovědi přijaty do 42 s 000 00 odpovědí do 8 s Všechny odpovědi přijaty do s 0 0 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 Obr. 3: Soubor odpovědí zatíženého systému s obsluhou zpracovávanou na úrovni IRQL 3 Jak je z grafů patrné, zvýšení úrovně IRQL na hodnotu 3 mělo na jednotlivé operační systémy opět mírně odlišný vliv. V případě MS Windows NT 4 jsou oba sledované parametry oproti standardnímu mechanizmu zkráceny téměř na polovinu. Kdežto u MS Windows 2000 se zásadním způsobem zkrátila pouze doba do které odpovědělo všech 99,9 % vzorků.
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 80 Snahou předchozích třech měření bylo ověřit navržené úpravy vždy samostatně nezávisle na ostatních. Na následujícím obrázku 4 jsou již zobrazeny výsledné soubory měření nad systémem používající všechny navržené úpravy současně. MS Windows 2000 00000 00000 238592 26478 0000 Společně všechny úpravy: maska INTR, IRQL 3, max IR7 Zatíženo: CPU Stress, Kopírování CD -> HD 0000 Obě úpravy společně: nejvyšší IR7, IRQL 3 Zatíženo: CPUStress a kopírování z CD na HD 000 00 0 odpovědí do 4 s Všechny odpovědi přijaty do 25 s 000 00 0 odpovědí do 8 s Všechny odpovědi přijaty do 87 s 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 3 5 7 9 3 5 7 9 2 23 25 27 29 3 33 35 37 39 4 43 45 47 49 Obr. 4: Soubor dob odpovědí zatíženého systému používající všechny navržené úpravy Zaměříme-li se na operačním systému MS Windows NT zjistíme, že kombinací všech úprav se výrazně zkrátily oba sledované parametry. Především termín nejpozději získané odpovědi (24 µs) je vůči neupravenému systému (97 µs) zkrácen na čtvrtinu a je dokonce kratší nežli limit do kterého původně odpovědělo 99,9 % vzorků. Díky tomu se snížil celkový rozptyl všech odpovědí, tudíž se výrazně zvýšila determinovatelnost zvolené obsluhy a tím i použitelnost k real-time operacím. Také v operačním systému MS Windows 2000 došlo ke zlepšení obou sledovaných parametrů. Oproti však svému předchůdci nejsou rozdíly až tak výrazné. Robustnější mechanizmus správy přerušení výrazněji odolává požadovaným změnám v prioritním uspořádání požadavků IRQ. Přesto obě použité úpravy (samostatně tak také společně) prokazatelně zkrátily oba sledované parametry a vylepšily tak determinovatelnost zvolené obsluhy. Naměřené výsledky potvrdily správnost použitých úprav a jejich pozitivní vliv na determinovatelnost takto koncipovaných úloh pro oba dva typy operačních systémů. Prezentovaných výsledků bylo dosaženo při řešení výzkumného záměru MSM 27230002. 4 Literatura CRAIG PEACOCK S 998A. Interfacing the Standard Parallel Port [online]. Craig Peacock February 998. PDF format. Available from WWW: <URL: http://www.beyondlogic.org>. CRAIG PEACOCK S 998B. Using Interrupts [online]. Craig Peacock February 998. PDF format. Available from WWW: <URL: http://www.beyondlogic.org>. FOJTÍK, D. 2003 Měření latence odpovědi na vznik přerušení v operačním systémech MS Windows NT/2000. In Workshop 2003 Fakulty strojní. Ostrava : VŠB-TU Ostrava, 7.. 2003, s. 9-2. ISBN 80-248-0233-3. INTEL CORPORATION 988. 8259A Programmable interrupt controller [online]. Intel Corporation December 988. PDF format. Available from WWW: <URL: http://www.intel.com>. Order Number 23468-003 MUELLER, S. 200 Osobní počítač. Praha: Computer Press, 200. ISBN 80-7226-470-2
XXVIII. ASR '2003 Seminar, Instruments and Control, Ostrava, May 6, 2003 8 MICROSOFT 998A. Microsoft Windows NT DDK. Redmond: Microsoft Corporation Redmond USA, 998. MICROSOFT 998B. MSDN Library April 998. Redmond: Microsoft Corporation Redmond USA, 998. MICROSOFT 2000. Microsoft Windows 2000 DDK. Redmond: Microsoft Corporation Redmond USA, June 28, 2000. NĚMEC, D. 988. Návody a vzory realizací s 8086. Praha: ČSVTS, 988. SOLOMON, A. D. 999. Windows NT pro administrátory a vývojáře. Praha: Computer Press, 999. ISBN 80-7226-47-9.