hledat:

6   Sledování a optimalizace výkonnostních charakteristik

Aktivita Sledování a optimalizace výkonnostních charakteristik se zabývá teoretickými a praktickými stránkami zajištění vysoké propustnosti a dalších kvalitativních komunikačních parametrů vyžadovaných aplikacemi při komunikaci přes rozlehlé vysokorychlostní sítě.

Aktivita má svoje internetové stránky, kde je možné nalézt naše články, technické zprávy, prezentace, výsledky experimentů a vytvořený software. Shrnutí našich nejdůležitějších výsledků dosažených v roce 2007 uvádíme dále.

6.1   Aktivní monitorování v síti CESNET2

Pro plánování sítě a řešení výkonnostních problémů je užitečné znát charakteristiky síťového provozu a stavu sítě. V letošním roce jsme rozšířili naši infrastrukturu pro monitorování sítě mimo jiné o aktivní monitorování, to znamená monitorování využívající testovacích paketů. Některé výsledky jsou prezentovány novým netradičním způsobem.

Některé síťové charakteristiky jsou spojeny se skutečným provozem v síti a je možné je zjistit pouze pasivním monitorováním, to znamená analýzou skutečného provozu. Jde například o zátěž sítě a její dynamiku, rozdělení provozu do protokolů nebo bezpečnostní problémy.

Pro jiné síťové charakteristiky je ale použití aktivního monitorování možné a jejich měření tímto způsobem je méně náročné na objem zpracovaných dat než u pasivního monitorování. Jde například o propustnost, zpoždění a do jisté míry i ztrátovost paketů. Tato měření jsou užitečná zejména jako indikátory dobrého stavu sítě, to znamená zajímavé jsou zejména změny v dlouhodobém sledování.

6.1.1   Zpoždění

Zpoždění může být měřeno jako jednosměrné nebo obousměrné. Zatímco obousměrné zpoždění je možné snadno měřit nástrojem ping, jednosměrné zpoždění umožňující detekci anomálií na trase lze měřit pouze mají-li obě koncová zařízení přesně synchronizovaný čas. Program ping je možné nasměrovat téměř na každé síťové zařízení, protože podpora ICMP zpráv programu ping je součástí standardní implementace protokolu IP. Naproti tomu měření jednosměrného zpoždění vyžaduje speciální kooperující program na každé straně měření.

Přesnost měření jednosměrného zpoždění závisí zejména na dvou faktorech:

• Přesnost časové synchronizace měřících stanic (řádově desítky mikrosekund při použití GPS přijímačů nebo 1 až 3 milisekundy se synchronizací protokolem NTP po síti).
• Zpoždění mezi odesláním či přijetím paketu a přidělením časových značek v důsledku hardwarového a softwarového zpracování v měřících stanicích (řádově desítky mikrosekund).

Typické zpoždění mezi uzly národní sítě je v řádu jednotek milisekund. Synchronizace času pomocí GPS přijímačů je tedy potřebná. V některých případech může ale druhý faktor způsobit nepřesnost až řádu milisekund. Může se to stát, je-li měřící stanicí silně zatížený počítač, kde časové značky přiděluje standardní operační systém. Tento faktor je možné ověřit posíláním paketů v přesných časových intervalech (např. z hardwarového generátoru) a jejich příjmem na měřící stanici. V takovém případě je potřeba pro příjem paketů použít karty přidělující časové značky již ve svém hardware.

Rozdíl ve zpoždění po sobě následujících paketů téhož spojení se nazývá jitter a je často považován za samostatnou síťovou charakteristiku, protože je důležitý pro řadu aplikací, například přenosy zvuku, obrazu nebo distribuované výpočty.

6.1.2   Ztrátovost

Ztrátovost paketů může být měřena jako jednoduchá metrika - paket je buď přenesen nebo ztracen. Praktičtější je ale statistická hodnota - procento ztracených paketů v určitém časovém období. Z hlediska vlivu ztrátovosti na aplikace je zajímavé sledovat také, zda se ztráty vyskytují ve shlucích, to znamená kolik po sobě odeslaných paketů bylo ztraceno.

Měření ztrátovosti testovacími pakety je snadné, naměřené hodnoty jsou ale přesně platné pouze pro vlastní testovací pakety. Je obtížné implikovat, jaká je ztrátovost reálného provozu. Aktivní měření ztrátovosti je proto užitečné ne jako přesné monitorování, ale jako indikátor dobrého stavu sítě - zvýší-li se naměřená ztrátovost, je pravděpodobně na trase mezi měřícími stanicemi nějaký problém.

6.1.3   Změna pořadí paketů

Obdobně jako u ztrátovosti, i změna pořadí paketů může být měřena jako jednoduchá metrika (pár paketů je nebo není přehozen) a statisticky - procento přehozených paketů. Je také možné kvantifikovat různými způsoby rozměr změn pořadí paketů v počtu a čase.

Ke změně pořadí paketů dochází obecně v důsledku paralelního průchodu paketů uzly (především jejich částmi) nebo linkami trasy s různým zpožděním. Vlastnosti monitorování jsou u změn pořadí paketů podobné jako u ztrátovosti. Aktivní monitorování opět slouží jako indikátor dobrého stavu sítě.

6.1.4   Propustnost

Při sledování objemu sítového provozu můžeme definovat několik termínů:

Instalovaná kapacita

je maximální objem dat, který může být teoreticky přenesen za jednotku času.

Využitá kapacita

je aktuálně využitá část instalované kapacity.

Volná kapacita

je aktuálně nevyužitá část instalované kapacity, je tedy doplňkem využité kapacity do instalované kapacity.

Propustnost

je objem přidaných dat, která mohou být ještě přenesena sítí za jednotku času, kdy síť již obsahuje jiný provoz.

Propustnost se liší od volné kapacity tím, že závisí na protokolech použitých pro přenos stávajícího provozu a nově přidaného provozu. Většina síťového provozu je v současnosti přenášena protokolem TCP, který přizpůsobuje rychlost vysílání dat objemu konkurenčního provozu. Propustnost je proto většinou vyšší než volná kapacita.

6.1.5   Měření zpoždění, ztrátovosti a změn pořadí paketů

Pro měření uvedených charakteristik používáme upravený nástroj RUDE/CRUDE pro generování toků protokolu UDP se specifikovanými délkami a počtem paketů za sekundu. Každý testovací paket nese ve svém obsahu časovou značku okamžiku odeslání a informace o datovém toku. Výhodou nástroje je nízká režie umožňující odesílání paketů v přesných intervalech a v případě potřeby i ve vysokých objemech. Naše verze nástroje podporuje IPv4 i IPv6, unicast i multicast a posílání specifikovaných dávek paketů.

Monitorujeme jednosměrné zpoždění, ztrátovost a změny pořadí paketů mezi centrální stanicí v uzlu CESNETu v Praze a ostatními hlavními uzly páteřní sítě v republice. Rozmístění monitorovacích stanic je znázorněno na obrázku. Stejné monitorovací stanice jsou použity i pro měření propustnosti a pro pasivní monitorování.

Vytvořili jsme systém, který naměřené výsledky ukládá do RRD databáze a na základě požadavků prezentuje v uživatelském rozhraní. Příklad prezentace zpoždění je na obrázku. Průměrné zpoždění v požadovaném období a s požadovaným časovým krokem je znázorněno jako pozitivní hodnoty červenou barvou pro jeden směr a jako negativní hodnoty zelenou barvou pro druhý směr. Různé barvy jsou užitečné v případě, kdy v důsledku výpadku časové synchronizace dojde k posunu kladných hodnot do záporné části nebo obráceně.

Příklad prezentace ztrátovosti je na obrázku. Stejný typ grafu se používá i pro prezentaci změn pořadí paketů. V RRD databázi ukládáme každý počet po sobě odeslaných paketů, které byly detekovány jako ztracené. Obdobně ukládáme počet přeskočených paketů v případě změny pořadí paketů. Graf znázorňuje maximální hodnoty v požadovaném období a s požadovaným časovým krokem. Tímto způsobem jsou výskyt i velikost ztrát nebo přeskupení vždy viditelné i v grafech za delší časové období, kde by se průměrné hodnoty blížily nule. Chceme-li určit přesněji dobu výskytu ztrát nebo přeskupení, stačí změnit časové měřítko grafu.

6.1.6   Měření propustnosti

Pro měření propustnosti používáme námi upravený nástroj iperf umožňující opakované měření ve skriptech. To znamená, že i v případě jakýchkoliv problémů s navázáním spojení nebo přenosem se musí řádně ukončit. Měření propustnosti provádíme obousměrně mezi centrální stanicí v uzlu CESNETu v Praze a ostatními hlavními uzly páteřní sítě v republice, a to pro IPv4 a IPv6 a pro transportní protokoly TCP a UDP. V případě protokolu UDP používáme zvyšující se datový tok a registrujeme dvě hodnoty - maximální tok, který je možné přenést beze ztrát paketů, a maximální tok, při kterém je ztrátovost nižší než stanovená hodnota, kterou je v současné době 5 %. Konfigurace monitorovacích stanic odpovídá požadavkům na maximální dosažitelnou rychlost odesílání a příjmu dat. Protože instalovaná kapacita páteřních linek je však vyšší než rychlost síťového rozhraní stanic, hodnota měření je v indikaci dobrého stavu sítě - náhlá změna v dlouhodobém měření (které probíhá pouze jednou denně) je známkou problému na dané trase. Dobrá naměřená propustnost naopak vylučuje problém v páteřní síti v případě problému uživatelů s propustností z jejich koncové stanice.

Příklad naměřené propustnosti je na obrázku. Zelená barva znázorňuje propustnost UDP při nulové ztrátovosti, červená barva při ztrátovosti do 5 % a modrá křivka znázorňuje propustnost TCP.

Sledovali jsme vzájemný efekt různých typů měření prováděných s použitím stejných monitorovacích stanic. Každý úplný test propustnosti (pro oba směry a všechny protokoly) přenese asi 4 gigabajty dat. Tento objem dat je pod běžnou fluktuací provozu na zatíženějších páteřních linkách, je ale viditelný v monitorování protokolem SNMP na méně zatížených linkách. Měření propustnosti nezpůsobuje viditelné ovlivnění pasivního monitorování prováděného na stejných stanicích. Ovlivňuje ale současně prováděné měření zpoždění. V budoucnu plánujeme tyto testy časově oddělit tak, aby nedocházelo k jejich ovlivnění.

6.2   Prototyp aplikace pro detekci problémových míst na trase

Řada výkonnostních problémů je způsobena závadou, špatnou konfigurací nebo vyčerpáním zdroje (např. paměti) některého komponentu na trase mezi koncovými stanicemi. Pro lokalizaci těchto problémů je užitečný nástroj typu "inteligentní traceroute", který poskytne seznam uzlů na trase s podrobnými informacemi o výkonnostních charakteristikách jednotlivých uzlů a linek. Vytvořili jsme prototyp takového nástroje. Předpokládáme, že v současnosti dokončovaný systém perfSONAR pro výkonnostní monitorování v síti GN2 nám v budoucnu umožní vytvořit vylepšenou verzi s automatickou analýzou trasy.

Standardní program typu traceroute poskytuje pouze seznam adres směrovačů na trase spolu s obousměrným zpožděním na tyto směrovače (RTT - Round Trip Time). Pro řešení komunikačních problémů je užitečné získat další charakteristiky, zejména:

• instalovanou kapacitu,
• volnou kapacitu,
• chybovost paketů (včetně příčin),
• obsazení front na směrovačích.

Program typu inteligentní traceroute by navíc měl pracovat v obou směrech, měl by být rozšiřitelný o nové charakteristiky a měl by rozpoznat uzly typu L2 nebo L1, které se vyskytují v současných hybridních sítích.

Přístup na směrovače protokolem SNMP nebo jiným způsobem je obvykle omezen na vybrané IP adresy monitorovacích stanic. Program spuštěný uživatelem na jeho PC musí proto k přístupu na směrovače použít proxy server. Tato metoda odpovídá architektuře systému perfSONAR, který je založen na komunikaci samostatných služeb výměnou XML zpráv. Mezi nejdůležitější služby patří měřící body (Measurement point, MP) a měřící archívy (Measurement archive, MA), které provádějí určitá konkrétní měření v síti. Měřící bod poskytuje pouze aktuálně změřené charakteristiky, zatímco měřící archív obsahuje i paměť pro průběžně měřené charakteristiky. Dalším užitečným komponentem je vyhledávací služba (Lookup Service - LS), která registruje a poskytuje adresy (URL) ostatních služeb.

Pro program typu inteligentní traceroute jsou zvláště užitečné dva druhy měřících bodů - SNMP MP, který poskytuje charakteristiky získané protokolem SNMP, a Telnet/SSH MP, který poskytuje informace získané spuštěním příkazů na směrovačích prostřednictvím protokolů Telnet nebo SSH. Každý takový měřící bod obsluhuje určitou množinu směrovačů.

6.2.1   Prototypová implementace - program JTraceRoute

Vytvořili jsme program JTraceRoute v jazyce Java, který je možné spustit samostatně nebo prostřednictvím technologie web start i z webovského prohlížeče. Program sestává z několika fází:

Standardní traceroute

Tato fáze získá seznam adres směrovačů na trase, volitelně i ve zpětném směru ve spolupráci se stejným programem na druhém konci, pracujícím v režimu server, a uloží tento seznam do textového souboru.

Traceroute XML konvertor

Druhá fáze převede textový soubor do formátu XML.

Hledání měřících bodů

Ve třetí fázi je využita vyhledávací služba k získání adres měřících bodů, které obsluhují směrovače identifikované v první fázi.

Komunikace s měřícími body

V poslední fázi jsou kontaktovány měřící body pro získání charakteristik o uzlech a linkách trasy.

Potřeba standardního formátu pro ukládání výsledků programů typu traceroute vedla pracovní skupinu IPPM (IP Performance Metrics) v rámci IETF k vytvoření pracovního dokumentu [NTQ07] s návrhem formátu XML pro tento účel. Tento dokument ale omezuje použití formátu XML pouze pro výsledky standardního traceroute. Pro ukládání dalších informací bude třeba vytvořit nový formát XML. Práci na příslušném návrhu plánujeme v rámci skupiny IPPM v příštím roce. Prototyp naší implementace používá námi navržené dočasné rozšíření standardního formátu XML, na kterém si chceme ověřit jeho praktické vlastnosti.

Typické použití programu JTraceRoute je následující.

1. Spustíme program JTraceRoute, viz obrázek. Zadáme adresu cílového uzlu, typ traceroute (v tomto okamžiku je možný pouze standardní traceroute), zda má být proveden traceroute i ve zpětném směru a adresář pro uložení výsledků. Postup provádění traceroute lze sledovat v dolní části programu.


Obrázek 6.5: Program JTraceRoute

2. Výsledek je uložen do XML souboru. Stisknutím tlačítka "View results" získáme grafické zobrazení trasy v obou směrech (byl-li proveden i zpětný traceroute), viz obrázek. Korelace seznamu směrovačů z obou směrů není zcela triviální, protože v každém směru získáme jiné IP adresy jiných rozhraní směrovačů bez síťových masek. Program JTraceRoute používá ke spárování adres linek heuristiku, která předpokládá, že většina linek mezi směrovači používá podsítě s dlouhou maskou, kdy IP adresy protilehlých stran téže linky jsou velmi blízké. Detekované asymetrie jsou odpovídajícím způsobem graficky zobrazeny. Program poskytuje seznam dříve provedených měření, která je možné kdykoliv později zobrazit výběrem ze seznamu.


Obrázek 6.6: Zobrazení výsledku traceroute

3. Kliknutím na kterékoliv rozhraní některého směrovače na trase zobrazíme informační okénko o tomto rozhraní. Dále jsou k dispozici dvě možnosti. Za prvé můžeme nechat spustit zvolený externí program, kterému bude jako argument zadána adresa daného rozhraní. Seznam nabídnutých programů je uložen v konfiguraci. Druhou možností je poslání dotazu do systému perfSONAR ohledně daného rozhraní, viz obrázek. Stisknutím tlačítka "Query LS" je odeslán vyhledávací službě dotaz na adresy (URL) měřících bodů, které mají informace o daném rozhraní. Potom můžeme z nabídnutého seznamu vybrat měřící bod a z dalšího seznamu typ dotazu, který má být na tento měřící bod poslán. Dotaz je zobrazen jako XML zpráva, v níž je na vhodném místě automaticky vyplněna adresa daného rozhraní. Dotaz můžeme editovat a odeslat. Výsledek je zobrazen rovněž jako XML zpráva.


Obrázek 6.7: Komunikace se systémem perfSONAR

Navržený a implementovaný program typu inteligentní traceroute umožňuje ve spolupráci se systémem perfSONAR získat výkonnostní charakteristiky uzlů a linek síťové trasy. Plánujeme rozšíření tohoto programu o bránu do systému G3 pro monitorování protokolem SNMP a automatizaci zjištění informací o celé trase.

6.3   Hardwarová podpora pro sledování dynamiky síťového provozu

Měříme-li zátěž sítě průměrnými hodnotami, zjistíme, že naměřené hodnoty závisí na zvoleném časovém intervalu. Kratší interval vede k větším fluktuacím hodnot. Jedna možnost kvantifikace dynamiky síťového provozu bez ohledu na časový interval je vytvoření histogramu rozložení délek dávek paketů. Za dávku paketů považujeme po sobě jdoucí posloupnost paketů ukončenou mezerou delší než stanovený limit, kde pakety uvnitř dávky jsou odděleny mezerou menší nebo rovnou danému limitu.

Pro přesné neintruzivní monitorování dynamiky provozu v reálném čase jsme vytvořili firmware pro kartu COMBO6X s jednotkou STU_BURST (Statistical Unit for Bursts). Měření má následující vlastnosti:

• Vstupem jsou délky a časové značky příchozích paketů.
• Výstupem je histogram rozložení délek dávek.
• Pro každý krok histogramu je sledován počet dávek, paketů a bajtů.
• Měření je trvalé, kdykoliv je možné přečíst výsledky platné v určitém časovém okamžiku bez přerušení měření.
• Je možné nastavit limitní mezeru mezi dávkami.
• Je možné nastavit velikost každého kroku histogramu samostatně.
• Jednotka je schopná pracovat plnou rychlostí linky (1 Gb/s) při všech délkách paketů a dávek na všech (čtyřech) rozhraních karty současně.

Rozhodli jsme se přidat měření dynamiky provozu k firmware NIFIC (Network Interface Card with Filtration). Integrace měření dynamiky do firmware je znázorněna na obrázku. Pakety přichází souběžně na vstup jednotek NIFIC a na vstup jednotky RTS (Relative Timestamp), která poskytuje délky paketů a časové značky v systémovém čase do jednotky STU_BURST. Z různých technických důvodů nebylo možné využít speciální karty pro časové značky COMBO-PTM. Protože ale jednotka STU_BURST potřebuje znát pouze rozdíly časových značek po sobě následujících paketů, použili jsme řešení bez karty COMBO-PTM, kdy jednotka RTS používá hodinový signál rozhraní GMII pro vytváření vlastních časových značek. Firmware obsahuje čtyři jednotky RTS a STU_BURST, jednu pro každé vstupní rozhraní karty. Jednotky NIFIC nemohou pracovat na plné zátěži linky pro všechny velikosti paketů. Pokud jejich činnost nepotřebujeme, je vhodné vypnout jejich vstupní vyrovnávací paměť a tím je odpojit.

Délka paketu je zakódována do 14 bitů, což je dostačující pro pakety do délky 16 383 bajtů. Časová značka má délku 64 bitů, kde 32 bitů je určeno pro sekundy a 32 bitů pro zlomek sekundy.

Struktura jednotky STU_BURST je znázorněna na obrázku. Jednotka BURST_SAMPLER porovnává mezipaketové mezery s limitní hodnotou a na konci dávky pošle počet bajtů v dávce do jednotky STU_CLASSIFIER. Tato jednotka porovnává délky dávek s velikostmi 256 kroků, do kterých dávky třídí. Uživatel může specifikovat velikosti těchto kroků libovolně. Všechny kroky mohou být stejně veliké nebo různě veliké, například v logaritmickém měřítku. Počty dávek, paketů a bajtů ve všech 256 krocích jsou udržovány v čítačích. Ty jsou 32bitové pro dávky a 64bitové pro pakety a bajty. V nejkritičtějším případě pouze 64bajtových paketů při rychlosti 1 Gb/s je potřebné čítače přečíst alespoň jednou za 2886 sekund. Protože čtení čítačů trvá určitou dobu, potřebujeme měřit trvale a chceme všechny hodnoty získat ke stejnému časovému okamžiku, jsou všechny čítače zdvojeny. Jedna polovina je vždy aktivní použitá pro měření. Požadavek na čtení výsledků přepne druhou polovinu jako aktivní, zatímco z první poloviny můžeme v klidu přečíst výsledky, čímž se čítače i vynulují.

Příklad naměřených hodnot zobrazených ve 3D grafu pro znázornění vývoje histogramu v čase je na obrázku.

6.4   Modulární platforma pro vysokorychlostní monitorování sítě s hardwarovou podporou

Vytvořili jsme modulární programovatelnou platformu pro zpracování paketů (monitorování a generování) rychlostí 10 Gb/s s operačním systémem Linux běžícím na zabudovaném procesoru Power PC v FPGA bez nutnosti použít externí počítač. Platforma je založena na námi navrženém unikátním uspořádání modulů, umožňujícím velkou rozšiřitelnost a složité zpracování i při vysokých rychlostech. Funkční moduly je možné vyměňovat za provozu zařízení.

Na technické řešení platformy byla podána přihláška užitného vzoru a vynálezu u Úřadu průmyslového vlastnictví s názvem Modulární programovatelná platforma pro vysokorychlostní hardwarové zpracování paketů.

Platforma je zabudovaná do 1U skříně. V tomto okamžiku pouze počítá příchozí pakety, a to plnou rychlostí 10 Gb/s při všech délkách paketů. Je také možné naopak generovat pakety plnou rychlostí 10 Gb/s. Implementaci funkčních modulů pro různé druhy statistik a vzdálený přístup protokolem SNMP plánujeme v příštím roce. Experimentální ověření možnosti realizace platformy pracující rychlostí 40 Gb/s rovněž plánujeme v příštím roce.

6.5   Systém NTPMON

V roce 2007 jsme rozšířili systém NTPMON pro kontrolu služby NTP. Nyní se sledování provádí na našich časových serverech a na monitorovacích stanicích v uzlech sítě CESNET, které potřebují znát čas s odchylkou v řádu desítek až stovek mikrosekund.

Systém NTPMON sbírá data pomocí dvou nezávislých agentů:

ntpq

Agent se dotazuje na parametry procesu NTP pomocí příkazu ntpq -c rl.

clie

Agent funguje jako klient protokolu NTP, zjišťuje rozdíl času mezi sledovaným a referenčním systémem.

Vzhledem k požadavkům na přesnost času a stabilitu hodin v počítači, na kterém je spuštěn agent clie, jsme se rozhodli tohoto agenta provozovat odděleně na vyhrazeném počítači. To má i tu výhodu, že v budoucnu bude možné do NTPMON zahrnout více distribuovaných agentů clie a provádět tak přesnější sledování v rozsáhlých sítích, např. v síti GÉANT2.

NTPMON generuje grafy zobrazující průběh veličin:

• časový posun,
• frekvenční posun,
• hraniční nejistota časové informace (root dispersion),
• změřený časový posun vůči referenčnímu systému,
• změřené zpoždění mezi sledovaným a referenčním systémem.

Grafy jsou generovány pro období posledních 6 hodin, 24 hodin, 7 dnů a 30 dnů a dále pro zvolený den, týden a měsíc, viz obrázek.

Dalším druhem výstupu je tabulka událostí, které jsou průběžně generovány některým agentem v případě, že je zjištěna nedostupnost služby NTP, překročení hraničních mezí kvantitativních parametrů (posun, stabilita) nebo změna kvalitativních parametrů (stratum, verze programu NTP, verze operačního systému). Některé druhy události expirují po jednom týdnu, jiné jsou průběžně agregovány tím způsobem, že se snižuje granularita přiřazeného časového údaje.

Posledním druhem výstupu je tabulka zobrazující poslední získané stavové informace o sledovaném systému, viz obrázek.

6.6   Nová konstrukce časových serverů

V průběhu roku jsme zhotovili a uvedli do provozu čtyři nové NTP servery vlastní konstrukce. Cílem bylo vyvinout zařízení s následujícími vlastnostmi:

• co nejvyšší stabilita systémových hodin,
• zpracování vstupního signálu 1 PPS (Pulse per second) bez vlivu zpoždění při přerušení,
• možnost umístění do racku - tj. počítačová skříň o šířce 19" s nejmenší možnou výškou 1U,
• displej zobrazující stav NTP serveru.

Jako základní desku počítače jsme vybrali osvědčené typy VIA EPIA s formátem mini-ITX. Pro zpracování vstupního signálu jsme použili specializovaný hardware - PCI kartu se zákaznickou verzí firmware, pro kterou jsme napsali Linuxový ovladač. Tato karta umožní snížit nejistotu časové značky při zpracování vstupních sekundových pulzů z externích hodin až na 50 ns. Vnitřní uspořádání NTP serveru je znázorněno na obrázku.

Každá základní deska architektury i386 obsahuje krystalový oscilátor 14,318 MHz, od něhož jsou odvozeny i systémové hodiny počítače. V našich NTP serverech jsme nahradili uvedený krystal modulem termostatovaného oscilátoru vlastni konstrukce, který je předmětem přihlášky užitného vzoru, viz obrázek. Modul obsahuje konfigurovatelnou násobičku/děličku kmitočtu, která dovolí využití oscilátoru s jinou základní frekvencí, např. běžně dostupnou hodnotu 10 MHz.

Displej NTP serveru slouží pro okamžitou informaci o jeho stavu a také jako velmi přesné digitální hodiny. První řádka displeje obsahuje jméno serveru a aktuální čas. Na druhé řádce se periodicky zobrazují následující údaje:

• hodnota Stratum,
• identifikace referenčního zdroje času,
• časový posun hodin,
• frekvenční stabilita hodin,
• zátěž serveru vyjádřená v počtu dotazů za jednotku času.

Náš základní NTP server tik.cesnet.cz je využíván nejen v rámci sítě CESNET2 ale i jiných evropských sítí a jeho zátěž je 200-300 dotazů z rozdílných IP adres každou sekundu. Parametry jeho hodin mají typickou hodnotu:

• posun času méně než 1 mikrosekunda,
• stabilita frekvence 1×10^-9 během 256 sekund.

6.7   Časová razítka a jejich ověřování

Termínem "časová razítka" se označuje speciální typ certifikátu, který dokazuje existenci nějaké události v určitém okamžiku v minulosti tím způsobem, že důvěryhodný časový údaj i klíč vztahující se k dané události se stanou součástí příslušného certifikátu. Například dokázat existenci nějakého textového souboru je možné pomocí tzv. hash funkce, která k libovolně velkému souboru přiřadí klíč omezené délky a ten pak je obsažen v certifikátu.

Systém, který generuje časová razítka, se nazývá časová autorita (time-stamp authority). Příslušný protokol je definován v dokumentu RFC 3161 "Internet X.509 Public Key Infrastructure, Time-Stamp Protocol (TSP)".

Časové autority jsou většinou komerční proprietární systémy, kdy je obtížné z vnějšku provést kalibraci poskytované časové informace. V roce 2007 jsme navrhli ve spolupráci s kolegy z Ústavu fotoniky a elektroniky Akademie věd České republiky a z Katedry měření FEL ČVUT metodu takové kalibrace a ověřili jsme ji pomocí prototypu kalibračního počítače, ve kterém jsme uplatnili naše zkušenosti s konstrukcí přesných NTP serverů.

Základem kalibračního systému je kalibrační počítač CC s programem proc_tsp, který je schopen přijímat a dekódovat obsah požadavků odesílaných časové autoritě i vydaných časových razítek. Čas přijetí těchto požadavků a razítek se vyhodnotí podle hodin počítače CC, které využívají stabilní oscilátor a jsou synchronizovány přijímačem GPS. Z metrologického hlediska jsou hodiny počítače CC navázány na časovou stupnici UTC.

Uvedeným způsobem získáme pro každé časové razítko trojici hodnot (T_Q, T_R, T_S), kde T_Q je čas přijetí požadavku, T_R je čas přijetí razítka a T_S je časový údaj obsažený v časovém razítku. Získané záznamy je možné statisticky zpracovat, resp. hledat případy, kdy bylo vydáno časové razítko s nesprávným časovým údajem.

Pro ověření popsané metody jsme postavili experimentální časovou autoritu s vyžitím programového balíku OpenTSA.

Navrhli a otestovali jsme dvě možné varianty kalibrační metody, které se liší zejména způsobem umístění kalibračního počítače:

Kalibrace u poskytovatele služby (obrázek)

Kalibrační počítač je umístěn v lokální síti poskytovatele služby a je schopen zachycovat všechny požadavky na časová razítka i vydaná časová razítka. V tomto zapojení jsou eliminovány vlivy zpoždění v síti. Cílem je ověřit nejistotu poskytované časové informace, kterou musí deklarovat provozovatel časové autority v popisu služby.

Obrázek 6.15: Kalibrace u poskytovatele služby

Kalibrační počítač u uživatele (obrázek)

Kalibrační počítač je umístěn vně sítě poskytovatele služby. Sám generuje požadavky a následně zpracovává přijatá časová razítka. Služba je vyhodnocována z pohledu uživatele, protože změřené hodnoty zahrnují i vliv zpoždění v síti.

Uvedené způsoby kalibrace časových autorit jsme prezentovali v září 2007 na mezinárodní konferenci IMEKO TC4.

předchozí

obsah

následující