ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická BAKALÁŘSKÁ PRÁCE. 2009 Michal Pantůček

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická BAKALÁŘSKÁ PRÁCE 2009 Michal Pantůček

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Katedra měření Komunikace v síti Ethernet v reálném čase Vedoucí práce: Ing. Jiří Novák, Ph.D. Autor: Michal Pantůček Praha 2009

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací. V Praze dne.. podpis

Anotace Tato bakalářská práce je zaměřena na Ethernet a jeho možné užití v aplikacích, kde je vyžadována komunikace v reálném čase. Nastiňuje, kde je kriterium přechodu od náhodného k deterministickému přístupu k médiu z hlediska komunikace v reálném čase za použití vytvořeného modelu a na něm provedených simulací. Konkrétně tak, aby byla minimalizována doba čekání na odeslání dat a maximalizována datová propustnost sítě. Annotation This bachelor thesis is focused on the Ethernet and its possible use in applications where real-time communication is required. It illustrates using created model and simulations where the criterion of transition from stochastic to deterministic media access control in light of real-time communication is. It is done concretely in order to minimize waiting time for sending a data and to maximize the data transmission efficiency.

Úvod... 1 1 Ethernet... 2 1.1 Vznik a historie... 2 1.2 Popis pracovních skupin pod IEEE 802... 2 1.3 Spojová vrstva... 5 1.4 Kontrola přístupu k mediu... 5 1.5 MAC formát rámce... 7 1.6 Metoda přístupu k médiu... 9 1.6.1 Odložení vysílání (deference)... 10 1.6.2 Vznik kolizí... 10 1.6.3 Detekce kolizí a jejich prodloužení... 11 1.6.4 Backoff a opětovný přenos rámce... 11 1.6.5 Zrychlený přenos rámců... 12 1.7 Příjem rámců... 12 1.7.1 Rozlišení kolize... 12 1.8 Fyzická vrstva... 12 2 Model komunikace po Ethernetu... 14 2.1 Popis modelu... 14 2.1.1 Ethernet... 14 2.1.2 Uzel... 16 2.1.3 TransmitFrame... 17 2.1.4 Backoff... 17 2.1.5 NahGen... 18 2.2 Simulace... 18 2.2.1 Výsledky simulace... 19 3 Ověření modelu na reálném systému... 20 3.1 Aplikace k měření... 20 3.1.1 Časování... 21 3.1.2 Ostatní části programu... 23 3.1.3 Výsledky měření... 24 4 Porovnání s deterministickými přístupy... 26 5 Závěr... 27 Seznam použité literatury... 28 Struktura CD přílohy... 30 Seznam použitých zkratek... 31 CD příloha - v -

Poděkování patří Ing. Jiřímu Novákovi, Ph.D. za věcné připomínky, pomoc a rady, bez kterých by nemohla tato práce vzniknout. Dále patří poděkování také rodině za trpělivost. - vi -

Úvod Ethernet je technologie používaná pro budování lokálních sítí (LAN) a její chování je nedeterministické. To zpravidla v normálním kancelářském použití, kdy nepotřebujeme zaručenou minimální odezvu, resp. dobu čekání na odeslání dat, nebo nemáme síť příliš vytíženou, vyhovuje. V poslední době se ale Ethernet používá i v řídících aplikacích, ve kterých je nutné zajistit odeslání dat v minimálním čase, resp. dodržení určité maximální doby odezvy v závislosti na řízených procesech a to vždy i při velkém vytížení média. Klasický Ethernet podle standardu IEEE 802.3 tomuto ne úplně vyhovuje, a proto byl vyvinut průmyslový standard Ethernetu, který již má jinak řešenou architekturu a determinismus a vyhovuje lépe. Existuje více těchto průmyslových provedení např. Powerlink, EtherCat, Profinet apod. Tahle práce se nicméně nezabývá přímo těmito průmyslovými standardy (o nich více v [1] a [2]), ale pokusí se ilustrovat způsob, jak je možné provozovat aplikace reálného času na klasickém Ethernetu tak, aby vyhovoval jejím požadavkům. Konkrétně se zaměří na kriterium přechodu na deterministický systém, který je sice pomalejší, ale je zde zajištěna přesně doba doručení dat a od určitého vytížení sítě se jeho použití vyplatí. Hlavní věcí této práce je vytvoření modelu, který umožňuje nasimulovat chování Ethernetu. Správnost modelu je ověřena s chováním skutečné reálné sítě. Práce obsahuje výstupy simulací v podobě grafů, ze kterých lze stanovit ono kriterium přechodu. - 1 -

1 Ethernet 1.1 Vznik a historie Vznik Ethernetu sahá až do 70. let. U zrodu stála firma Xerox Corporation a její vývojové a výzkumné centrum Palo Alto Research Center. Xerox v té době řešil potřebu sdílet své drahé tiskárny mezi více počítači. V roce 1975 tak vznikla experimentální síť s rychlostí 3 Mbit/s používající koaxiální kabel a technologii CSMA/CD (carrier sense multiple access with collision detection)- metoda mnohonásobného přístupu k mediu s nasloucháním nosné a detekcí kolizí. Po úspěchu této sítě pokračoval vývoj v kooperaci tří firem DEC, Intelu a Xeroxu a byl vydán, podle počátečních písmen zúčastněných firem, tzv. DIX standard někdy zvaný též Blue Book standard neboli Ethernet verze 1.0. Šlo o Ethernet s rychlostí přenosu 10 Mbit/s. Publikován byl tento standard u organizace IEEE v roce 1980. Tento standard se stal poté základem pro oficiální standard- IEEE Std. 802.3 [6] publikovaný v roce 1985. V pozdějších letech byl standard dále doplňován, rozšiřován a rozvíjen. V roce 1990 přibyla jako možné médium kroucená dvojlinka a topologie typu hvězda (IEEE 802.3i). Byly také postupně zvyšovány rychlosti přenosu až na momentálních 10 Gbit/s. Ve vývoji pracovní skupinou 802.3 je i 40 a 100 Gbit/s. Historie je blíže popsána v [1], [3] a [4]. 1.2 Popis pracovních skupin pod IEEE 802 Dále je uvedena tabulka s výčtem pracovních skupin IEEE 802, mezi kterými je i skupina pracující na Ethernetu a tabulka popisující jednotlivé standardy v rámci pracovní skupiny IEEE 802.3, tedy Ethernetu. - 2 -

Tab. 1.1: Popis pracovních skupin 802.X podle [5] Číslo Náplň prac. skupiny Stav 802.1 Vyšší vrstvy LAN protokolu aktivní 802.2 Logical Link Control neaktivní 802.3 Ethernet aktivní 802.4 Token Bus rozpuštěna 802.5 Token Ring neaktivní 802.6 Metropolitan Area Network rozpuštěna 802.7 Širokopásmový TAG rozpuštěna 802.8 Optovláknový TAG rozpuštěna 802.9 Integrované služby LAN rozpuštěna 802.10 Bezpečnost rozpuštěna 802.11 Bezdratové LAN aktivní 802.12 Priorita na žádost rozpuštěna 802.13 - - 802.14 Kabelový modem rozpuštěna 802.15 Wireless Personal Area Network (WPAN) aktivní 802.16 Širokopásmový bezdrát aktivní 802.17 Pružný paket ring aktivní 802.18 Radio Regulatory TAG aktivní 802.19 Coexistence TAG aktivní 802.20 Mobilní širokopásmový bezdrátový přístup (MBWA) aktivní 802.21 Media Independent Handoff aktivní 802.22 Wireless Regional Area Networks aktivní - 3 -

Tab. 1.2: Přehled standardů Ethernetu 802.3 podle [5] Standard Popis 802.3a 10BASE2, 10 Mbit/s přes koax. 802.3b 10BROAD36 802.3c Specifikace opakovače- 10 Mbit/s 802.3d FOIRL- Spoj z optického vlákna s opakovačem 802.3e 1BASE5- StarLAN 802.3i 10BASE-T, 10 Mbit/s, kroucená dvojlinka 802.3j 10BASE-F, 10 Mbit/s, optické vlákno 802.3u 100BASE-TX, 100BASE-T4, 100BASE-FX, 100Mbit/s 802.3x Plný duplex s kontrolou toku dat 802.3y 100BASE-T2, 100 Mbit/s, méně kval. kroucená dvojlinka 802.3z 1000BASE-X, 1 Gbit/s, optické vlákno 802.3ab 100BASE-T, 1 Gbits, kroucená dvojlinka 802.3ac Rozšíření max. rámce kvůli Qtag 802.3ad Agregace linky 802.3ae 10 Gbit/s, opt. vlákno 802.3af PoE- Power over Ethernet (napájení přes Ethernet) 802.3ah Ethernet in the First Mile (spojení na dlouhé vzdál.) 802.3ak 10GBASE-CX4, 10 Gbit/s, twinaxiální kabel 802.3an 10GBASE-T, 10 Gbit/s, UTP 802.3ap Backplane Ethernet, 10 Gbit/s přes tištěný spoj 802.3aq 10GBASE-LRM, 10 Gbit/s přes multividové opt. vlákno 802.3ar Řízení při přetížení sítě 802.3as Rozšíření rámce 802.3at Vylepšení PoE 802.3au PoE- požadavky na izolaci 802.3av 10 Gbit/s, EPON 802.3aw 10GBASE-T- oprava 802.3az Energy Efficient Ethernet- EEE 802.3ba 40 Gbit/s, 100 Gbit/s Ethernet 802.3bb Zvětšení pauzy reakční doby dostatečně pro 10 Gbit/s 802.3bc EOS typy, délky, hodnoty 802.3bd Řízení toku dat na základě priority 802.3be MIB definice pro Ethernet Standard IEEE 802.3 [6] specifikuje z hlediska referenčního ISO/OSI (International Organisation for Standartization/Open Systems Interconnection) - 4 -

modelu komunikace spodní dvě vrstvy a to spojovou a fyzickou viz Obr. 1.1. Obě vrstvy jsou podle standardu popsány dále. Obr. 1.1: Referenční ISO/OSI model komunikace 1.3 Spojová vrstva Spojová neboli linková vrstva (data link layer) podle ISO/OSI modelu definuje, jakým způsobem jsou předávány zprávy v síti. Podle standardu 802.3 [6] je spojová vrstva dělena na 3 podvrstvy: MAC (Media Access Control- kontrola přístupu k mediu) klientnapř. LLC (Logical Link Control) MAC Control- nepovinná MAC (Media Access Control) 1.4 Kontrola přístupu k mediu MAC, tedy kontrola přístupu k mediu, poskytuje služby umožňující místnímu MAC klientu výměnu dat s jinými (cizími) klienty- LLC podvrstvami. Volitelná podvrstva MAC Control může zajišťovat další služby ke kontrole MAC operací. Může tak být použita na kontrolu toku dat mezi MAC klienty skrze příslušný komunikační kanál. - 5 -

Standard specifikuje i určitou abstrakci funkční specifikace pro výměnu dat mezi podvrstvami. Zadefinovány jsou dva typy: a) požadavek (request)- požadavek předávaný z vrstvy N do vrstvy N-1 b) signál, indikace (indication)- indikace nějaké události na vrstvě N-1 předávaná z vrstvy N-1 do N, která je využitelná pro vrstvu N, tato událost může vzniknout po nějakém vnějším požadavku nebo může být zapříčiněna vnitřní událostí ve vrstvě N-1 Vrstva N-1 je poskytovatelem služby a vrstva N uživatelem, jak je znázorněno na Obr. 1.2, převzatém z [6]. Obr. 1.2: Znázornění vztahu vrstev v rámci specifikace z [6] Datový požadavek i indikace obsahují adresu cíle a zdroje, data, která jsou předávána resp. obdržována a kontrolní součet rámce. Indikace ještě navíc obsahuje informaci o stavu pro MAC klienta. Požadavek je vygenerován MAC klientem kdykoliv potřebuje přenést data. Naopak indikace je předána z MAC podvrstvy MAC klientu, případně ještě přes MAC Control podvrstvu tak, aby indikovala příjem rámce směřujícího k MAC klientu MAC podvrstvou. Takto se děje pouze pokud je rámec přijat bez chyb a je určen pro danou místní MAC entitu. V případě existence MAC Control podvrstvy jsou definovány ještě kontrolní požadavek a indikace. Požadavek obsahuje cílovou adresu, kód operace požadované MAC klientem a sadu parametrů podle příslušného kódu - 6 -

operace. Požadavek je generován MAC klientem, když chce použít nějaké operace MAC Control podvrstvy. Indikace obsahuje pouze kód operace a prvky podle příslušného kódu operace. Indikace je generována MAC Control podvrstvou podle podmínek specifických pro každou MAC Control operaci. 1.5 MAC formát rámce Obr. 1.3: Formát rámce pro přenos dat podle [6] Struktura rámce je standardem [6] specifikována na 9 částí viz Obr. 1.3. Byty rámce jsou přenášeny odshora dolů a bity jednotlivých bytů zleva doprava, přičemž jsou orientovány od méně významného (LSB) po nejvýznamnější (MSB) bit. První částí je 7 bytů dlouhá preambule, tedy počáteční část, která slouží k sesynchronizování se s časováním příchozího rámce. Obsahem jsou střídavě za sebou bity 10. Dále navazuje část zvaná SFD (Start Frame Delimiter), což je vždy sekvence bitů ve tvaru: 10101011. Tato část uvozuje začátek rámce. Následující adresová pole jsou rozdělena na 3 části. Celková délka pole je 48 bitů. První bit u adresy cíle vyjadřuje, zda se jedná o adresu individuální (0) nebo skupinovou (1). Individuální je pak vždy adresa spjatá s konkrétní stanicí v síti LAN, zatímco u skupinové adresy se může jednat buď o adresu - 7 -

odpovídající nějaké konvenci na vyšší úrovni nebo o tzv. broadcast adresu, tedy adresu označující jako příjemce všechny stanice v lokální síti. U adresy zdroje je první bit rezervován a je vždy 0. Druhý bit slouží k vyjádření, zda je adresa spravována lokálně (1) nebo globálně (0). Zbytek je vyhrazen již pro samotnou adresu. Další pole definující délku nebo typ má 2 byty. Rozhodující pro interpretaci je první byte. Pokud je jeho hodnota menší nebo rovna 1500 dekadicky, pak číslo značí počet bytů dat. Pokud je větší nebo rovno 1536, pak číslo vyjadřuje typ protokolu MAC klienta. Minimální velikost dat je při implementaci 46 bytů a maximální 1500 bytů. Pokud nemají data minimální velikost, tak jsou k nim přidány jako výplň další bity tak, aby byla minimální velikost zajištěna. Čtyř bytový kontrolní redundantní součet CRC je počítán z obsahu polí adresy zdroje, cíle, délky/typu, dat a výplně. Jako generující polynom se používá: G(x) = x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x + 1 Postup výpočtu je takový, že nejprve je sestaveno prvních 32 bitů rámce. Poté je n bitů rámce dosazeno za koeficienty polynomu M(x) stupně n-1. První bit adresy cíle odpovídá x (n-1) a poslední bit dat odpovídá x 0. Polynom M(x) je vynásoben x 32 a vydělen polynomem G(x). Zbytek, který vyjde- R(x) má stupeň maximálně 31. Jednotlivé koeficienty R(x) jsou 32 bitovým CRC součtem. Přídavné rozšíření rámce, které následuje po kontrolním součtu je sekvence bitů dostatečně odlišná od dat. Rozsah je dán od 0 do počtu bitů, který je dán rozdílem tzv. slot time a minimální délky rámce. Význam slot time viz 1.6.2. Podle implementace je horní hodnota rozsahu rozšíření rámce např. pro 1 Gbit/s 3584 bitů. Rámec je prohlášen za chybný při doručení, pokud je splněna aspoň jedna z následujících podmínek: a) Nesouhlasí délka rámce s délkou uvedenou v poli délka/typ. Pokud pole obsahuje kód typu namísto délky, pak je rámec prohlášen za z tohoto pohledu za konzistentní. b) Délka není v celých bytech. - 8 -

c) Bity v příchozím framu negenerují kontrolní součet CRC identický s obdrženým. Obsah nekorektních rámců není postoupen LLC a MAC Control podvrstvám. Standard dále definuje ještě rozšíření specifikace rámce o tzv. Qtag Prefix. Jedná se o rozšíření o dvě dvojice bytů za pole s adresou zdroje. Podrobná definice je ve standardu IEEE P802.1Q. Toto rozšíření umožňuje rozlišení VLAN (Virtual Local Area Network), tedy virtuální sítě, které bývají vytvářené např. na úrovni přepínače k určitému rozdělení sítě LAN na logické virtuální celky. 1.6 Metoda přístupu k médiu Standard poskytuje 2 režimy činnosti MAC podvrstvy: a) Poloduplexní (half duplex) b) Plně duplexní (full duplex) U poloduplexního režimu se uplatňuje algoritmus přístupu k médiu CSMA/CD a stanice se dělí o médium. Obousměrný přenos je realizován rychlou výměnou rámců. Poloduplexní režim je možný na všech podporovaných médiích a je nutný u médií, u kterých není možné zároveň přijímat a odesílat bez kolize. Naproti tomu u plně duplexního režimu dochází pouze vždy ke komunikaci bod bod mezi dvěmi stanicemi. Médium tedy není sdíleno mezi více stanicemi a nedochází ke kolizím. Tento režim může být použit pouze na médiích, která umožňují simultánní vysílání a příjem bez interferencí. Plně duplexního režimu se nejčastěji užívá v sítích s přepínačem. Dále se budu věnovat hlavně poloduplexnímu režimu a popisu metody CSMA/CD. CSMA/CD MAC podvrstva poskytuje MAC klientu služby potřebné pro přenos a příjem rámců a zprostředkovává také přivlastnění si média a přenos sériového toku bitů fyzické vrstvě. MAC podvrstva zajišťuje také doručování různých chyb MAC klientu. - 9 -

Nejprve je sestaven rámec pomocí informací dodaných MAC klientem. Výplň je potřebná, pouze pokud nemají data minimální délku. Rozšíření na konci rámce je nezbytné k zajištění dostatečné délky, resp. doby trvání přenosu na médiu v poloduplexním režimu při rychlosti 1 Gbit/s. Kontrolní součet je buď poskytnut MAC klientem, nebo je zajištěn až MAC podvrstvou, pokud ta nepodporuje předání CRC od MAC klienta. 1.6.1 Odložení vysílání (deference) Po tom, co je rámec MAC klientem předán k přenosu, je zahájeno odesílání, co nejdříve je to možné. Pro poloduplex platí, že CSMA/CD MAC podvrstva sleduje médium, i když pravě nemá nic k odeslání. Sleduje signál z PLS (Physical Layer Signaling), podvrstvy fyzické vrstvy. Kdykoliv je médium zaneprázdněné CSMA/CD MAC podvrstva odkládá na základě tohoto signálu vysílání rámce. Když je přenesen poslední bit rámce a médium se uvolní, čímž se změní přijímaný signál z PLS, MAC podvrstva pokračuje v čekání po dobu povinné mezirámcové mezery. Pokud je po uplynutí této doby připraven nějaký rámec k odeslání, pak je ihned zahájen přenos. Pokud není nic k přenesení nebo po přenosu MAC podvrstva pokračuje ve sledování média. K zajištění robustnosti je doporučeno implementovat mezirámcovou mezeru tak, že se rozdělí na dvě části a pokud je médium obsazeno během prvních dvou třetin intervalu, tak je odpočítávání této prodlevy restartováno. Při obsazení až při poslední třetině se potom již odpočítávání nerestartuje. Toto je ale pouze doporučené, nepovinné a počáteční část může být kratší než dvě třetiny i nulová. Co se týče plně duplexního módu, tam ke kolizím s jinými uzly nedochází. Zde je pouze po dokončení přenosu rámce čekání po dobu mezirámcové mezery. Povinná mezirámcová mezera je hodnota minimální prodlevy mezi rámci. Tato hodnota může být v závislosti na implementaci vyšší. 1.6.2 Vznik kolizí Když je dokončeno čekání na uvolnění média a začne vysílání, tak potom může dojít ke kolizi, pokud začne vysílat více stanic v době, než je - 10 -

dokončeno obsazení média kteroukoli stanicí. Tato doba se nazývá kolizní okno. Dynamika kolizí je nejvíce ovlivněna zejména jedním parametrem tzv. slot time. Tento údaj vyjadřuje horní hranici doby trvání obsazení média a zároveň udává maximální délku fragmentu rámce generovaného při kolizi. Je používán i jako jednotka při vyčkávání před pokusem o opětovný přenos po kolizi. Jeho hodnota, aby vyhovoval, by měla být větší než suma času, za který se signál dostane z jednoho konce sítě k druhému, viz fyzická vrstva, a maximálního tzv. jam času. Oba termíny jsou postupně popsány dále. Absolutní velikost slot time je dána implementací. Např. pro rychlost 100 Mbit/s je jeho hodnota 512 bitového času, což je relativní jednotka daná dobou, za kterou je síťový interface schopný vyprodukovat na médium 1 bit. 1.6.3 Detekce kolizí a jejich prodloužení Kolize jsou detekovány prostřednictvím signálu z fyzické vrstvy. Pokud je detekována kolize během přenosu, vysílající stanice nepřeruší ihned přenos, ale pokračuje ve vysílání tzv. jam sekvence. Jedná se o prodloužení kolize z toho důvodu, aby všechny stanice kolizi zaznamenaly. Velikost sekvence činí 32 bitů. Obsah této přídavné sekvence bitů není definován, jen by měl být odlišný od kontrolního CRC součtu odpovídajícího rámci, který byl vysílán. 1.6.4 Backoff a opětovný přenos rámce Po kolizi dochází k opětovnému přenosu rámce. Počet opětovných pokusů je omezen pro rychlosti přenosu do 1 Gbit/s na 16 pokusů. K opětovnému odeslání rámce nedochází hned. Po odeslání jam sekvence bitů je další přenos naplánován pomocí algoritmu zvaného exponenciální backoff. Doba do dalšího pokusu je v násobkách slot time času. O kolikanásobek se jedná, rozhoduje náhodně vygenerované číslo, které je v intervalu 0; 2 k ), kde k odpovídá tomu o kolikátý opětovný pokus o odeslání rámce se jedná. Při prvním opětovném pokusu se tedy vybírá z čísel 0, 1, při dalším 0, 1, 2, 3 apod. V dalších pokusech až do desátého. Potom se již interval nenavyšuje. Maximální interval je tedy 0; 2 10 ). - 11 -

1.6.5 Zrychlený přenos rámců Při rychlosti 1 Gbit/s je možné implementovat přenos skupiny rámců bez předávání kontroly nad médiem jinému uzlu, tzv. burst mód. Po úspěšném přenosu rámce může vysílající stanice pokračovat v přenosu dalším rámcem, při čemž ostatní stanice stále vyčkávají. Toho je dosaženo tak, že vysílající stanice nečeká ani po dobu mezirámcové mezery. Onu dobu totiž vyplní rozšířením přídavnými bity, které jsou na straně přijímající stanice rozlišeny od datových. Vysílající stanice může takto vysílat rámce, dokud není dosaženo burst limitu 65536 bitů. První rámec je rozšířen, pokud je to potřeba. U dalších rámců již není rozšíření nutné. Po prvním odeslaném rámci již ve správně nakonfigurované síti nemůže dojít ke kolizi. 1.7 Příjem rámců Přijaté rámce jsou rozlišeny na základě monitorování signálu fyzické vrstvy. Mohou nastat dvě chyby. Buď je rámec moc dlouhý anebo není jeho délka v celých bytech. 1.7.1 Rozlišení kolize Při poloduplexním režimu musí mít každý rámec délku aspoň jeden slot time. Akorát pokud se jedná o rámce v sérii v burst režimu kromě prvního, tak stačí definovaná minimální délka rámce. Cokoliv kratší délky je prohlášeno za fragment vzniklý kolizí a je odmítnuto. Takováto situace je brána jako standardní a není označována za chybu. 1.8 Fyzická vrstva Co se fyzické vrstvy týká, standard definuje různá kompatibilní rozhraní. Pro rychlosti větší než 100 Mbit/s následující podvrstvy a rozhraní: a) Srovnání (Reconciliation) b) MII (Media Independent Interface) c) PCS (Physical Coding Sublayer) d) PMA (Physical Medium Attachment) e) PMD (Physical Medium Dependent) - 12 -

f) MDI (Medium Dependent Interface) g) Médium Pro rychlosti nižší: a) PLS (Physical Layer Signaling) b) AUI (Attachment Unit Interface) c) PMA (Physical Medium Attachment) d) MDI (Medium Dependent Interface) e) Médium Např. PLS podvrstva poskytuje služby místnímu MAC klientu k výměně datových bitů s MAC klientem cizím. Podrobně se nebudu těmto podvrstvám věnovat, protože to je mimo rozsah této práce. Více ve standardu IEEE 802.3 [6]. Dohromady jsou v jednotlivých podvrstvách a rozhraních definovány typy kabelů, konektorů, fyzické kódování jednotlivých bitů na médium (Manchester kód pro 10 Mbit/s a MLT-3 kódování v případě 100 Mbit/s), jednotlivé napěťové úrovně, el. schémata apod. 10 Mbit/s 10BASE5 a kódování Manchester má pouze 2 napěťové úrovně (+, -), kdežto 100 Mbit/s 100BASE-TX a kódování MLT-3 má napěťové úrovně 3 (+, 0, -). - 13 -

2 Model komunikace po Ethernetu Úkolem bylo vytvoření modelu, který bude simulovat přenos dat po Ethernetu a použít ho k určení doby, od které je výhodné přejít od ethernetovské stochastické přístupové metody CSMA/CD k nějakému deterministickému přístupu. Jako software byl pro vytvoření modelu zvolen program MATLAB společnosti MathWorks, protože jeho schopnosti jsou na podobné modely naprosto dostačující. Koneckonců všechny operace v rámci chování Ethernetu se dají nasimulovat matematickými operacemi, a tak nebylo třeba přímo programovat samostatnou aplikaci v nějakém programovacím jazyce. 2.1 Popis modelu Na přiloženém CD jsou umístěny soubory se zdrojovým kódem ve formátu programu MATLAB. Kód je rozdělen na 5 funkčních částí, souborů. Dále zde budou postupně popsány. Jsou zde pojmenovány tak, jako funkční soubory, resp. skripty na CD. 2.1.1 Ethernet V této hlavní části je nejprve definován rámec, přesně podle standardu. Byla zvolena minimální potřebná velikost klientských dat v rámci tak, aby nebyla potřeba výplň. Pro potřeby simulace tedy pracuji s minimální potřebnou velikostí rámce. V implementaci modelu jsem zvolil rychlost 100 Mbit/s, protože síťová rozhraní schopná operovat na této rychlosti standardu jsou asi nejrozšířenější a také jsou nejpoužívanější z hlediska aplikací v řízení. V modelu uvažuji také pouze poloduplexní režim, což je jasné s ohledem na použití. Z těchto uvedených informací tedy vyplývá použitá velikost rámce 576 bitů a absence rozšíření v rámci z toho důvodu, že to je používané pouze u rychlosti 1 Gbit/s. Stejně jako burst mód. Diskrétní jednotkou simulace byl zvolen bitový čas, tedy čas potřebný síťovým rozhraním k vyprodukování bitu na médium. Při zvolené rychlosti 100 Mbit/s to odpovídá 10 nanosekundám. - 14 -

Jednotlivým uzlům je náhodně vygenerováno v jakých časech budou mít požadavky na vysílání podle dané střední hodnoty rámců k odeslání za sekundu. Nejprve je po milisekundových intervalech vygenerováno pro každý bitový čas, zda bude chtít daný uzel vysílat. Milisekundový interval části je zvolen z kapacitních důvodů. Poté jsou vybrány pouze časy, kdy nějaký uzel chce vysílat a takto se pokračuje daným počtem částí, až je vygenerovaný kompletní časový rozsah. Další možností, která byla zkoušena při simulacích a je bližší řídícím aplikacím je metoda, kdy každý uzel automaticky vysílá ve stanovených intervalech podle střední hodnoty požadovaného zatížení sítě. Každý uzel při tom může začít na začátku v trochu jiný čas. Mezera mezi nimi je definována. Ve zdrojovém kódu je k dispozici ještě třetí, rychlejší možnost než první, která pouze vyplní první vygenerovanou milisekundou zbývající požadovaný čas tak, že je zkopírována za sebou, kolikrát je třeba. Pouze jsou rovnoměrně posunuty časy požadavků. Z hlediska přesnosti výsledného vytížení modelu sítě za sekundu je ale samozřejmě přesnější první metoda. Ta také byla používána v simulacích. Dále je zde while cyklus, hlavní část modelu, ve kterém se přičítá průběžně čas simulace. Původně byl model udělán se striktně lineárním časem. Jedno provedení cyklu tedy znamenalo posun času o 1. To se ovšem ukázalo jako nepoužitelné z důvodu přílišné výpočetní pomalosti. Rozhodl jsem se proto pro nelineární pojetí času s tím, že se přeskakuje čas mezi požadavky na přenos, kdy se nic neděje. Obsažena je i proměnná definující kolizní okno, kterým se simuluje čas prodlevy k zaznamenání kolize nebo toho, že vysílá jiný uzel. V reálu je tato prodleva ovlivněna vzdáleností vysílajících uzlů, délkou média. Maximální délka kabelu pro 100 Mbit/s standard je omezena standardem na 100 metrů. V praxi se užívá i mírně delší, zhruba do 200 metrů, protože standard je naddimenzován. Udávaná rychlost šíření signálu v UTP kabelu CAT5 je 0,66 rychlosti šíření světla ve vakuu. 8 8 3 10 1,98 10 m/s v 0,66 c 0,66 (1) - 15 -

Pro simulaci jsem zvolil tedy nejhorší možný případ a to délku média 200 metrů. l 200 6 t 1,01 10 s (2) v 8 1,98 10 Jak je vidět z rovnice (2) zvolil jsem velikost tohoto kolizního okna 1 s, tedy 100 v bitovém čase. Ve zmíněném while cyklu je obsažen algoritmus vyčkávání ( deferring algoritmus ), který zajišťuje sledování média, jak je definováno ve standardu a po zaregistrování uvolnění média odpočítávání mezirámcové mezery. Dále jsou zde zajištěna přeskakování času. Ten se přeskakuje, když je dokončen přenos rámce a je mezera k dalšímu požadavku a nic jiného se neděje. Potom také, když je přenášen pouze jeden rámec a ostatní uzly nic nedělají, příp. jsou v backoffu. To je řešeno tak, že po kolizním oknu, tedy v tomto případě po 100 prvních bitech rámce, kdy již není možné, aby došlo ke kolizi, dojde k přeskočení času ke konci přenosu rámce nebo ke konci nejkratšího backoffu ze všech uzlů, pokud nějaký je v běhu a podle toho, co je kratší, jestli nejkratší backoff nebo zbytek k přenosu rámce. Podle toho jak se posune čas, tak jsou poté kýžené hodnoty posunuty u jednotlivých uzlů prostřednictvím předání globální proměnnou. 2.1.2 Uzel Při programování bylo v MATLABU využito konceptu s lokálními persistent proměnnými. Jedná se o proměnné, které jsou lokální ve funkci, ve které jsou deklarovány. Jejich obsah je ukládán v tzv. workspace, které je vlastní dané funkci a proměnné jsou tak dostupné pouze z oné funkce., při čemž jejich obsah je uchováván i po skončení dané funkce a je dostupný při opětovných voláních funkce až do té doby, dokud nejsou proměnné smazány. Kvůli těmto persistent proměnným bylo nutné, aby každý uzel měl svojí vlastní funkci s unikátním jménem, protože každá funkce má svůj vlastní workspace a i přesto, že proměnné mají ve všech funkcích reprezentujících uzel stejné jméno, jsou navzájem izolované. Pro chod modelu je tedy nutné mít pro každý uzel vlastní funkci, i když zdrojový kód je pro každý uzel stejný. Funkce mají název uzelx.m, kde X je - 16 -

číslo uzlu a jsou volané z výše zmíněného while cyklu, ve kterém je for cyklus, který toto zajišťuje. Globální proměnné jsou oproti persistent proměnným dostupné během celého běhu skriptu ze všech funkcí, ve kterých jsou deklarované. Funkce uzlu obsahuje obsluhu vysílání. Pokud je médium z pohledu uzlu volné, tj. není aktivní vyčkávání nebo mezirámcová mezera, pak může být zahájeno vysílání, pokud je o to zájem. Do prvního sloupce matice proměnné transferredframes je ukládán čas požadavku na odeslání rámce a poté do druhého sloupce čas dokončení přenosu rámce. Ve třetím sloupci je počet kolizí. Z uzlu je volána funkce transmitframe, která zajišťuje vlastní přenos, resp. počítání po jednotlivých bitech a další věci. Její popis bude následovat. Dále je zde obsaženo navýšení aktuálního bitu o určitý počet bitů v případě přeskakování času. Pokud je vypotřebován maximální počet pokusů k přenosu rámce, tak je namísto času dokončení zapsáno NaN (not a number). Původně byla udělána každému uzlu fronta požadavků, takže se požadavky na přenos v rámci každého uzlu mohly hromadit. Protože by to ale mělo simulovat nějakou řídící aplikaci, tak bylo toto zrušeno, protože nemá význam, aby se v tomto případě hromadily požadavky, které by již nebyly aktuální v době, kdy by na ně přišla řada. 2.1.3 TransmitFrame Tato funkce reprezentuje obsluhu přenosu po jednotlivých bitech. Dále je zde zjištění nové kolize, při které se přeruší přenos a probíhá jamování, tedy prodloužení kolize. Poté se volá funkce obsahující výpočet backoffu, tedy čekání před opětovným pokusem o přenos. Ve funkci transmitframe je dále také odpočítávání backoff pauzy a i její přeskočení v případě přeskočení času. 2.1.4 Backoff Zde je prováděn algoritmus výpočtu exponenciálního backoffu. Implementace je provedena přesně, jak bylo již nastíněno v popisu standardu. - 17 -

2.1.5 NahGen Tato funkce je využita v hlavní části skriptu modelu, kde je volána k náhodnému vygenerování zda chce uzel v daný bitový čas vysílat nebo ne. Vstupem funkce je střední hodnota rámců za sekundu, která se přepočte na střední hodnotu za bitový čas a na základě této střední hodnoty je generován výstup. K tomu je zde použita MATLAB funkce rand, která slouží jako pseudonáhodný generátor čísel od 0 do 1 v rovnoměrném rozdělení. Abych dosáhnul generování čísel v požadované střední hodnotě, je k výstupu funkce přičten rozdíl požadované střední hodnoty a střední hodnoty rovnoměrného rozdělení v intervalu od 0 do 1, tedy 0,5. 2.2 Simulace Jak bylo popsáno výše, k simulaci byly zvoleny parametry tak, aby vše odpovídalo poloduplexnímu režimu s rychlostí přenosu 100 Mbit/s. Schéma je vidět na Obr. 2.1. Legenda Symbol Počet Popis 1 Ethernet 10 Osobní počítač Obr. 2.1: Schéma znázorňující simulovanou strukturu - 18 -

2.2.1 Výsledky simulace 4.5 x 105 4 3.5 3 doba přenosu [ s] 2.5 2 1.5 1 0.5 0 1 2 3 4 5 6 7 střední hodnota počtu rámců/s x 10 4 Obr. 2.2: Graf závislosti doby přenosu na střední hodnotě počtu rámců Simulace byla provedena pro 4 různá zatížení pomyslné sítě. Je vidět, že do 30000 rámců za sekundu je doba přenosu dost nízká. Při 50000 je stále ještě únosná, ale již se začínají množit ztráty paketů a celková propustnost sítě tak klesá. Při 70000 rámcích za sekundu je již doba přenosu závratná a moc rámců k cíli nedorazí. Dobou přenosu je myšlena doba od vzniku požadavku u konkrétní stanice do okamžiku dokončení přenosu rámce. Tento význam bude používán i dále. Tab. 2.1: Tabulka průměrných hodnot ze simulace vynášených do grafu Zatížení [pkt/s] 10000 30000 50000 70000 Doba přenosu [μs] 6,2252 11,4353 10591 415973-19 -

3 Ověření modelu na reálném systému Z důvodu vhodnosti ověření modelu v reálu byla v laboratoři provedena měření. 5x vysílající PC Rozbočovač Přijímající PC Obr. 3.1: Schéma znázorňující reálné měření Na Obr. 3.1 je znázorněno, jak probíhalo měření. Provedeno bylo za pomoci 6 stejných počítačů zapojených do obyčejného rozbočovače (hubu) o rychlosti 100 Mbit/s UTP kabely. Pět počítačů bylo určeno na vysílání rámců a šestý na příjem. K obsluze měření byla použita aplikace vytvořená na katedře měření k měření na zarušené síti, kde sloužila k vysílání a kontrole přenosu. Tato aplikace byla upravena tak, aby vyhovovala potřebám tohoto měření. Původní aplikace i upravené verze jsou dostupné na CD příloze. 3.1 Aplikace k měření Program je naprogramován v jazyce C a některé jeho části v assembleru. Je určen pro systém MS-DOS, protože tím je zajištěn relativně nízkoúrovňový přístup k odesílání a příjmu rámců. Výsledky tak nejsou ovlivněny vyššími vrstvami, službami systému apod. Jako ovladač pro MS-DOS se používá tzv. Packet Driver, což je typ ovladače síťového adaptéru poskytujícího přímý přístup ke spojové vrstvě - 20 -

ISO/OSI modelu a je tak rozhraním k přímému přístupu k odesílání a příjmu rámců. Podrobná specifikace viz [8]. Nejprve bylo potřeba v programu vyřešit časování s přesností na mikrosekundy. Nějaké funkce na časování již zde byly, ale nebyly dostatečně přesné. 3.1.1 Časování Využito bylo čipu časovače 8253/8254, který je přítomný u všech dnešních počítačů XT/AT. Systémový takt o velikosti 14,31818 MHz je dělen dvanácti, což dává frekvenci 1,19318 MHz, která taktuje 3 kanály časovače 8253/8254. Ten dělí tuto frekvenci na 3 různé a poskytuje tak 3 výstupní signály ve třech kanálech. Kanál 0 poskytuje signál přerušení pro čip 8259, který slouží jako kontrolér přerušení a generuje přerušení časovače s periodou 54,9254 milisekundy. Toto přerušení je používáno např. systémovým časem. BIOS má v paměti na adrese 0040:006C čítač ( BIOS tick count ), který počítá přerušení právě s periodou 54,9254 milisekundy od půlnoci do půlnoci a slouží k určení času v DOSu. Proměnná je 32 bitů dlouhá, avšak jen 21 bitů je používáno (max. hodnota je 1800AF hexadecimálně). Kanály 1 a 2 jsou také použitelné pro časování. Kanál 1 slouží k obnovování DRAM paměti. Kanál 2 generuje zvuk pro PC speaker. Každý kanál pracuje nezávisle na ostatních, má hradlový a časovací vstup, výstup a každý má pro sebe určité registry. Módový registr slouží k nastavení operačního módu kanálu. Vždy při nastavení se všechny hodnoty vyresetují a výstup vrátí na počáteční stav. Mód 0 nastavuje chování tak, že časovač čeká, dokud není hodnota v překládacím (reload) registru naplněna softwarem. Poté je při následujícím tiku časovače hodnota z tohoto registru předána do počítacího registru. Hodnota v tomto registru je zmenšována, pokud je na hradlovém vstupu úroveň vysoká. Pokud je úroveň nízká, není hodnota zmenšována. Potom, co se dostane hodnota v tomto počítacím registru na 0, je hodnota na výstupu změněna z nízké úrovně na vysokou. Hodnota v překládacím registru může být přepisována kdykoliv. Je možné definovat 3 módy přístupu do tohoto registru Lobyte, Hibyte a Lobyte - 21 -

i Hibyte. Při prvních dvou režimech dochází k využívání jen jednoho bytu registru, kdežto při třetím dochází k automatickému přepínání mezi oběma a využívají se střídavě oba. V operačním módu 0 a při nastaveném dvoubytovém režimu přístupu dochází k zastavení čítání po zápisu do prvního bytu a k načtení hodnoty z překládacího registru a ke startu počítání až po zápise i do druhého bytu. Ostatní módy se liší ve funkčnosti, nicméně je již popisovat nebudu. Popíši akorát mód 2, který používám v aplikaci pro měření k časování. Kanál se chová jako dělič frekvence. Hodnota v překládacím registru je dělitelem, kterým je dělena frekvence čítače a výsledek je výstupem. Počítací registr začíná čítat na hodnotě překládacího registru a ta je zmenšována až na hodnotu 1 a potom se obnoví. Výstup je na nízké úrovni při hodnotě 1 v počítacím registru. Takže pulsy výstupu jsou na frekvenci 1,19 MHz děleno hodnotou překládacího registru. Dělitelem je implicitně hodnota 65536. Ke čtení hodnoty z počítacího registru není možné přistupovat přímo, ale děje se tak skrze další tzv. latch registr. Tento registr přímo sleduje hodnotu v počítacím registru, dokud není zastaven příslušným příkazem. Tuto stabilní hodnotu je pak možno přečíst skrze datový port. Jakmile je hodnota z latch registru vyčtena, tento registr dále pokračuje ve sledování hodnoty počítacího registru. I/O adresy datového portu jednotlivých kanálů jsou: Kanál 0-40h Kanál 1-41h Kanál 2-42h Byte na adrese 43h je vyhrazen k nastavení kanálu, operačního módu, módu přístupu a formátu (BCD kód nebo binární formát). Ve svém programu používám tedy kanál 0, operační mód 2, mód přístup Lobyte/Hibyte a binární formát. To je zajištěno hexadecimální hodnotou 0x34 zapsanou na adresu 43h. K získání absolutní časové značky ( timestamp ) používám již výše zmíněnou BIOS proměnnou čítače ( BIOS tick count ) 32 bitů dlouhou a 16 bitů dlouhou hodnotu z časovače 8253/8254. Postup je takový, že nejdříve se přečte hodnota z BIOS čítače, poté hodnota z časovače, povolí se přerušení a přečte se další hodnota z BIOS - 22 -

čítače. Pak se zkontroluje jestli je jedna či druhá hodnota z BIOS čítače adekvátní pokud jsou obě rozdílné. K odměřování uběhlého času, který potřebuji jak pro odesílání rámců s danou prodlevou, tak i poté při příjmu k odměření doby přenosu používám funkci, která vrátí v jednotkách 0,8381 mikrosekundy diferenci mezi dvěma časovými značkami. Je pamatováno i na problém při případné změně dne, tj. v případě že konečná značka je menší než ta počáteční. Informace o časování jsem čerpal z [9]. 3.1.2 Ostatní části programu Funkční část byla vymyšlena tak, že odesílající stanice posílají pakety s danou prodlevou v počtu mikrosekund. Časová značka při vzniku požadavku je vložena na začátek datové části rámce a rámec je odeslán. Rámec je poté přijat přijímající stanicí a z něj je přečtena časová značka vzniku požadavku na odeslání a zároveň je zaznamenána časová značka, kdy byl rámec obdržen. Je zřejmé, že bylo nutné zajistit časovou synchronizaci všech zúčastněných počítačů, jelikož každý může mít aktuální čas ve stejnou dobu mírně odlišný. Kvůli tomu bylo v aplikaci uděláno to, že aplikace nejprve před zahájením přijme rámec, který je na začátku datové části označen speciální posloupností a okamžik příjmu tohoto rámce je prohlášen za počáteční čas a od té doby je vše počítáno od tohoto počátečního času. Měření tedy bylo realizováno tak, že byl k rozbočovači připojen ještě další počítač, z kterého byl klasicky ze systému Windows odeslán paket prostřednictvím programu umožňujícího sestavit si paket podle přání a odeslat ho. Jako cílová adresa daného paketu byla zadána broadcast adresa, takže paket došel všem stanicím najednou ve stejnou dobu a to zajistilo sesynchronizování času všech počítačů. Z původní aplikace bylo ponecháno vytvořené rozhraní pro výpis na obrazovku, odeslání a příjem paketu a komunikaci s Packet Driverem. Byly vytvořeny 2 verze upravené aplikace. Jedna pro odesílající počítače a druhá pro přijímající. Každá byla upravena na míru tak, aby dělala jen to, co je potřeba. - 23 -

Odesílající program (pod názvem stations ) byl udělán tak, že po nastavení konfigurace- počtu paketů a intervalu mezi nimi a po přijetí onoho synchronizačního rámce potvrdí synchronizaci času. Poté se příslušnou klávesou zahájí vysílání paketů a od té doby je zastaven výpis na obrazovku tak, aby nebyl průběh odesílání nijak zpomalován a znepřesňován. Přijímající aplikace ( receiver ) je zase připravena tak, že stejně jako odesílající potvrdí synchronizaci času po přijetí onoho příslušného rámce. Poté čeká na příjem a po dobu naplnění datové struktury nebo do přerušení příslušnou klávesou je výpis na obrazovku také potlačen tak, aby nevznikaly žádné prodlevy. Výstupem je poté soubor s informacemi o nastavení a výsledkách měření. Obsaženy jsou 3 sloupce, které obsahují časové značky vzniku požadavku na odeslání paketu, časové značky přijetí paketu a jejich rozdíl. Zdrojové kódy obou upravených aplikací i původní aplikace jsou umístěny na CD příloze. 3.1.3 Výsledky měření Tab. 3.1: Výsledky reálného měření Zatížení [pkt/s] 10000 30000 50000 70000 Doba přenosu [μs] 8,1 20,42 12454 401515 Měření bylo provedeno tak, jak bylo uvedeno výše. Průměrné hodnoty jsou opět vidět v Tab. 3.1. Na Obr. 3.2 je znázorněno porovnání simulace a měření. Pokud hodnoty porovnáme, tak vidíme, že hodnoty simulace až na poslední hodnotu vyšla o něco nižší než ve skutečnosti. To může být způsobeno nenulovou reakční dobou počítače nebo případně menší chybou při synchronizaci časů všech stanic na počátku měření. - 24 -

4.5 x 105 4 3.5 doba přenosu [ s] 3 2.5 2 1.5 simulace měření 1 0.5 0 1 2 3 4 5 6 7 střední hodnota počtu rámců/s x 10 4 Obr. 3.2: Porovnání výsledků reálného měření a simulace 700 600 doba přenosu [ s] 500 400 300 200 100 simulace měření determ. 0-100 -200 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3 3.2 střední hodnota počtu rámců/s x 10 4 Obr. 3.3: Detail porovnání determ. systému s naměřenými a nasim. daty - 25 -

4 Porovnání s deterministickými přístupy Základní deterministickou přístupovou metodou je tzv. Master-Slave nebo Server-Klient. Tato přístupová metoda je použita např. u AS- Interface distribuovaného (FieldBus) systému [10]. Jedná se o to, že jedna stanice je Master a ostatní Slave, při čemž Master periodicky oslovuje jednotlivé Slave stanice. Slave stanice mohou vysílat pouze, když jsou osloveny Master stanicí. Slave stanice odpoví ve specifikovaném časovém úseku. Mezi Master požadavkem a Slave odpovědí je pauza, stejně jako po odpovědi Slave uzlu. Pauza před odpovědí Slave stanice může být maximálně tak dlouhá, jako očekávaná odpověď. Pokud do té doby není obdržena Master uzlem odpověď, může Master pokračovat dalším požadavkem. Pokud by se implementovala tato metoda tak, že bychom měli 10 stanic a rámce by byly minimálně dlouhé 72 bytů, tak jak požaduje Ethernet s tím, že zachováme pauzu mezi rámci, tak jak je definovaná v Ethernetu dostaneme: 576 96 2 1344 bitů To odpovídá délce jednoho cyklu požadavek-odpověď 13,44 s při rychlosti 100 Mbit. Při zohlednění doby doručení signálu přes médium přičteme ještě 1 s pro požadavek i odpověď. Tím dostáváme zhruba 15 nebo 16 s. Pro 10 uzlů tedy trvá cyklus oběhnutí celé sběrnice 160 s. Průměrná doba čekání na odeslání dat je tedy asi 80 s. Pokud budou dodržovat všechny uzly tuto metodu, jsou kolize prakticky vyloučené, protože provoz je řízen Master uzlem. Maximální datová propustnost takovéto sítě by byla 36 Mbit/s pokud počítáme jako data jen ta od Slave stanic, jinak je dvojnásobná. Z hlediska porovnání s našimi daty ze stochastického systému nás zajímá průměrná doba přenosu. Jestliže zde máme průměrnou dobu čekání na odeslání 80 s, odpovídá tomu po přičtení doby přenosu rámce skrze médium průměrná doba přenosu zhruba 86 s. Pokud to srovnáme s výsledky simulace, zjistíme, že deterministický systém se nám začíná vyplácet z hlediska průměrné doby přenosu zhruba při zatížení média 40000 rámců za sekundu a více, viz srovnávací graf na Obr. 3.3. - 26 -

5 Závěr Tato práce se zabývala Ethernetem a jeho možným nasazením v realtime aplikacích. Obsahuje model, výstupy simulace a reálného měření na síti Ethernet. Práce obsahuje také specifikaci standardu Ethernetu (IEEE 802.3). Poměrně podrobně popsané chování, tak jak předepisuje standard. A je zde i přehledný výčet různých podstandardů Ethernetu a jiných. Je zde popsán i způsob poměrně přesného časování v řádu mikrosekund potřebného k měření v DOSu. Práce se dotkla i průmyslových sběrnic a deterministického systému přístupu k médiu. Zdrojové kódy jak všech funkcí v rámci vytvořeného modelu, tak i aplikace vytvořené a použité k naměření hodnot na reálné síti jsou přiloženy na CD. Hodnoty v porovnání modelu s realitou vyšly téměř shodně. Jedinou větší nevýhodou modelu je, že ač jsem se snažil a použil částečně nelineárního času simulace, jeho výpočty jsou relativně dosti pomalé. Odpovědí na zadání, tedy nalezení kritéria přechodu od stochastické metody CSMA/CD k deterministickému systému, je kritérium v podobě vytížení media kolem 40-50 tisíc paketů za sekundu. V reálném použití by se jednalo o model chování takový, že by byla klasicky realizována metoda přístupu CSMA/CD. Protože je médium sdílené a všechny uzly tak naslouchají a mají přehled o přenášených rámcích, je možné, že by vyhodnocovaly průběžně vytížené média a jakmile by došlo k překročení této prahové hodnoty, tak by došlo k přepnutí a např. jeden z uzlů by byl předem určen jako ten, který bude prohlášen za Master a bude deterministicky řídit probíhající přenos. Po poklesu vytížení by se opět aktivoval přenos s náhodnou přístupovou metodou k médiu. - 27 -

Seznam použité literatury [1] Zezulka F., Hynčica O.: Průmyslový Ethernet I: Historický úvod. Automa, 2007, roč. 13, č. 1, s. 41 43 [2] Zezulka F., Hynčica O.: Průmyslový Ethernet IV: Principy průmyslového Ethernetu. Automa, 2007, roč. 13, č. 10, s. 57 60 [3] Cisco Systems, Inc.: Ethernet. http://www.cisco.com/en/us/docs/internetworking/technology/handbook/ethern et.html [4] Ethernet. http://en.wikipedia.org/wiki/ethernet [5] IEEE 802 Working Group. http://grouper.ieee.org/groups/802/dots.html [6] Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. IEEE Std 802.3-2005 [7] The MathWorks, Inc.: MATLAB Documentation. http://www.mathworks.com/access/helpdesk/help/techdoc/index.html [8] FTP Software, Inc.: PC/TCP Packet Driver Specification. http://www.crynwr.com/packet_driver.html [9] Heidenstrom K.: Timing on the PC family under DOS. ftp://ftp.coast.net/simtel/msdos/info/pctim003.zip [10] AS-Interface: AS-Interface system description. http://www.asinterface.net/system/ [11] Kocourek P., Novák J.: Přenos informace. Praha 2004. ISBN 80-01-02892-5 - 28 -

[12] Dolejš O., Hanzálek Z., Smolik P.: On The Ethernet Use for Real-Time Publish-Subscribe Based Applications. http://dce.felk.cvut.cz/hanzalek/publications/hanzalek04e.pdf [13] Dolejš O., Hanzálek Z.: Simulation of Ethernet for Real-Time Applications. - 29 -

Struktura CD přílohy Název Cesta Velikost Popis RECEIVER.CPP cd\mereni\ 49746 Měření- aplikace příjímací stanice STATIONS.CPP cd\mereni\ 49400 Měření- aplikace vysílající stanice PACKET.TXT cd\mereni\pktdrv\ 3629 Packet Driver RTSPKT.COM cd\mereni\pktdrv\ 33744 Packet Driver ETHERNET.DAT cd\mereni\puvodni_apl\ 4858 Původní aplikace OLD.!!! cd\mereni\puvodni_apl\ 12 Původní aplikace PKTTEST.DSK cd\mereni\puvodni_apl\ 2782 Původní aplikace PKTTEST.EXE cd\mereni\puvodni_apl\ 56539 Původní aplikace PKTTEST.PRJ cd\mereni\puvodni_apl\ 4250 Původní aplikace PROG.CPP cd\mereni\puvodni_apl\ 48527 Původní aplikace backoff.m cd\simulace\ 387 Funkce modelu ethernet.m cd\simulace\ 7812 Funkce modelu nahgen.m cd\simulace\ 489 Funkce modelu transmitframe.m cd\simulace\ 1395 Funkce modelu uzel1.m cd\simulace\ 4052 Funkce modelu uzel10.m cd\simulace\ 4052 Funkce modelu uzel2.m cd\simulace\ 4052 Funkce modelu uzel3.m cd\simulace\ 4052 Funkce modelu uzel4.m cd\simulace\ 4052 Funkce modelu uzel5.m cd\simulace\ 4052 Funkce modelu uzel6.m cd\simulace\ 4052 Funkce modelu uzel7.m cd\simulace\ 4052 Funkce modelu uzel8.m cd\simulace\ 4052 Funkce modelu uzel9.m cd\simulace\ 4052 Funkce modelu BP.pdf cd\ PDF s prací - 30 -

Seznam použitých zkratek AUI CRC CSMA/CD DIX EEE EOS EPON FOIRL IEEE ISO LAN LLC LRM LSB MAC MBWA MDI MIB MII MSB OSI PCS PLS PMA PMD SFD UTP VLAN WPAN Attachment Unit Interface Cyclic Redundancy Check Carrier Sense Multiple Access with Collision Detection DEC, Intel, Xerox Energy Efficient Ethernet Ethernet over SONET/SDH Ethernet Passive Optical Network Fiber-optic inter-repeater link The Institute of Electrical and Electronics Engineers International Organization for Standardization Local Area Network Logical Link Control Long Reach Multimode Least significant Bit Media Access Control Mobile Broadband Wireless Access Media Dependent Interface Management Information Base Media Independent Interface Most significant Bit Open System Interconnection Physical Coding Sublayer Physical Layer Signalling Physical Medium Attachment Physical Medium Dependent Start Frame Delimiter Unshielded twisted pair Virtual LAN Wireless Personal Area Network - 31 -