BC:xvykopa1

Z FI WIKI
Přejít na: navigace, hledání

Úvod

V dnešní době je kladen velký důraz na používání počítačových a komunikačních technologií ve všech odvětvích lidské činnosti. Moderní aplikace neustále vyžadují lepší a výkonější hardware a rychlejší komunikační kanály, aby zajistily přenos velkých objemů dat. Např. kvalitní multimediální vysílání si vynucuje použití téměř ideální počítačové síťě, takové sítě, která by zajišťovala neomezenou propustnost dat a jejich nulové zpoždění. Jak se můžeme přiblížit této nedosažitelné kvalitě sítě? Při návrhu stě bychom měli vycházet z předpokladu, že kvalita celku závisí na kvalitě jednotlivých prvků. Nesmíme tedy podcenit výběr prvků síťové infrastruktury. Kritéria výběru jsou různorodá -- od ekonomických, přes strategická, až po čistě technická. Posledně zmíněnými se zabývá tato práce. V průběhu několika desetiletí vznikla celá řada doporučení a testovacích nástrojů, které se snažily reagovat na prudký rozvoj celého odvětví. Např. často skloňovaný a dnes už i nasazovaný protokol IPv6 si vyžádal revizi těchto doporučení a úpravu testovacích nástrojů. Pro správce počítačových sítí je důležité znát základní charakteristiky použitých prvků, pro vývojáře těchto prvků je to až životně důležité. Výsledky testování výkonu jejich produktů za stejných podmínek jako byly testovány ostatní výrobky často rozhodují o další práci.

Projekt Liberouter

Původním cílem projektu LiberouterLiberouter bylo vyvinout vysokorychlostní směrovač na bázi PC s podporou IPv4 a IPv6 se zcela otevřenými zdrojovými kódy (software i firmware). Běžné směrovače na bázi PC používají standardně vybavený osobní počítač a příslušný software, který přijímá datové pakety, zpracovává je a odesílá do příslušné sítě. Veškerá data tedy putují ze síťové karty přes sběrnici do paměti. V dnešní době je v běžných osobních počítačích rozšířena sběrnice PCI v různých variantách. Původní šířka sběrnice je 32 bitů a taktovací frekvence 33 MHz. Novější počítače disponují PCI sběrnicí o šířce 64 bitů a frekvenci 66 MHz. Teoretická propustnost je tedy kolem 500 Mb/s u první verze a 1 Gb/s u druhé (musíme počítat dva průchody datového paketu sběrnicí). Ovšem tyto hodnoty jsou v praxi nižší. Efektivita využití PCI sběrnice je malá, asi 50 % datových přenosů připadá na režijní operace. Projekt Liberouter jde jinou cestou. Využívá hardwarový akcelerátor COMBO6 obsahující programovatelný hardware. Firmware je naprogramován v jazyce VHDL (VHSIC Hardware Description Language) a přímo vykonává operace, které musejí být provedeny co nejrychleji, např. filtrování paketů. Data tedy neputují po pomalé sběrnici, ale jsou zpracována přímo na kartě. Ostatní operace, které nespěchají, má na starosti software počítače. Akcelerační karta je pro operační systém transparentní. Lze tedy používat běžné systémové příkazy jako route aj. Spojení běžného osobního počítače a hardwarového akcelátoru využívá výhod obou paradigmat. Poskytuje výkon drahého hardwarového směrovače v cenové hladině softwarového směrovače. Postupem času se objevily nové aplikace a krom původního projektu Liberouter vznikly další projekty: NIC (síťová karta), NIFIC (síťová karta s hardwarový filtrováním, zasíláním a replikací paketů), FlowMon (pasivní sonda sledující síťové rozhraní) a další. Moje práce v projektu Liberouter spočívá v testování nejrůznější charakteristik vyvíjených zařízení. Dále mám za úkol vyvinout sadu skriptů pro automatizaci testování, které by pak mohli provádět sami vývojáři. Celý proces testování by se tak podstatně zjednodušil a zrychlil.

Obsah práce

První kapitola obsahuje tento úvod. Přehled důležitých dokumentů, které klasifikují a popisují nejrůznější typy testů, je obsahem druhé kapitoly. Nejprve jsou zrekapitulovány a komentovány dokumenty vydané dvěma pracovními skupinami celosvětové organizace Internet Engineering Task Force (IETF), které se zaměřují na podobnou problematiku. Na závěr je provedeno srovnání textů vydaných oběma skupinami.

Typy testů

Výrobci prvků síťové infrastruktury mají jasný cíl – prodat co nejvíce svých produktů, zvítězit nad konkurencí. Tvrdý konkurenční boj s sebou přináší i různé zkreslování a zatajování vlastností jednotlivých produktů. Každý výrobce používá svoji sadu testů. Jednotlivé typy testů a způsob jejich provádění je navržen tak, aby testovaná zařízení dosahovala co nejlepších výsledků. Zákazník tedy nemá možnost objektivně porovnávat produkty různých výrobců. Máme-li dnes na mysli síť, je to internet. Již od počátku jeho vývoje bylo užitečné navrhnout a používat standardy. Proto také vzniklo sdružení výzkumníků, vývojářů, návrhářů, výrobců a uživatelů internetových technologií s názvem Internet Engineering Task Force (IETF) a jeho pracovní skupiny Benchmarking Methodology Working Group (BMWG) a IP Performance Metrics Working Group (IPPM). Obě skupiny se snaží popsat různé metodiky provádění testů včetně jednoznačné prezentace naměřených hodnot. BMWG se zaměřuje spíše na probematiku testování jednoho či několika málo zařízení, zatímco IPPM na testování sítě jako celku. Tyto pracovní skupiny vydávají Request For Comments (RFC), což jsou de facto internetové standardy. Dodržování standardů různými produkty výrobců prvků síťové infrastruktury vede ke snadnému porovnávání jejich vlastností a parametrů.

Dokumenty pracovní skupiny BMWG

RFC 1242

Prvním dokumentem, který BMWG publikovala byl již v roce 1991 RFC 1242 Benchmarking Terminology for Network Interconnection DevicesRFC 1242. Krom definic klíčových pojmů jako je např. propustnost nebo zpoždění obsahuje i definice zdánlivě zřejmé: směrovač (router), most (bridge) či konstatní zátěž. Právě na definicích těchto elementárních pojmů staví další definice a následující dokumenty. Autoři se tedy snaží předcházet nejednoznačnosti při intepretaci.

RFC 1944

O pět let později, v roce 1996, byl vydán další důležitý dokument – RFC 1944 Benchmarking Methodology for Network Interconnect DevicesRFC 1944. Obsahuje popis výkkonostních testů síťových zařízení včetně jednoznačné prezentace výsledků. To opět napomáhá jednoznačnosti porozumění. Dále je kladen důraz na zopakovatelnost testů. Výsledky pak mají určitou vypovídací hodnotu. Stejně jako v ostatních RFC, se i v tomto ve specifikacích důsledně rozlišuje např. mezi výrazy musí, požaduje, měl by, volitelné. Na základě míry splnění těchto požadavků pak testy částečně nebo úplně vyhovují specifikacím v tomto dokumentu. To je další důležitá informace pro uživatele. Následuje popis zapojení testovaného zařízení (DUT, device under test) a zamyšlení nad propojováním různorodých síti. V celém dokumentu se díváme na testované zařízení jako na blackbox, nezajímá nás vnitřní struktura a zapojení a jak se v data v daném zařízení zpracovávají. Do zařízení posíláme data (tj. vstupy) a dostáváme data nebo jejich statistiky (tj. výstupy). Na základě jejich porovnání prohlásíme zda, zařízení testem prošlo nebo jaké jsou jeho výkkonostní charakteristiky. Komplementární přístup, kdy sledujeme, co se děje uvnitř zařízení, tj. jak jednotlivé vnitřní moduly nakládají s daty, se nazývá whitebox. Tento typ testování se používá při návrhu a ladění jednotlivých komponent vyvíjeného zařízení, přístup blackbox pro testování v konečné fázi vývoje produktu. Další část je věnována nastavení zařízení. Konfigurace musí proběhnout přesně tak, jak bylo sděleno uživateli. Dále se očekává, že budou zprovozněny a do testu zahrnuty všechny protokoly, které daný prvek síťové infrastruktury podporuje. Více informací podává dodatek A, který plní pouze informativní funkci, není závazný. Osmá část odkazuje na dodatek C, jenž obsahuje definice formátu rámců a datagramů používaných na Ethernetu. Zvláštní případy, tzn. definice, které nejsou součástí dodatku C, musí být zahrnuty jako nedílná součást testovací zprávy. Velikost rámců je další téma tohoto RFC. Všechny popisované testy by měly být provedeny několikrát, nejméně s pěti různými délkami testovacích rámců. Zejména by měly být do testování zahrnuty rámce s nejmenší resp. největší délkou, kterou připouští příslušný protokol. Interval mezi délkami má být dostatečný. Pro různá média jsou určeny různé délky. Např. pro Ethernet je to 64, 128, 256, 512, 1024, 1280 a 1518 bajtů. Dále je diskutována velikost rámců v závislosti na MTU (Maximum Transmission Unit) a fragmentaci. Při ověřování příchozích rámců, musíme dbát na to, aby nebyly do celkového počtu přijatých zahrnuty např. pakety obsahující směrovací informace či ARP dotazy. V každém případě bychom měli kontrolovat, zda se shodují délky vyslaných a přijatých rámců. V některých testech záleží i na pořadí rámců. Pokud každý rámec obsahuje unikátní číslo (rámce pak tvoří sekvenci), můžeme sledovat pořadí, v jakém se vrátily zpět, zda nedošlo po cestě k jejich duplikaci nebo ztrátě. V některých případech je užitečné znát výkon testovaného zařízení za určitých podmínek. Např. pokud testujeme propustnost směrovače, zaměříme se na potenciálně problémovou oblast. Tou může být všesměrové vysílání a proto každý stý rámec, který vysíláme na směrovač, obsahuje všesměrovou cílovou adresu (tzv. broadcast frame). Nebo můžeme sledovat, zda směrovač odpovídá na dotazy definované protokolem správy sítě, např. SNMP. Důležitou roli hraje též úprava směrovacích informací nebo správná funkce bezpečnostních filtrů směrovače. Tato pravidla rozhodují o průchodu paketu směrovačem na základě zdrojových a cílových adres. Pokud testovací zařízení umožňuje generovat síťový provoz, jenž vyhovuje dané podmínce, měli bychom do testování zahrnout co nejvíce takových podmínek a provozů. Jestliže splníme tento požadavek, celý testovací proces bude časově náročný. Před začátkem testování s dodatečnými podmínkami bychom měli testovat zařízení bez těchto podmínek a pak teprve každou podmínku zvlášť. Další část textu je zaměřena na adresy používané v testovacích paketech. Pro jednoduchost se doporučuje začít pouze s jedním testovacím tokem dat, tj. je použita právě jedna zdrojová a cílová adresa. Autoři upozorňují na zřejmý fakt, že v reálných sítích je takových toků mnohem víc. Proto je vhodné použít náhodně generované cílové adresy nebo rovnoměrné rozložení těchto adres. Bližsí informace o adresách v IP datagramech nalezneme v dodatku C. Až doposud jsme měli na mysli jednosměrný provoz. Avšak v reálné síti je velmi časté, že data tečou oběma směry. Pokud má testované zařízení více portů, každý port bychom měli testovat zvlášť. Odhalíme tak případnou chybu, který se vyskytuje pouze na některém z daných portů. Také bychom měli vytvořit takový provoz, jenž testované zařízení přijme na různých vstupních portech a pošle na stejné výstupní porty ve stejném okamžiku. V tomto dokumentu nejsou nijak specifikovány testy probíhající na různých protokolech současně. Podobně je tomu tak u různých délek rámců v jednom testu. Jediný požadavek je vznesen na použití délek rámců, tak jak byly deklarovány v předcházejícím textu. Na propojení více testovaných zařízení sítí nahlížíme jako na jedno zařízení. To je tzv. end-to-end přístup. Musíme ale brát v úvahu, že jsou v síti další prvky, které např. zanáší do přenosu dat určité zpoždění. Dále by měla být v testech použita maximální rychlost zasílání rámců dané délky na daném médiu. Konkrétní hodnoty pro konkrétní média udává dodatek B. Např. u hodnot pro Ethernet musíme být obezřetní. Stuart Johnson upozorňuje ve svém komentářiJohnson na skutečnost, že speficikace IEEE 802.3 povoluje odchylku hodinového taktu +-0,01 %. Není tedy zaručeno, že všechna zařízení zvládnou zpracovat maximální hodnoty uvedené v dodatku B. Takže ztráta 0,02 % všech zaslaných paketů je povolená. Shlukový provoz (bursty traffic) je dalším tématem tohoto RFC. Autoři konstatují, že je tento typ provozu bližší skutečnému a doporučují jej generovat i kromě provozu s konstantní zátěží. Rámce uvnitř shluku mají být poslány po sobě, s co nejmenší mezerou. Cílem tohoto testu je zjistit takový interval mezi shluky, při kterém není ztracen žádný rámec. Shluky jsou tvořeny 16, 64, 256 nebo 1024 rámci. Každá sada testů se skládá z několika dílčích testů. Postup provádění těchto dílčích testů je následující:

  • pokud je testované zařízení směrovač, pošleme směrovací informace na vstupní port a počkáme 2 sekundy
  • zašleme rámce, které naučí testované zařízení, kam má posílat testovací rámce; např. protokol ARP plní tuto funkci v rodině protokolů IPv4
  • pokud je testované zařízení směrovač, pošleme směrovací informace na vstupní port a počkáme 2 sekundy
  • zašleme rámce, které naučí testované zařízení, kam má posílat testovací rámce; např. protokol ARP plní tuto funkci v rodině protokolů IPv4
  • spustíme samotný test a čekáme nejméně 60 sekund; v některých případech časově náročných testů je povoleno tuto dobu zkrátit, ale je výsledek je třeba ověřit testem trvajícím celých 60 sekund
  • vyčkáme 2 sekundy na poslední příchozí rámce
  • nejméně 5 sekund ponecháme zařízení na stabilizaci

Po definicích nejrůznějších podmínek a specifikací provádění testů se konečně dostáváme k popisu samotných testů.

Test propustnosti

Tento test má za úkol zjistit propustnost definovanou v RFC 1242, tj. maximální rychlost zasílání paketů, při které nejsou zahozeny žádné odeslané pakety. Způsob prováděníDo testovaného zařízení vyšleme určitou rychlostí určitý počet rámců a sledujeme počet rámců vyslaných nebo zpracovaných testovaným zařízením. Pokud je počet vyslaných rámců stejný jako počet přijatých, zvýšíme vysílací rychlost a test opakujeme. Jestliže je počet přijatých rámců nižší, snížíme rychlost a test opět opakujeme. Propustnost je tedy nejvyšší rychlost (v rámcích za sekundu), při níž je roven počet vyslaných a přijatých rámců.

Testovací zprávaVýsledky testování by měly být prezentovány formou grafu. Na ose x jsou vyneseny délky rámců, na ose y rychlost v rámcích za sekundu. Graf se skládá nejméně ze dvou křivek. První zobrazuje maximální teoretickou rychlost pro dané médium a druhá výsledky testu – naměřenou propustnost. Další křivky mohou ukazovat výsledky pro určitý testovací tok.

Příklad grafu zachycujícího výsledky testu propustnosti dle RFC 1944

Doprovodný text má informovat o použitém protokolu, formátu testovacího toku a typu média. Autoři RFC předpokládají, že pokud bude použita pouze jediná hodnota k propagačním účelům, bude to právě ta, při které zařízení dosahuje největšího výkonu. Obvykle se tak děje na nejkratších rámcích. Tato hodnota musí být udána v rámcích za sekundu, volitelně pak v bitech či bajtech za sekundu. Závěr musí obsahovat nejvyšší naměřenou hodnotu, velikost rámce, na níž byla zjištěna, teoretickou maximální rychlost média pro danou velikost rámce a typ protokolu použitého v testu. Technická specifikace (datasheet) zařízení má obsahovat úplnou tabulku výsledků. DiskuzeDokument přesně nespecifikuje, kolik rámců máme poslat na testované zařízení. Udává jen standardní délku trvání testu 60 sekund a její možné zkrácení. Exaktní počet vyslaných rámců lze jednoduše dopočítat z rychlosti zasílání. Způsob provádění testu je také popsán neurčitě. Na druhou stranu nám autoři ponechávají volnost. V praxi se osvědčilo používat algoritmus binárního půlení. Jeho asymptotická složitost je logaritmická. Podstatně se tak zkrátí doba potřebná k provedení testu. Začneme vysílat rámce polovinou maximální možné rychlosti. Pokud není žádný z nich ztracen, rozpůlíme interval mezi 50 a 100 procenty maximální rychlosti, tj. vysíláme rychlostí 75 % maxima. V opačném případě rozpůlíme interval mezi 0 a 50 procenty, tj. vysíláme rychlostí rovnou čtvrtině maximální. Takto pokračujeme až do námi určeného nejmenšího intervalu, který už nebudeme půlit, protože přesnost je vyhovující, např. 0,02 %.

Test zpoždění (latence)

Cílem testu zpoždění je najít velikost latence, tak jak je definována v RFC 1242. Zde je důležité rozlišit různé typy zařízení, existují totiž tři způsoby zpracovávání paketů:

  • celý paket je nejprve celý načten a až poté přeposlán na příslušné rozhraní, tuto techniku používají především přepínače a směrovače; zpozdění je pak definováno jako časový interval mezi průchodem posledního bitu vstupního rámce na vstupním portu a průchodem prvního bitu výstupního rámce na výstupním portu
  • paket je neprodleně zaslán na dané rozhraní, takto zachází s rámcinapř. opakovače (huby) a zařízení operující na druhé vrstvě síťového modelu ISO/OSI; latence je časový interval mezi průchodem prvního bitu vstupního rámce na vstupním portu a průchodem prvního bitu výstupního rámce na výstupním portu
  • kombinace předchozích způsobů: paket není načten celý, např. je načtena jen hlavička a už je zahájeno přeposílání; v RFC 1242 je pak doporučováno považovat zpoždění začasový interval mezi průchodem prvního bitu po preambuli (bitové výplně mezi rámci) vstupního rámce na vstupním portu a průchodem prvního bitu výstupního rámce na výstupním portu

Způsob prováděníPřed tímto testem je nutné zjistit propustnost pro rámce dané délky (pro Ethernet tedy 64, 128, 256, 512, 1024, 1280 a 1518 bajtů). Pro každou takovou délku pak vytvoříme tok testovacích rámců, jenž by měl trvat nejméně 120 sekund. Do každého toku pak po 60 sekundách vložíme jeden označkovaný rámec. Zaznamenáme čas, kdy byl tento rámec zcela odeslán. Příjmající část testovacího zařízení musí tento rámec rozeznat od ostatních v testovacím toku a zaznamenat čas jeho příchodu. Zpoždění je pak rozdíl těchto dvou časů podle výše uvedených definic. Každý test musí být proveden nejméně dvacetkrát a výsledná hodnota zpoždění je aritmetickým průměrem všech zjištěných hodnost. Testovací rámec by měl mít pokaždé jinou cílovou síť, avšak stejnou jako ostatní rámce v testovacím toku. Testovací zprávaPoužitá definice latence z RFC 1242 musí být obsažena v testovací zprávě. Výsledky mají být v tabulce, která má právě tolik řádků, kolik různých délek rámců bylo testováno. Kromě délky rámců sloupce obsahují rychlost, jenž byl posílán testovací tok, dále typ použitého přenosového média a výsledné zpoždění. DiskuzeVšimněme si, že je tento typ testu, tak jak je popsán v tomto dokumentu časově náročný. Pokud budeme testovat na Ethernetu, musíme vyjma testů propustnosti provést nejméně 7 testů, které se skládají z 20 dílčích testů. Čistý čas potřebný k provedení testů je nejméně 4 hodiny a 40 minut. Nesmíme opomenout čas potřebný ke stabilizací prostředí a zařízení, tzn. ke každému dílčímu testu musíme dle tohoto RFC přičíst celkem 7 sekund. Celkový čas provedení tohoto testu, pokud již máme výsledky testování propustnosti, je téměř 5 hodin. Uvedené definice zpoždění kladou vysoké nároky na přesnost času. Softwarové nástroje běžící na obyčejném PC mají velké potíže se zajištěním požadované přesnosti. Vzhledem k rychlostem dnešních sítí, které se pohybují v řádech gigabajtů, musejí být schopny rozlišit velmi malá časová kvanta – jednotky až zlomky mikrosekund. Z tohoto pohledu je tedy vhodnější nasadit hardwarové testovací nástroje, které disponují velmi přesnými časovacími jednotkami.

Zjištění ztrátovosti

Toto RFC opět odkazuje na defici ztrátovosti paketů (frame loss rate) z RFC 1242. Ztrátovost je tedy procentuální údaj vyjadřující kolik paketů mělo být přeneseno, avšak z důvodu nedostatku systémových prostředků testovaného zařízení tomu tak nebylo. Způsob prováděníStejně jako v testu propustnosti, tak i v tomto testu vyšleme na testované zařízení určitý počet rámců určitou rychlostí. Zařízení by mělo tyto rámce přijmout a přeposlat dále. Ztrátovost spočítáme takto:

Výpočet ztrátovosti

ztratovost = \frac{ (pocet\ zaslanych\ ramcu - pocet\ prijatych\ ramcu ) \times 100}{pocet\ zaslanych\ ramcu}

V prvním dílčím testu by měly být rámce zaslány maximální teoretickou rychlostí, kterou dané médium poskytuje. Další dílčí testy jsou prováděny s postupně se snižující rychlostí (nejvyšší krok je 10 %) až do té doby, než jsou je zjištěná ztrátovost ve dvou testech nulová. Autořo tohoto dokumentu doporučují dělat jemnější kroky než je zmíněných 10 % maximální rychlosti média.

Testovací zprávaNaměřené hodnoty by měly být zobrazeny v grafu. Na osu x je nanesena rychlost v procentech maximální možné rychlosti použitého média, na osu y ztrátovost v procentech. Obě osy musí mít rozsah 0–100 %. Graf může obsahovat více křivek, jenž mohou vyjadřovat ztrátovost např. pro různé délky rámců či použité protokoly.

DiskuzeNěkteré části testovacího proceu zjištění ztrátovosti jsou stejné jako u testu propustnosti. V obou testech zašleme rámce a sledujeme, kolik se jich vrátilo. V testu propustnosti vlastně zjišťujeme ztrátovost; hledáme rychlost zasílání, při níž je ztrátovost rovna nule (nebo téměř nule). Pokud byla naměřena vyšší než nula (nebo definovaný práh), tak snížíme rychlost zasílání a konkrétní hodnota ztrátovosti je pro nás nezajímavá. Naopak, když zjišťujeme ztrátovost, rychlost je pevně udána krokem jejího snižování.

Test back-to-back rámců

Cílem testu je zjistit, v jaké míře je testovací zařízení schopno zpracovávat back-to-back rámce. Co jsou to back-to-back rámce? Odpověď nám opět podá RFC 1242. Jsou to rámce pevné délky, které jsou vyslány za sebou. Interval mezi dvěma po sobě jdoucími rámci má být nejmenší povolený na daném médiu. Způsob prováděníDo testovaného zařízení zašleme shluk back-to-back rámců. Jestliže je počet přijatých rámců roven počtu odeslaných, zvětšíme počet rámců ve shluku. V opačném případě počet rámců snížíme. Test opakujeme. Výsledkem testu je počet rámců v nejdelším shluku, které zařízení zcela zpracovalo, tzn. nebyl ztracen žádný rámec. Každý dílčí test musí trvat nejméně 2 sekundy a měl by být opakován nejméně padesátkrát. Výsledná hodnota je rovna aritmetickému průměru dílčích naměřených hodnot. Testovací zprávaZpráva by měla obsahovat tabulku s výsledky. Počet řádků je stejný jako počet různých délek rámců, které jsme testovali. Sloupce jsou tvořeny délkou testovacího rámce a výslednou hodnotou pro každý typ testovacího toku dat. Další sloupec může obsahovat přirozenou odchylku. DiskuzeK urychlení provádění testu můžeme opět využít algoritmus binárního půlení, jenž byl popsán v diskuzi u testu propustnosti. Předem ale neznáme horní mez, kterou použijeme v tomto algoritmu. Heuristicky můžeme určit subjektivně nedosažitelnou hodnotu a pokud není zahozen žádný rámec, tak tuto hodnotu např. zdvojnásobíme. Dolní mez nám určuje požadavek, že délka testu je nejméně 2 sekundy. Pokud zařízení dosahuje horších výsledků, než při minimální délce shluku určené právě 2sekundovým trváním testu, tak je pomocí tohoto testu nezměříme.

Zotavení po přetížení

Tento test má za úkol zjistit čas, který potřebuje zařízení na zotavení se po přetížení. Způsob prováděníPřed prováděním samotného testu musíme znát propustnost pro každou délku rámce, kterou udává tento dokument. Pak začneme po dobu nejméně 60 sekund vysílat rámce 110% rychlostí zjištěnou v testu propustnosti, příp. maximální rychlostí média, pokud je 110% rychlost vyšší nex maximální. Pak snížíme tuto rychlost na polovinu a zaznamenáme čas, ve kterém jsme snížili rychlost a čas, kdy byl naposledy ztracen testovací rámec. Čas zotavení po přetížení je pak roven rozdílu těchto dvou časů. Test by měl být několikrát opakován a výsledná hodnota je pak aritmetický průměr všech dílčích testů. Testovací zprávaVýsledky testování by měly být zachyceny v tabulce. Počet řádků je stejný jako počet různých délek rámců, které jsme testovali. Sloupce jsou tvořeny délkou testovacího rámce, propustností pro každý typ toku a naměřenou hodnotou zotavení. DiskuzePři vyhodnocování tohoto testu je nutné zaznamenávat čas prvního přijatého paketu po snížení rychlosti na 50 %. Ne všechny testovací nástroje disponují takovou funkcionalitou. Předpokládejme, že je zařízení ve stavu přetížení, kdy zahazuje všechny pakety a po snížení rychlosti přejde do normálního stavu, kdy zpracovává všechny pakety. Potom můžeme čas, kdy se zařízení dostane ze stavu přetížení, vypočítat z počtu odeslaných paketů poloviční rychlostí, počtu přijatých paketů a rychlosti zasílání.

Zotavení po restartu

Cílem testu je zjistit, za jak dlouhou dobu po softwatovém a hardwarovém restartu se zařízení zotaví. Způsob prováděníStejně jako o testu zotavení po přetížení musíme před zahájením samotného testování znát propustnost. Tentokrát však jen rámců s nejmenší povolenou délkou na daném médiu. Testovací proud složený z nejkratších rámců posíláme na testované zařízení. To následně resetujeme. Sledujeme výstupní port zařízení. Zaznamenáme čas, kdy byl zaslán poslední rámec toku před restartem a první rámec po restartu. Rozdíl těchto časů je hledané hodnota. Pokud sledujeme reakci zařízení na výpadek napájení, výpadek má trvat 10 sekund. Testovací zprávaZpráva by měla obsahovat tvrzení o času zotavení pro každý typ restartu. DiskuzeV dnešní době, kdy jsou zařízení spravována vzdáleně, může nastat problém při provedení hardwarového restartu nebo simulovaného výpadku napájení. Zdánlivě časově nenáročný test se tak může protáhnout o dobu nutnou k fyzické návštěvě místa, kde je zařízení umístěno.

RFC 2544

V roce 1999 vyšel RFC 2544 Benchmarking Methodology for Network Interconnect DevicesRFC 2544, který je v podstatě druhým vydáním RFC 1944 až na jednu drobnou změnu. Tou je větší rozsah adres, které organizace IANA přidělila pracovní skupině BMWG pro potřeby testování. Autoři doporučují používat tyto adresy (192.18.0.0 až 198.19.255.255), aby se vyloučil možný únik testovacích paketů do reálné sítě při špatném zapojení.

RFC 2285 a RFC 2889

Tyto stejnojmené dokumenty (RFC 2285 Benchmarking Methodology for LAN Switching DeviceRFC 2285 a RFC 2889 Benchmarking Methodology for LAN Switching DeviceRFC 2889) navazují na předcházející texty. RFC 2285 rozšiřuje definice v RFC 1242 a RFC 1944 o pojmy z oblasti přepínání, tj. provozu na druhé, linkové vrstvě síťového ISO/OSI modelu. Zmíněné dokumenty totiž braly v úvahu spíše zařízení na vyšší (obvykle třetí, síťové) vrstvě, většinou směrovače. Přepínání je však odlišné, např. mohou nastat situace, kdy je jeden vstupní rámec přeposlán na desítky výstupních portů zařízení. Nejen takové výkonostní testy jsou popsány v druhém dokumentu, RFC 2889. Metodiky provádění těchto testů jsou navrženy důkladněji než v RFC 1944. Nechybí ani popis, jak má vypadat zpráva o proběhlém testování. Autoři opět předcházejí špatné interpretaci čtenářem.

RFC zaměřené na testování směrovačů

  • RFC 3222 Terminology for Forwarding Information Base (FIB) based Router Performance
  • RFC 4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane
  • RFC 4063 Considerations When Using Basic OSPF Convergence Benchmarks
  • RFC 4062 OSPF Benchmarking Terminology and Concepts
  • RFC 4061 Benchmarking Basic OSPF Single Router Control Plane Convergence

Dokumenty pracovní skupiny IPPM

RFC 2330

Další pracovní skupina organizace IETF, IP Performance Metrics, postupovala v počátcích stejně jako Benchmarking Methodology Working Group. Nejprve vydala v roce 1998 RFC 2330 Framework for IP Performance MetricsRFC 2330. Stalo se tak v roce 1998. Tento rámcový dokument obsahuje definice používané v dalších RFC skupiny. Dále jsou v něm uvedeny obecné požadavky na testy (např. opakovatelnost testu), určeny povolené měrné jednotky a jejich správné používání, diskutují se chyby měření (a rozdíly mezi chybami měření a měřenou charakteristikou). Tvůrci dokumentu pohlíží na danou problematiku komplexněji, uvádějí příklad, ve kterém modelují směrovač z jednodušších kompoment a na základě tohoto modelu určují sledované charakteristiky. Také se zamýšlejí nad skládání jednotlivých testů (mějme cestu skládající se z několika částí, pak výsledné zpoždění celé cesty je téměř rovno součtu zpoždění jednotlivých částí). Další část je věnována problematice přesného času v sítích. Následuje rozdělení metrik:

  • např. propustnost, i když se samotný test skládá z dílčích testů
  • tento typ metriky odebírá v předem určeném čase vzorek, používá tedy několikrát atomickou metriku; např. při testování zpozdění v jednom směru po dobu jedné hodiny provádíme dílčí měření v čase určeném Poissonovým rozložením; uvědomme si, že např. test zpoždění uváděný v RFC 2544 je vlastně také vzorkovací metrikou – podle specifikace by se měl provádět nejméně dvacetkrát, tzn. vzorkování je periodické a atomická metrika je tak jeden test zpoždění pro určitý typ rámce
  • taková metrika produkuje hodnoty pomocí statistické funkce aplikované na již naměřené hodnoty získané vzorkovací metrikou; např. hodnota aritmetického průměru všech vzorků získaných v předchozím příkladě

Ve zbylé části textu autoři rozebírají výhody a nevýhody používání různých statických rozložení používaných při měření dané charakteristiky. Poukazují na to, že periodické vzorkování nemusí postihnout veškeré chování testovaného zařízení (dokonce je může negativně ovlivnit) nebo na možnost zneužití výrobci, kteří mohou s tímto běžně rozšířeným a jednoduchým typem vzorkování počítat a záměrně tak modifikovat chování produktu. Proto navrhují používat jiné než periodické vzorkování. Takové, kde je velikost intervalu mezi jednotlivými měřeními náhodná, předem neznámá. Avšak základní vlastnost všech testů uvedená v tomto dokumentu je jejich opakovatelnost. Tu těžko můžeme garantovat, pokud je velikost intervalu zcela náhodná. Proto se používají statistická rozložení, funkce, které zaručí generování náhodných intervalů podle jistých pravidel. Tvůrci dokumentu doporučují používat vzorkování s Poissonovým rozložením, protože není předvídatelné, za jak dlouhou dobu po posledním dílčím měření proběhne další. Implementace tohoto způsobu vzorkování není triviální. Musíme disponovat generátorem pseudonáhodných čísel, který bude produkovat hodnoty v intervalu 0 až 1 s rovnoměrným rozložením. Hodnoty předložíme funkci, která spočte výslednou délku intervalu. Počkáme daný čas a provedeme měření (odebereme vzorek). Vygenerojeme další pseudonáhodné číslo a vypočteme další čas, po který budeme čekat a pak měřit atd. Tato jednoduchá technika má však své nevýhody. Měření nejsou prováděna přesně po uplynutí spočteného času. Samotné měření totiž trvá nenulový čas. Ve skutečnosti je tedy další test proveden po delší době než měl původně být. Vzorkování tudíž už nekoresponduje s Poissonovým rozložením. Samozřejmě, že lze provést další měření po čase rovnající se rozdílu délky čekacího intervalu a času měření, ale to už vyžaduje dodatečné režie – musíme měřit čas testu (toto měření nemusí být z nejrůznějších důvodů přesné). Problém nastane pokud je čas měření větší než čekací interval. Pokud můžeme provádět více měření v jednom čase (většinou to neplatí), autoři doporučují vygenerovat posloupnost intervalů a jednotlivé časy měření na začátku testování. Tím je předcházející problém vyřešen. Pro jistotu bychom měli ověřit, zda časy, ve kterých skutečně proběhlo měření, odpovídají Poissonovu rozložení. V dodatku tohoto RFC je uveden kód v jazyce C pro takovýto test. Vzorkování s Poissonovým rozložení přináší při správné implementaci jisté výhody oproti periodickému vzorkování za cenu velkých režií. V další kapitole je diskutována prezentace naměřených hodnot formou percentilů. Následuje rozprava o pravděpodobnostech v metrikách. Nedoporučuje se používat tvrzení typu pravděpodonost ztráty paketů mezi uzly A a B je 0,73, ale ztratilo se 73 paketů ze 100. První tvrzení vyznívá všeobecně, druhé je přesnější. Autoři nabádají k užívání tvrzené druhého typu, je pro čtenáře srozumitelnější.

Na základě předloženého resumé můžeme konstatovat, že tvůrci RFC 2330 využívají v testování statistický aparát, jehož pochopení a implementace klade na tvůrce testovacích nástroje další nároky. Na základech tohoto dokumentu stojí následující RFC pracovní skupiny IP Performance Metrics.

RFC 2678

O rok později, v roce 1999, vyšel RFC 2678 IPPM Metrics for Measuring ConnectivityRFC 2678. V tomto dokumentu jsou popsány základní metriky konektivity, tj. dosažitelnosti jednotlivých strojů nebo rozhraní (v jednom stroji může být více rozhraní) v určitém čase či časovém intervalu. Kromě časových údajů jsou parametry metrik zdrojové a cílové IP adresy. Dokument rozlišuje následující typy:

  • jednosměrná konektivita v určitém časovém okamžiku t
  • obousměrná konektivita v určitém časovém okamžiku t
  • jednosměrná konektivita v určitém časovém intervalu dt
  • bousměrná konektivita v určitém časovém intervalu dt
  • "obecná" obousměrná konektivita v určitém časovém intervalu dt

tento typ metriky zkoumá, zda po odeslání paketů určitého typu bude přijata odezva ve formě paketů jiného typuu; přecházející obousměrné metriky předpokládají pakety stejného typu, proto je tato metrika v jistém smyslu obecná

Hodnotou těchto metrik je binární hodnota pravda nebo nepravda. Autoří textu si uvědomují, že v případě užití navrhovovaných metod provádění metrik se spojitým časovým intervalem dochází v praxi k určité nepřesnosti a nekonzistenci s definicí: daná metodologie totiž nezkoumá konektivitu v každém časovém okamžiku, ale jen v určitých časech v daném intervalu dt.

RFC 2679 a RFC 2680

Ve stejné době jako RFC 2678 vychází i RFC 2679 A One-way Delay Metric for IPPMRFC 2679 a RFC 2680 One Way Packet Loss Metric for IPPMRFC 2680. Tyto dokumenty se věnují se měření zpoždění reps. ztrátovosti paketů, mají stejnou strukturu. Definují atomické (singleton) metriky a na nich postavené vzorkovací a statistické, které jsou odvozeny ze vzorkovacích. Nejprve jsou vyjmenovány nejrůznější aspekty, proč je vůbec dobré zpoždění nebo ztrátovost měřit. To ve výše jmenovaných dokumentech skupiny BMWG chybí. Dalším tématem je přesný čas a definice souvisejících pojmů. Pak již následují samotné definice metrik zpoždění resp. ztrátovosti, které jsou členěny následovně (příklad pro atomickou metriku jednosměrné zpoždění je uveden v závorce):

  • název metriky (jednosměrné zpoždění paketů určitého typu)
  • paramtery (zdrojová a cílová IP adresa strojů příp. rozhraní, čas)
  • jednotky (reálné číslo udávající počet sekund nebo nekonečno)
  • definice (jednosměrné zpoždění pro pakety určitého typu putující od zdrojové do cílové adresy je reálné číslo, které udává čas, který uplyne mezi odesláním prvního bitu paketu z vysílací stanice a přijetím posledního bitu na přijímací stanici; pokud zaslaný paket není přijat zpoždění je rovno nekonečnu)
  • diskuze (např. reálné hodnoty zpoždění jsou větší než 0 sekund)
  • metodologie (zajistíme časovou synchronizaci stanic, sestavíme testovací paket, na cílové stanici se připravíme na příchod tohoto paketu, ve zdrojové stanici umístíme do již sestaveného paketu časovou známku a odešleme jej, pokud paket dorazí v "rozumném" čase, přečteme co nejdřív jeho časovou známku a odečteme ji od času příchodu paketu, dále musíme vzít v úvahu čas, který uplnyne od vystavení časové známky a skutečného odeslání resp. přijetí paketu nebo rozdíl v přesném čase obou stanic)
  • chyby a problémy (zde jsou pobrobně diskutovány rozdíly v časování stanic, rozdíly mezi časem odeslání resp. příjmu na rozhraní a v softwaru a jejich následná kalibrace)
  • prezentace výsledků (kalibrace a prostředí, v němž byla provedeno měření by mělo být součástí testovací zprávy, dále přesná specifikace použitého paketu, rozpoznávání, kdy je zpoždění rovno nekonečnu, výsledky kalibrace, cesta, po které paket prošel)

RFC 2679 definuje krom atomické metriky jednosměrné zpoždění paketů určitého typu vzorkovací metriku jednosměrné zpoždění toku paketů s Poissonovým rozložením a odvozené statistické metriky percentily jednosměrného zpoždění toku paketů s Poissonovým rozložením, jednosměrné zpoždění toku paketů s Poissonovým rozložením, medián jednosměrného zpoždění toku paketů s Poissonovým rozložením, minimální jednosměrné zpoždění toku paketů s Poissonovým rozložením, invertované percentily jednosměrného zpoždění toku paketů s Poissonovým rozložením. Obdobné metriky pro ztrátovost jsou definovány v RFC 2680.

RFC 2681

Tento dokument navazuje obsahem i strukturou na RFC 2679. RFC 2681 Round-trip for Delay Metric for IPPMRFC 2681 se zaměřuje na korektní zjištění zpoždění otáčky (round-trip time) mezi zdrojovým a cílovým uzlem. Autoři upozorňují, že v mnohých případech nelze pouze sečíst časy, které nám poskytnou dvě jednosměrné metriky a pohlížejí na celou problematiku komplexněji.

RFC 3357

V roce 2002 byl vydán RFC 3357 One-way Loss Pattern Sample MetricsRFC 3357, který využívá metrik, jenž byly popsány v RFC 2680. Dokument je zaměřen na zjišťování struktury ztrát v daném datovém toku, ne pouze na prosté konstatování, že pakety byly ztraceny či ne; definuje dvě základní metriky vzdálenost ztráty (loss distance) a periodu ztráty (loss period) a další odvozené, statistické metriky.

RFC 3393

RFC 3393 IP Packet Delay Variation Metric for IP Performance MetricsRFC 3393 se zabývá definicí metriky jednosměrný rozptyl zpoždění a z ní odvozených metrik. Autoři opět odkazují na předcházející dokument, konkrétně RFC 2679. Jednosměrný rozptyl zpoždění je pak vypočten z rozdílů jednotlivých hodnot jednosměrného zpozdění.

Srovnání dokumentů skupin BMWG a IPPM

Výše uvedený přehled dokumentů obou skupin přímo vybízí ke srovnání. Ve světě počítačů a komunikačních pojmů se občas užívají výrazy, které jsou zdánlivě zaměnitelné a tudíž mohou být vykládány pokaždé jinak. Proto obě skupiny nejprve definovaly základní pojmy, aby předešly možným zmatkům.

Název pracovní skupiny IP Performance Metrics napovídá, že se bude jednat o měření výkonostních charakteristik v sítích používající Internet Protocol. Skutečně, dokumenty skupiny se vůbec nezabývají síťovými vrstvami, které leží pod IP. Linková a fyzická vrstva jsou pro účely měření transparentní. Naopak pracovní skupina BMWG se ve svých dokumetech těmito vrstvami zabývá. Např. pro různá média definuje jiné parametry testů: pro Ethernet uvádí jiné délky rámců než pro Token Ring nebo FDDI. Při testování podle dokumentů BMWG je použito laboratorní prostředí – organizace IANA, která se mj. stará o přidělování IP adres poskytla BMWG rozsah adres k testování, stroje jsou zapojeny v umělé síti, v mnohých případech velmi jednoduché (testovacího zařízení je přímo připojeno k testovanému). Zato IPPM blíže nespecifikuje způsob zapojení a ani nevylučuje testování v reálné síti (jako BMWG), kde může být mezi stanicemi, mezi nimiž probíhá měření, několik dalších sítí, směrovačů nebo přepínačů. Doporučení BMWG je tedy vhodné používat při vývoji jednoho konkrétního zařízení a metriky IPPM pro charakterizaci sítě v běžném provozu. Tyto metriky jsou dle mého názoru dobře vystavěny. Pokud je namodelujeme jako tři na sobě ležící vrstvy, vidíme, že každá metrika další metrika (vzorkovací, statistická) je odvozena od přecházejících. Atomické metriky jsou tedy základem všech ostatních. Vzorkovací metriky neobsahují pouze běžné, periodické vzorkování, ale pro praxi výhodnější s Poissonovým, příp. geomterickým rozložením. Jestliže se takto pokusíme modelovat testy definované BMWG, dostaneme nejvýše jen dvě vrstvy: atomický, dílčí test, který je několikrát za sebou opakován, tj. probíhá periodické vzorkování (čili jen podmnožina vzorkování, které definuje IPPM). Na druhou stranu jiná vzorkování jsou náročnější na implementaci. Statistický přístup je v těchto testech použit pouze do té míry, že je spočten aritmetický průměr a jeho hodnota je považována za výsledek testu. Metodika jednotlivých testů je v RFC skupiny BMWG popsána vágně. To nám zase ale přináší určitou volnost při provádění testů. V dokumentech skupiny IPPM je detailnější popis a hlavně je u každého testu diskuze zamýšlející se nad možnými výsledky a upozorňující na chyby, které mouhou nastat a ovlivnit celé testování. Dále bych se zastavil u typů testů, které dané dokumenty skupin specifikují. BMWG popisuje test zpoždění, avšak už pomíjí důležitou charakteristiku sítě, kterou je rozptyl zpoždění. V dnešní době rozvoje multimediálních, především hlasových a videokonferenčních aplikacích je potřeba znát rozptyl zpoždění stejně jako např. propustnost. Především lidské ucho je k velkým hodnotám rozptylu velmi netolerantní. IPPM věnovala měření rozptylu dokonce celý RFC. Stejně tak metrikám konektivity. Domnívám se, že testování konektivity považola BMWG za zbytečné, protože se v laboratorním prostředí očekává splnění tohoto základního požadavku. Avšak v reálných sítích tuto jistotu nemáme. Další rozdíl spatřuji např. v testu ztrátovosti. V dokumentu BMWG je výsledkem testu kolik procent paketů se ztratilo, tj. sumární informace, zatímco metrika IPPM nám podává informaci o struktuře těchto ztrát. Naopak RFC skupiny IPPM neobsahují testy typické pro zkoušení jednotlivých zařízení (např. zotavení po přetížení nebo restartu), jsou zaměřeny na celou síť. Obě skupiny dbají na to, aby byly výsledky testů prezentovány v jednoznačné podobě a nedocházelo tak k rozdílné interpretaci naměřených hodnot; definují, jak má vypadat testovací zpráva.

Testovací nástroje

Softwarové nástroje

Hardwarové nástroje

Srovnání hardwarových a softwarových nástrojů

Text nadpisu

Implementace skriptů na vybraném nástroji