Fakulta elektrotechnická Katedra telekomunikační techniky

ˇ e vysoké uˇcen´ı technické v Praze Cesk´ Fakulta elektrotechnická Katedra telekomunikaˇcn´ı techniky

Moˇ znosti zlepˇsen´ı pˇresnosti synchronizace ˇ casu v paketov´ ych s´ıt´ıch Disertaˇcn´ı práce

Ing. Michal Pravda

Praha, srpen 2015

Doktorský studijn´ı program: Elektrotechnika a informatika Studijn´ı obor: Telekomunikaˇcn´ı technika ˇ Skolitel: Doc. Ing. Jiˇr´ı Vodráˇzka Ph.D.

ii

c 2015 Ing. Michal Pravda Copyright

Abstrakt Disertaˇcn´ı práce se zab´ yvá moˇznostmi zlepˇsen´ı pˇresnosti synchronizace ˇcasu v paketov´ ych s´ıt´ıch a následného pˇresného generován´ı taktu ze synchronizovaného zaˇr´ızen´ı. C´ılem práce bylo prostudován´ı moˇznost´ı synchronizace v paketov´ ych s´ıt´ıch a nalezen´ı moˇznost´ı, které zlepˇs´ı ˇcasovou synchronizaci jednotliv´ ych zaˇr´ızen´ı a zv´ yˇs´ı pˇresnost generovaného taktu na stranˇe klienta. Práce je rozdˇelena do dvou hlavn´ıch ˇca´st´ı. Prvn´ı ˇcást je zamˇeˇrena na mˇeˇren´ı a anal´ yzu pˇresnosti synchronizace ˇcasu v reálné s´ıti. Pˇri mˇeˇren´ı byla vyuˇz´ıvána zaˇr´ızen´ı s podporou Precision Time Protokolu (PTP). Vlastnosti s´ıtˇe a pˇrenosové parametry byly mˇenˇeny pomoc´ı s´ıt’ového emulátoru a v závislosti na zmˇenˇe docházelo i ke zmˇenˇe v´ ysledné pˇresnosti synchronizace ˇcasu. Druhá ˇca´st se zab´ yvá moˇznostmi vylepˇsen´ı pˇresnosti synchronizace ˇcasu. Strana klienta byla rozˇs´ıˇrena o druhé lokáln´ı hodiny H2, které umoˇzn ˇuj´ı pomalejˇs´ı dolad’ován´ı a zvyˇsuj´ı tak v´ yslednou pˇresnost synchronizace ˇcasu klienta. Návrh klienta byl proveden univerzálnˇe, aby mohl b´ yt pouˇzit bud’ pro NTP nebo PTP protokol. Pˇri simulac´ıch jednotliv´ ych navrˇzen´ ych algoritm˚ u byly pouˇzity stejné podm´ınky, jako pˇri mˇeˇren´ı v reálném prostˇred´ı a v´ ysledky byly následnˇe porovnávány. V´ ysledná pˇresnost synchronizace ˇcasu pˇri simulaci metody s navrˇzen´ ym vylepˇsen´ım dosahovala lepˇs´ıch v´ ysledk˚ u neˇz pˇri mˇeˇren´ı v reálné s´ıti. V´ ysledky simulac´ı uvedené v této práci ukazuj´ı, ˇze navrˇzená metoda vylepˇsen´ı klienta dosahuje vyˇsˇs´ı pˇresnosti synchronizace ˇcasu. V pˇr´ıpadˇe porovnán´ı lokáln´ıch hodin H1 a H2 na stranˇe klienta zjist´ıme, ˇze kol´ısán´ı hodin H2 je vˇzdy niˇzˇs´ı neˇz hodin H1 za stejn´ ych vstupn´ıch podm´ınek. Toto chován´ı je správné a bylo c´ılem této práce.

iv

Abstract This doctoral thesis deals with the possibilities of improving accuracy of time synchronization over packet networks and the subsequent accurate pulse generation. The goal of this paper is to analyze the options of synchronization in packet networks, and also to design and simulate a possible method for increasing device synchronization and accuracy of pulse generated on the side of the client. The work is divided into two main parts. The first part is focused on the analysis and measurement of synchronization accuracy in a real packet network. Measurement was performed using the Precision Time Protocol (PTP). Network transmission parameters were changed using a network emulator and depending on the change resulting synchronization accuracy varied. The second part deals with methods for improving accuracy of clock synchronization. An additional source of a local H2 clock is used on the client’s side to improve synchronization accuracy. Client design was made to be very versatile, therefore it can be used for NTP as well as PTP protocol. The proposed methods were simulated under the same conditions as the previous measurements and the results were compared. The resulting synchronization accuracy was better in the simulation than in the real network. The simulation results presented in this paper indicate that the proposed method of client improvement achieves higher accuracy of time synchronization. When comparing the results of the local H1 and H2 clocks on the client’s side, it is apparent that the variation of the H2 is always smaller than that of the H1 under identical input conditions. This behavior proves to be correct which is the aim of this work.

Podˇ ekov´ an´ı Rád bych podˇekoval svému ˇskoliteli Doc. Ing. Jiˇr´ımu Vodráˇzkovi, Ph.D. za vytvoˇren´ı tv˚ urˇc´ıch podm´ınek a za cenné pˇripom´ınky i rady pˇri tvorbˇe této disertaˇcn´ı práce. Dále bych chtˇel podˇekovat své rodinˇe za veˇskerou podporu a trpˇelivost bˇehem celého mého doktorského studia.

vi

Obsah Obsah

1

Seznam obr´ azk˚ u

3

Seznam tabulek

5

Seznam zkratek

7

´ 1 Uvod

9

2 Souˇ casn´ y stav ˇ reˇ sen´ e problematiky ˇ 2.1 Casov´ a synchronizace v paketov´ ych s´ıt´ıch . . . . . . 2.2 Network Time Protocol . . . . . . . . . . . . . . . . 2.2.1 V´ ypoˇcet korekce ˇcasu . . . . . . . . . . . . . 2.2.2 V´ ykonnost NTP protokolu . . . . . . . . . . 2.3 IEEE 1588 – Precision Time Protocol . . . . . . . . 2.3.1 Architektura PTP . . . . . . . . . . . . . . 2.3.2 Princip synchronizace u PTP . . . . . . . . 2.3.2.1 Pr˚ uchoz´ı hodiny . . . . . . . . . . 2.3.3 Vlastnosti PTP . . . . . . . . . . . . . . . . 2.4 Synchronn´ı Ethernet . . . . . . . . . . . . . . . . . 2.5 Porovnán´ı jednotliv´ ych protokol˚ u . . . . . . . . . . 2.6 Mˇeˇren´ı v reálné s´ıti . . . . . . . . . . . . . . . . . . 2.6.1 Zpoˇzdˇen´ı paketové s´ıtˇe . . . . . . . . . . . . 2.6.2 Mˇeˇren´ı PTP . . . . . . . . . . . . . . . . . . 2.6.2.1 Popis jednotliv´ ych zaˇr´ızen´ı . . . . . 2.6.2.2 S´ıt’ové topologie a v´ ysledky mˇeˇren´ı 2.7 Zhodnocen´ı souˇcasného stavu . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

11 11 12 13 14 14 16 17 18 19 21 22 22 22 23 24 25 33

3 C´ıle disertaˇ cn´ı pr´ ace

35

4 N´ avrh a simulace synchronizaˇ cn´ıho algoritmu 4.1 Model synchronizaˇcn´ıch obvod˚ u - aktuáln´ı stav . . . . . . . . . . . . . . . . 4.1.1 Vyhodnocovac´ı algoritmus klienta . . . . . . . . . . . . . . . . . . .

37 37 38

1

2

OBSAH 4.2 4.3

Mˇeˇren´ı synchronizace v reálném prostˇred´ı . . . . . . Návrh na zlepˇsen´ı synchronizace . . . . . . . . . . . 4.3.1 Návrh vhodného filtru - stabilita obvodu . . 4.3.1.1 Vlastnosti a v´ ysledky FIR filtru . . 4.3.1.2 Vlastnosti a v´ ysledky IIR filtru . . 4.3.2 Simulace a v´ ysledky druh´ ych hodin . . . . . 4.3.2.1 Pr˚ umˇerovac´ı filtr . . . . . . . . . . 4.3.2.2 V´ ysledná pˇresnost hodin H2 . . . . 4.3.2.3 Lokáln´ı oscilátor a jeho dolad’ován´ı

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

5 Z´ avˇ er 5.1 Splnˇen´ı c´ıl˚ u disertaˇcn´ı práce . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Anal´ yza a mˇeˇren´ı vlivu vel. zpoˇzdˇen´ı s´ıtˇe na pˇresnost synchronizace 5.1.2 Simulaˇcn´ı program s aktuáln´ım stavem a funkc´ı synch. algoritmu . 5.1.3 Sn´ıˇzen´ı vlivu kol´ısán´ı zpoˇzdˇen´ı na pˇresnost synch. a zv´ yˇsen´ı pˇresnosti 5.1.4 Vytvoˇren´ı simulaˇcn´ıho programu s vylepˇsenou synchronizac´ı . . . . 5.2 Vyuˇzit´ı pro praxi a budouc´ı práce . . . . . . . . . . . . . . . . . . . . . . .

44 47 48 50 53 57 57 59 64 69 69 69 70 70 71 71

Literatura

73

Publikace autora

77

Seznam obr´ azk˚ u 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21

Hierarchie jednotliv´ ych vrstev NTP [22] . . . . . . . . . . . . . . . . . ˇ Casov´ e znaˇcky pˇri komunikaci klienta se serverem . . . . . . . . . . . . Topologie jednoduché s´ıtˇe . . . . . . . . . . . . . . . . . . . . . . . . . Architektura synchronizaˇcn´ı jednotky s PTP. [23] . . . . . . . . . . . . Korekce offsetu [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mˇeˇren´ı zpoˇzdˇen´ı [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . Blokové schéma vyuˇzit´ı pr˚ uchoz´ıch hodin . . . . . . . . . . . . . . . . . Jednotlivá zpoˇzdˇen´ı v s´ıti . . . . . . . . . . . . . . . . . . . . . . . . . Funkce synchronn´ıho Ethernetu . . . . . . . . . . . . . . . . . . . . . . ˇ Cetnost zpoˇzdˇen´ı paket˚ u pˇri propojen´ı na NTP server . . . . . . . . . . Blokové schéma synchronizaˇcn´ı karty PTP serveru [9] . . . . . . . . . . Pˇr´ımé propojen´ı serveru a klienta . . . . . . . . . . . . . . . . . . . . . S´ıt’ová topologie se serverem, PTP pˇrep´ınaˇcem a klientem . . . . . . . . V´ ysledky mˇeˇren´ı pˇri pˇr´ımém propojen´ı a s PTP pˇrep´ınaˇcem . . . . . . Topologie pro mˇeˇren´ı standardn´ıho pˇrep´ınaˇce a rozboˇcovaˇce . . . . . . V´ ysledky mˇeˇren´ı pˇri pouˇzit´ı standardn´ıho pˇrep´ınaˇce a rozboˇcovaˇce . . . Topologie pro mˇeˇren´ı rozboˇcovaˇce se zat´ıˇzen´ım . . . . . . . . . . . . . . V´ ysledky mˇeˇren´ı pˇri pouˇzit´ı rozboˇcovaˇce se zat´ıˇzen´ım a bez zat´ıˇzen´ı . . Topologie pro mˇeˇren´ı pˇrep´ınaˇce se zat´ıˇzen´ım . . . . . . . . . . . . . . . V´ ysledky mˇeˇren´ı standardn´ıho pˇrep´ınaˇce se zat´ıˇzen´ım a bez zat´ıˇzen´ı . . V´ ysledky mˇeˇren´ı stand. pˇrep´ınaˇce a Hirschmann pˇrep´ınaˇce se zat´ıˇzen´ım

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

12 13 15 16 18 19 20 20 21 23 24 25 26 26 27 27 28 29 30 31 31

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

Blokové schéma synchronizace ˇcasu . . . . . . . . . . . . . . . . . . . Fitr FIR s ˇra´dem 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . Korekce K1 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms Korekce K2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms Odchylka ˇcasu pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 3 ms a rozptylu 1 ms . . Korekce K1 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 2 ms Korekce K2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 2 ms Odchylka ˇcasu pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 3 ms a rozptylu 2 ms . . Blokové schéma mˇeˇren´ı s emulátorem s´ıtˇe . . . . . . . . . . . . . . . . Odchylka ˇcasu pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 3 ms a rozptylu 1 ms . . Odchylka ˇcasu pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 3 ms a rozptylu 2 ms . .

. . . . . . . . . . .

. . . . . . . . . . .

38 39 40 40 41 42 42 43 44 45 45

3

. . . . . . . . . . .

´ U ˚ SEZNAM OBRAZK

4 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31 4.32 4.33 4.34 4.35 4.36

Odchylka ˇcasu pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 10 ms a rozptylu 1 ms . . . . . Rozˇs´ıˇrené blokové schéma synchronizace ˇcasu . . . . . . . . . . . . . . . . . Regulaˇcn´ı smyˇcka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Oblast stability diskrétn´ıch regulaˇcn´ıch obvod˚ u . . . . . . . . . . . . . . . Amplitudová charakterist. fitru FIR ˇra´du 20 s mezn´ım kmitoˇctem 0,03 Hz Zobrazen´ı nul a pól˚ u filtru FIR ˇra´du 20 s mezn´ım kmitoˇctem 0,03 Hz . . . V´ ysledek synchronizace ˇcasu klienta s filtrem FIR ˇrád 20 . . . . . . . . . . Filtr IIR s ˇra´dem 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zobrazen´ı nul a pól˚ u filtru IIR ˇra´du 4 s mezn´ım kmitoˇctem 0,03 Hz . . . . Nyquist˚ uv diagram pro filtr IIR s ˇra´dem 4 . . . . . . . . . . . . . . . . . . Korekce K1 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms . . . Korekce K2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms . . . Odchylka ˇcasu pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 3 ms a rozptylu 1 ms . . . . . ˇ ast blokového schématu s hodinami H2 . . . . . . . . . . . . . . . . . . . C´ V´ ysledné korekce K4 a K2 pˇri stˇredn´ı hodnotˇe zpoˇzd. 3 ms a rozptylu 1 ms Rozd´ıl ˇcasu serveru a H2 pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 3 ms a rozptylu 1 ms Rozd´ıl ˇcasu serveru a H1, H2 pˇri stˇredn´ı hodnotˇe zpoˇzd. 3 ms a rozpt. 1 ms Rozd´ıl ˇcasu serveru a H1, H2 pˇri stˇredn´ı hodnotˇe zpoˇzd. 3 ms a rozpt. 3 ms Rozd´ıl ˇcasu serveru a H1, H2 pˇri stˇredn´ı hodnotˇe zpoˇzd. 10 ms a rozpt. 1 ms ˇ ast blokového schématu s oscilátorem . . . . . . . . . . . . . . . . . . . . C´ Fázov´ y závˇes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pˇrevodn´ı charakteristika doladˇen´ı oscilátoru . . . . . . . . . . . . . . . . . Rozd´ıl ˇcasu serveru a ˇcasu H1 a H2 pˇri chybˇe lokáln´ıho oscilátoru o 2 Hz . Dolad’ován´ı osc. s chybou 2 Hz pˇri stˇredn´ı hodnotˇe zpoˇz. 3 ms a rozp. 1 ms Dolad’ován´ı osc. s chybou 2 Hz pˇri stˇredn´ı hodnotˇe zpoˇz. 3 ms a rozp. 2 ms

46 47 48 49 50 51 52 53 54 55 55 56 56 57 59 60 61 63 63 64 65 66 67 68 68

5.1

Histogram ˇcetnost´ı rozd´ılu ˇcasu serveru a ˇcasu hodin H1 a H2 . . . . . . .

72

Seznam tabulek 2.1

V´ ysledky mˇeˇren´ı pro r˚ uzné topologie pˇri r˚ uzn´ ych podm´ınkách . . . . . . .

32

4.1 4.2 4.3 4.4 4.5 4.6

V´ ysledky simulac´ı pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe . . . . . . . . . . V´ ysledky mˇeˇren´ı s emulátorem s´ıtˇe pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe V´ ysledky pˇresnosti syn. hodin H1 pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe . V´ ysledky pˇresnosti syn. hodin H2 pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe . Funkce doladˇen´ı oscilátoru pˇri simulaci . . . . . . . . . . . . . . . . . . . . V´ ysledky pˇresnosti synchronizace hodin H2 v závislosti na doladˇen´ı osc. . .

43 46 62 62 65 67

5

6

SEZNAM TABULEK

Seznam zkratek

SDH OTH IEEE ITU ITU-T ETSI RFC ISO SNTP NTP PTP BMC TSU TC E2E P2P FTP HTTP FPGA PHY MII MAC UDP TCP SyncE SSM LAN MAN WAN

Synchronous Digital Hierarchy Optical Transport Network Institute of Electrical and Electronics Engineers International Telecommunication Union International Telecommunication Union Telecommunication Sector European Telecommunication Standards Institute Request for Comments International Organization for Standardization Simple Network Time Protocol Network Time Protocol Precision Time Protocol Best Master Clock Time Stamp Unit Transparent Clock End to End Peer to Peer File Transfer Protocol Hypertext Transfer Protocol Field Programmable Gate Array Physical Layer Media Independent Interface Medium Access Layer User Datagram Protocol Transmission Control Protocol Synchronous Ethernet Synchronization status message Local Area Network Metropolitan Area Network Wide Area Network 7

8

SEZNAM TABULEK GPS USB PPS FIR IIR PLL VCO RTT

Global Positioning System Universal Serial Bus Pulse Per Second Finite Impulse Response Infinite Impulse Response Phase Lock Loop Voltage Controlled Oscillator Round Trip Time

Pouˇ z´ıvan´ e symboly x Promˇenná, která pˇredstavuje nˇejakou hodnotu t Reprezentuje ˇcas - vyuˇz´ıváno zejména v simulac´ıch ∆t Reprezentuje rozd´ıl ˇcas˚ u (hodin) - vyuˇz´ıváno zejména pˇri porovnán´ı rozd´ılu hodin klienta a serveru δ Reprezentuje poˇcet pr˚ umˇerovan´ ych vzork˚ u - vyuˇz´ıvano u pr˚ umˇerovac´ıch filtr˚ u f Symbol frekvence ∆f Reprezentuje odchylku frekvence k Symbol korekce - reprezentuje hodnotu korekce hodin na stranˇe klienta

Kapitola 1 ´ Uvod Synchronizace ˇcasu a distribuce taktu je d˚ uleˇzit´ ym parametrem telekomunikaˇcn´ıch a poˇc´ıtaˇcov´ ych s´ıt´ı. Pˇresná distribuce a synchronizace taktu je vyˇzadována pˇri komunikaci v reálném ˇcase napˇr´ıklad v automatizaˇcn´ıch systémech nebo pˇri pˇrenosu audia ˇci videa. V páteˇrn´ıch s´ıt´ıch jsou vyuˇz´ıvány s´ıtˇe se synchronizac´ı (napˇr´ıklad s´ıtˇe SDH), nicménˇe je potˇreba umoˇznit synchronizaci i pˇres jiné typy s´ıt´ı, jak´ ymi jsou napˇr´ıklad paketové s´ıtˇe. V automatizaci docház´ı vlivem vzr˚ ustaj´ıc´ı sloˇzitosti a v´ ykonu strojn´ıch zaˇr´ızen´ı, které pracuj´ı relativnˇe samostatnˇe, k decentralizaci ˇr´ızen´ı. To klade vˇetˇs´ı d˚ uraz na rychlost a pˇresnost vzájemné synchronizace jednotliv´ ych zaˇr´ızen´ı a pˇresné generován´ı ˇr´ıd´ıc´ıho taktu pro dalˇs´ı zaˇr´ızen´ı. Koordinaci a pˇresné ˇcasován´ı zaˇr´ızen´ı je potˇreba ˇreˇsit pomoc´ı s´ıt’ového propojen´ı a jednou z moˇznost´ı, která je nejv´ıce rozv´ıjena a diskutována, je vyuˇzit´ı standardn´ı paketové s´ıtˇe Ethernet.

Pˇ r´ınos t´ eto disertaˇ cn´ı pr´ ace Hlavn´ı nápln´ı této disertaˇcn´ı práce je anal´ yza moˇznost´ı synchronizace ˇcasu v paketov´ ych s´ıt´ıch a zv´ yˇsen´ı pˇresnosti synchronizace ˇcasu i generován´ı taktu. Pro synchronizaci ˇcasu se vyuˇz´ıvá nˇekolik synchronizaˇcn´ıch protokol˚ u. Základn´ı princip synchronizace ˇcasu je u vˇsech protokol˚ u podobn´ y a spoˇc´ıvá ve v´ ymˇenˇe ˇcasov´ ych zpráv mezi serverem a klientem. Hlavn´ım problémem pˇri synchronizaci ˇcasu je zpoˇzdˇen´ı pˇri doruˇcován´ı jednotliv´ ych zpráv pomoc´ı paket˚ u. V pˇr´ıpadˇe generován´ı taktu je nejd˚ uleˇzitˇejˇs´ım aspektem pˇresnost generátoru a jeho schopnost doladˇen´ı na základˇe informac´ı z´ıskan´ ych ze synchronizaˇcn´ıho protokolu. Hlavn´ı oblasti této práce lze shrnout do následuj´ıc´ıch bod˚ u: 1. Mˇeˇren´ı a anal´ yza zp˚ usob˚ u synchronizace ˇcasu klienta v r˚ uzn´ ych s´ıt´ıch a za r˚ uzn´ ych podm´ınek. 2. Simulace zp˚ usobu synchronizace ˇcasu u stávaj´ıc´ıch synchronizaˇcn´ıch protokol˚ u. 3. Vytvoˇren´ı optimalizovan´ ych algoritm˚ u a simulaˇcn´ıho modelu na stranˇe klienta, kter´ y vylepˇsuje v´ yslednou pˇresnost synchronizace ˇcasu. 9

10

´ KAPITOLA 1. UVOD 4. Implementace generátoru taktu do simulaˇcn´ıho modelu na stranˇe klienta za u ´ˇcel zv´ yˇsen´ı pˇresnosti stability generovaného taktu.

Pˇredloˇzená práce shrnuje v´ ysledky v´ yzkumu v oblasti synchronizace ˇcasu v paketov´ ych s´ıt´ıch v návaznosti na návrh synchronizaˇcn´ı jednotky s generátorem taktu a navrhuje moˇznosti vylepˇsen´ı pro budouc´ı implementaci do jednotliv´ ych zaˇr´ızen´ı.

Kapitola 2 Souˇ casn´ y stav ˇ reˇ sen´ e problematiky Paketové s´ıtˇe jsou nejrychleji se rozv´ıjej´ıc´ım typem s´ıt´ı v souˇcasnosti. Pˇrenosy pˇres paketové s´ıtˇe jsou dnes vyuˇz´ıvané i v páteˇrn´ıch s´ıt´ıch, kde dˇr´ıve byly vyuˇz´ıvané jiné technologie. Ethernet je nejznámˇejˇs´ım zástupcem paketov´ ych s´ıt´ı. Jeˇstˇe pˇred rokem 2000 se Ethernet [4] stal dominantn´ı technologi´ı pro drátové lokáln´ı s´ıtˇe (LAN). Dnes je Ethernet definován i pro optické vlákno, kde je dosahováno rychlosti des´ıtek Gbit/s. V závislosti na rozˇsiˇrován´ı paketov´ ych s´ıt´ı do pr˚ umyslové oblasti se vzájemná synchronizace zaˇr´ızen´ı stává poˇzadovanou funkˇcnost´ı jednotliv´ ych zaˇr´ızen´ı. Proto je synchronizace v paketov´ ych s´ıt´ıch velice diskutovan´ ym problémem [12]. Moje práce se zamˇeˇruje na synchronizaci a distribuci ˇcasu v paketov´ ych s´ıt´ıch a následné generován´ı pˇresného taktu. Network Time Protocol (NTP), Simple Network Time Protocol (SNTP) a relativnˇe nov´ y IEEE-1588 Precision Time Protocol (PTP) patˇr´ı mezi nejrozˇs´ıˇrenˇejˇs´ı synchronizaˇcn´ı protokoly. Network Time Protocol [1] patˇr´ı mezi nejznámˇejˇs´ı protokoly a je vyuˇz´ıván k synchronizaci ˇcasu poˇc´ıtaˇc˚ u pˇres Internet. SNTP [2] je zjednoduˇsen´ y synchronizaˇcn´ı protokol vycházej´ıc´ı z NTP, kter´ y má horˇs´ı pˇresnost synchronizace. Nejnovˇejˇs´ı synchronizaˇcn´ı protokol popisuje standard IEEE 1588 a je také znám´ y jako PTP (Precision Time Protocol). Prvn´ı návrh standardu byl vydán v roce 2002, ale v roce 2008 byla vydána druhá revize tohoto dokumentu [6]. Hlavn´ım rozd´ılem mezi NTP a PTP protokolem jsou moˇznosti jejich implementace. Zat´ımco NTP dovoluje pouze softwarovou implementaci, PTP protokol umoˇzn ˇuje jak softwarovou, tak hardwarovou implementaci. Hardwarová implementace umoˇzn ˇuje pˇresnˇejˇs´ı urˇcen´ı ˇcasu pˇrijet´ı ˇci odeslán´ı paketu, ˇc´ımˇz se zvyˇsuje v´ ysledná pˇresnost synchronizace [23].

2.1

ˇ Casov´ a synchronizace v paketov´ ych s´ıt´ıch

Obsahem této kapitoly jsou jednotlivé moˇznosti synchronizace ˇcasu v paketov´ ych s´ıt´ıch, popis jednotliv´ ych protokol˚ u, které synchronizaci umoˇzn ˇuj´ı a jejich vlastnosti. Jak bylo zm´ınˇeno v u ´vodu, mezi nejznámˇejˇs´ı protokoly patˇr´ı Network Time Protocol (NTP) a Precision Time Protocol (PTP). NTP je velice populárn´ı a ˇsiroce rozˇs´ıˇren´ y hlavnˇe v poˇc´ıtaˇcov´ ych s´ıt´ıch, kde se pouˇz´ıvá k synchronizaci ˇcasu poˇc´ıtaˇc˚ u a jednotliv´ ych s´ıt’ov´ ych 11

ˇ ´ STAV RE ˇ SEN ˇ E ´ PROBLEMATIKY KAPITOLA 2. SOUCASN Y

12

zaˇr´ızen´ı. Pˇresnost NTP protokolu je v ˇra´du jednotek aˇz des´ıtek milisekund. PTP protokol je dnes nejpˇresnˇejˇs´ım protokolem pro synchronizaci ˇcasu pˇres paketové s´ıtˇe. Jeho pˇresnost pˇri hardwarové podpoˇre je v ˇra´du des´ıtek nanosekund. NTP protokol vyuˇz´ıvá podobn´ ych princip˚ u jako PTP, nicménˇe hlavn´ı d˚ uvod lepˇs´ı pˇresnosti synchronizace u PTP je pˇresné urˇcen´ı pˇr´ıchodu ˇcasové znaˇcky na u ´rovn´ı s´ıt’ové karty, to ale vyˇzaduje hardwarovou implementaci protokolu. Tato vlastnost speciáln´ı hardwarové podpory m˚ uˇze b´ yt jasnou nev´ yhodou oproti NTP.

2.2

Network Time Protocol

Network Time Protocol (NTP) je jeden z nejstarˇs´ıch a nejrozˇs´ıˇrenˇejˇs´ıch protokol˚ u, kter´ y je vyuˇz´ıván pro ˇcasovou synchronizaci v prostˇred´ı Internetu. NTP byl primárnˇe vynalezen pro synchronizaci hodin v poˇc´ıtaˇc´ıch a jeho struktura umoˇzn ˇuje i synchronizaci jednotliv´ ych d˚ uvˇeryhodn´ ych ˇcasov´ ych server˚ u, které následnˇe poskytuj´ı pˇresn´ y ˇcas sv´ ym klient˚ um. Bylo vytvoˇreno nˇekolik verz´ı tohoto protokolu. Nejrozˇs´ıˇrenˇejˇs´ı verz´ı je verze 3, kterou vytvoˇril David Mills v roce 1992 [1]. NTP vyuˇz´ıvá konceptu jednotliv´ ych u ´rovn´ı, které jsou oznaˇcovány jako stratum. Jedná se o hierarchick´ y model, kde kaˇzdé zaˇr´ızen´ı v urˇcité vrstvˇe m˚ uˇze fungovat jako ˇcasov´ y server pro zaˇr´ızen´ı v niˇzˇs´ı vrstvˇe (obr. 2.1). Stratum 0 reprezentuj´ı servery se samostatn´ ymi ˇ ım vyˇsˇs´ı ˇc´ıslo stratum, t´ım niˇzˇs´ı pˇresnost hodin. Stratum 1 a 2 referenˇcn´ımi hodinami. C´ maj´ı NTP servery velk´ ych poskytovatel˚ u a stratum 3 a 4 jsou uˇz pro klienty ˇci lokáln´ı poskytovatele. NTP klient um´ı pˇrijmout ˇcasovou informaci souˇcasnˇe od v´ıce NTP server˚ u, coˇz umoˇzn´ı pˇresnˇejˇs´ı urˇcen´ı ˇcasu. Transportn´ım protokolem pro NTP pakety je UDP (User Datagram Protocol), kter´ y pouˇz´ıvá port 123. UDP nevytváˇr´ı stálé pˇripojen´ı mezi serverem a klientem.

Obrázek 2.1: Hierarchie jednotliv´ ych vrstev NTP [22] NTP vyuˇz´ıvá nˇekolik algoritm˚ u, které jsou urˇceny pro specifické ˇcinnosti a mezi které

2.2. NETWORK TIME PROTOCOL

13

patˇr´ı napˇr´ıklad Marzulloho algoritmus. Tento algoritmus se stará o v´ ybˇer jednoho synchronizaˇcn´ıho serveru z nˇekolika server˚ u. Algoritmus je schopn´ y urˇcit, které ˇcasové servery maj´ı ’ nejvyˇsˇs´ı pˇresnost. Dalˇs´ı algoritmus zajiˇst uje správn´ y synchronizaˇcn´ı proces a je zaloˇzen na postupném pˇribliˇzován´ı k pˇresnému ˇcasu. U algoritmu m˚ uˇzeme rozliˇsit dvˇe fáze. Prvn´ı fáze je pouˇzita pˇri velkém rozd´ılu ˇcasu klienta a serveru (obvykle nad 125 milisekund) a v tomto ˇ klienta se okamˇzitˇe uprav´ı o vypoˇctenou kopˇr´ıpadˇe dojde ke skokové synchronizaci. Cas rekci. V druhé fázi docház´ı k pravidelné synchronizaci, která pozvolna zpˇresˇ nuje ˇcas klienta.

2.2.1

V´ ypoˇ cet korekce ˇ casu

NTP protokol je zaloˇzen na v´ ymˇenˇe ˇcasov´ ych zpráv mezi jednotliv´ ymi zaˇr´ızen´ımi, kter´ ymi m˚ uˇzou b´ yt jak servery, tak poˇc´ıtaˇce ˇci jiná s´ıt’ová zaˇr´ızen´ı [1]. Jednotlivé ˇcasové ˇ znaˇcky jsou pˇrenáˇseny v NTP paketech. Casov´ a znaˇcka je ˇc´ıslo, které udává datum a ˇcas. ˇ Casová znaˇcka je v paketu reprezentována ˇc´ıslem o velikosti 64 bit˚ u, kde prvn´ıch 32 bit˚ u reprezentuje poˇcet sekund od 1. ledna 1900 a druh´ ych 32 bit˚ u vyjadˇruje ˇc´ıslo za desetinou teˇckou. Jsme tedy schopni pˇrenáˇset ˇcas s pˇresnost´ı 232 ps. Pˇri synchronizaci ˇcasu klient poˇsle dotaz na NTP server, kter´ y dopln´ı svou lokáln´ı ˇcasovou znaˇcku a poˇsle ji zpˇet klientovi. Jeden klient se m˚ uˇze dotazovat souˇcasnˇe nˇekolik NTP server˚ u a podle vestavˇeného algoritmu vybere ten nejvhodnˇejˇs´ı. V´ ysledná ˇcasová korekce lokáln´ıch hodin je následnˇe vypoˇc´ıtávána ze vˇsech ˇcasov´ ych znaˇcek zobrazen´ ych na ilustraˇcn´ım obrázku 2.2. Zaˇca´tek komunikace zahajuje klient, kter´ y vyˇsle ˇza´dost ve formˇe NTP paketu, kter´ y obsahuje prvn´ı ˇcasovou znaˇcku T1 (ˇcas odeslán´ı poˇzadavku). Poté co server pˇrijme tuto zprávu, vygeneruje ˇcasovou znaˇcku T2 , která reprezentuje ˇcas pˇrijet´ı NTP paketu. Následnˇe server poˇzadavek zpracuje a pos´ılá zpˇet NTP paket, do kterého tˇesnˇe pˇred odeslán´ım dopln´ı ˇcasovou znaˇcku T3 . Posledn´ım krokem je pˇrijet´ı paketu klientem v ˇcase T4 .

ˇ Obrázek 2.2: Casov´ e znaˇcky pˇri komunikaci klienta se serverem Z tˇechto ˇctyˇrech ˇcasov´ ych znaˇcek je vypoˇc´ıtáno zpoˇzdˇen´ı s´ıtˇe δ (2.1) a odchylka ˇcasu serveru a klienta (offset) o (2.4). δ = ((T4 − T1 ) − (T3 − T2 ))/2

(2.1)


14

V´ ypoˇcet s´ıt’ového zpoˇzdˇen´ı pˇredpokládá, ˇze zpoˇzdˇen´ı ve smˇeru od klienta k serveru je stejné jako ve smˇeru od serveru ke klientovi. Pˇresnˇe jsme schopni urˇcit jen celkové zpoˇzdˇen´ı tam i zpˇet (T4 − T1 ) − (T3 − T2 ). Rozd´ıl ˇcasu serveru a klienta vyjadˇruje, o kolik se má ˇcas klienta upravit, aby odpov´ıdal ˇcasu serveru. Rovnice (2.2) prezentuje ideáln´ı pˇr´ıpad, kdy ˇcas klienta je pˇresnˇe zasynchronizován s ˇcasem serveru. T4 = T3 + δ (2.2) V pˇr´ıpadˇe, ˇze klient nen´ı zasynchronizován, mus´ı se k ˇcasu klienta pˇriˇc´ıst korekce o, která ˇcas klienta uprav´ı. V´ ysledn´ y v´ ypoˇcet hodnoty korekce po u ´pravách je uveden ve vztahu 2.4. o + T4 o

2.2.2

= T3 + δ = (T2 − T1 + T3 − T4 )/2

(2.3) (2.4)

V´ ykonnost NTP protokolu

Pˇresnost NTP protokolu je znaˇcnˇe závislá na vzdálenosti od NTP serveru. V pˇr´ıpadˇe velk´ ych s´ıt´ı jako je tˇreba Internet se pˇresnost synchronizace ˇcasu pohybuje v ˇra´du des´ıtek milisekund. V pˇr´ıpadˇe lokáln´ıch s´ıt´ı (LAN) je pˇresnost synchronizace v rozmez´ı od 0,5 do 10 milisekund. Studie [23] uvád´ı pro lokáln´ı s´ıtˇe pr˚ umˇernou hodnotu ˇcasové nepˇresnosti 8,2 milisekundy, medián 1,8 milisekundy a smˇerodatnou odchylku 18 milisekund. V pˇr´ıpadˇe Internetu byla zjiˇstˇena pr˚ umˇerná hodnota 88 milisekund, medián 30 milisekund a smˇerodatná odchylka 175 milisekund. Na pˇresnost synchronizace má vliv mnoho faktor˚ u. Promˇenlivé zpoˇzdˇen´ı s´ıtˇe m˚ uˇzeme povaˇzovat za nejv´ yznamnˇejˇs´ı a je zejména zp˚ usobeno s´ıt’ov´ ymi prvky v cestˇe mezi klientem a serverem (pˇrep´ınaˇce, smˇerovaˇce). V kapitole 2.6.1 je popsané mˇeˇren´ı v reálné s´ıti s NTP.

2.3

IEEE 1588 – Precision Time Protocol

Pˇresn´ y ˇcasov´ y protokol (The Precision Time Protocol - PTP) je název pro synchronizaˇcn´ı protokol umoˇznuj´ıc´ı synchronizaci ˇcasu v paketov´ ych s´ıt´ıch a je popsán ve standardu IEEE 1588. Prvn´ı verze tohoto standardu byla publikována v roce 2002. Druhá verze, která je nyn´ı aktuáln´ı a pˇrináˇs´ı malé zmˇeny a vylepˇsen´ı, byla publikována v roce 2008. C´ılem v´ yvoje protokolu PTP bylo hlavnˇe zv´ yˇsen´ı pˇresnosti synchronizace [29]. D˚ uraz pˇri v´ yvoji a formulaci standardu byl kladen zejména na: • v´ yslednou pˇresnost synchronizace ˇcasu, která je v ˇra´du des´ıtek aˇz stovek nanosekund • vytvoˇren´ı mezinárodn´ıho standardu, kter´ y by zajistil interoperabilitu zaˇr´ızen´ı jednotliv´ ych v´ yrobc˚ u a umoˇznil tak vˇetˇs´ı rozˇs´ıˇren´ı a vyuˇzit´ı tohoto synchronizaˇcn´ıho protokolu

2.3. IEEE 1588 – PRECISION TIME PROTOCOL

15

• vˇsestrannost a univerzálnost protokolu, kter´ y umoˇzn´ı vyuˇzit´ı v nejrozˇs´ıˇrenˇejˇs´ıch typech s´ıt´ı (Ethernet), dále pouˇzitelnost i v mal´ ych s´ıt´ıch ˇci pods´ıt´ıch s minimáln´ımi nároky na správu, n´ızké nároky na hardware a v´ ypoˇcetn´ı v´ ykon jednotliv´ ych zaˇr´ızen´ı PTP protokol slouˇz´ı k synchronizaci ˇcasu vˇsech zaˇr´ızen´ı, která jsou pˇripojena k jedné s´ıti. PTP protokol je zaloˇzen na pˇrenosu synchronizaˇcn´ıch zpráv mezi jednotliv´ ymi zaˇr´ızen´ımi. Aby bylo dosaˇzeno vysoké pˇresnosti synchronizace ˇcasu, je na zaˇca´tku synchronizaˇcn´ıho algoritmu nutné urˇcit zaˇr´ızen´ı s nejpˇresnˇejˇs´ım ˇcasem a toto zaˇr´ızen´ı je v rámci synchronizaˇcn´ıho algoritmu oznaˇceno jako hlavn´ı (master). Ostatn´ı zaˇr´ızen´ı se následnˇe chovaj´ı jako podˇr´ızená, ale i u nich docház´ı k urˇcité konfiguraci, a to podle toho zda jsou hraniˇcn´ımi zaˇr´ızen´ımi (boundary) a nebo bˇeˇzn´ ymi koncov´ ymi zaˇr´ızen´ımi (ordinary). Hraniˇcn´ı s´ıt’ové prvky pˇrij´ımaj´ı synchronizaci od hlavn´ıho (master) s´ıt’ového prvku a následnˇe ji pˇredávaj´ı koncov´ ym s´ıt’ov´ ym prvk˚ um (obr. 2.3). Druhá verze PTP nav´ıc definuje takzvané pr˚ uchoz´ı hodiny (transparent clock) [13], kter´ ym se budeme vˇenovat pozdˇeji.

Obrázek 2.3: Topologie jednoduché s´ıtˇe Pˇr´ıklad jednoduché s´ıtˇe je zobrazen na obrázku 2.3. Jsou zde zobrazeny dvoje hraniˇcn´ı hodiny a dvoje standardn´ı. Pˇri startu je nastaveno jedno zaˇr´ızen´ı jako hlavn´ı (master) a to podle pˇresnosti vnitˇrn´ıch hodin jednotliv´ ych zaˇr´ızen´ı. Následnˇe toto zaˇr´ızen´ı poskytuje pˇresn´ y ˇcas ostatn´ım. Zaˇr´ızen´ı, které maj´ı v´ıce port˚ u (napˇr´ıklad pˇrep´ınaˇce), mohou m´ıt nˇekteré porty v reˇzimu slave a nˇekteré v reˇzimu master (v obrázku oznaˇceno jako S a M). To znamená, ˇze zaˇr´ızen´ı se synchronizuj´ı z jednoho zdroje a pˇresn´ y ˇcas dále poskytuj´ı dalˇs´ım zaˇr´ızen´ım. Algoritmus, kter´ y urˇcuje nejpˇresnˇejˇs´ı hodiny, se naz´ yvá Best Master Clock (BMC). Detailn´ı popis návrhu a realizace jednotliv´ ych topologi´ı je popsána v kapitole 3.3 v knize [14]. Po nastaven´ı jednotliv´ ych s´ıt’ov´ ych prvk˚ u a urˇcen´ı master-slave hierarchie dojde ke spuˇstˇen´ı synchronizace mezi jednotliv´ ymi prvky. Pˇresn´ y ˇcas je na jednotliv´ ych s´ıt’ov´ ych prvc´ıch urˇcován v´ ypoˇctem. Podobnˇe jako u NTP protokolu docház´ı k v´ ypoˇctu zpoˇzdˇen´ı paketu mezi dvˇema zaˇr´ızen´ımi a následnˇe je vypoˇc´ıtána korekce ˇcasu klienta. Vyuˇzit´ı vysoké pˇresnosti synchronizace ˇcasu a tedy celého protokolu PTP se najde v mnoha oblastech. Jednou z nich jsou napˇr´ıklad mˇeˇr´ıc´ı systémy, kde potˇrebujeme znát

16


pˇresn´ y okamˇzik mˇeˇren´ı urˇcitého senzoru. Proto je potˇreba m´ıt pˇresnˇe synchronizovan´ y ˇcas v mˇeˇr´ıc´ım zaˇr´ızen´ı. Synchronn´ı sbˇer dat, registrace událost´ı a dalˇs´ı funkce vyˇzaduj´ı vysokou pˇresnost synchronizace. Uplatnˇen´ı je moˇzné naj´ıt napˇr´ıklad v inteligentn´ıch s´ıt´ıch ”Smart Grid”, které vznikaj´ı v oblasti ˇr´ızen´ı energetick´ ych s´ıt´ı. PTP se také vyuˇz´ıvá v telekomunikac´ıch napˇr´ıklad pro synchronizaci taktu základnov´ ych stanic v mobiln´ı s´ıti a následnˇe generován´ı taktu pro dalˇs´ı zaˇr´ızen´ı v mobiln´ı s´ıti. Tento protokol je velice vhodné vyuˇz´ıt v pˇr´ıpadˇe potˇreby generován´ı pˇresného taktu pro dalˇs´ı zaˇr´ızen´ı v odlehlé lokalitˇe. D´ıky tomuto protokolu nepotˇrebujeme budovat samostatnou synchronizaˇcn´ı s´ıt’, coˇz má pˇr´ımou návaznost na finanˇcn´ı náklady. Vlastnosti a frekvence generovaného taktu je závislá na moˇznostech koncového zaˇr´ızen´ı.

2.3.1

Architektura PTP

Standardn´ı synchronizaˇcn´ı protokoly byly vˇzdy implementovány jen softwarovˇe a to pˇrináˇs´ı urˇcité nev´ yhody [23]. PTP protokol pˇrináˇs´ı moˇznost jak softwarové, tak hardwarové implementace. Hardwarová implementace je nároˇcnˇejˇs´ı a jednotlivá zaˇr´ızen´ı mus´ı podporovat tento synchronizaˇcn´ı protokol, ale v´ ysledná pˇresnost synchronizace je mnohem lepˇs´ı v porovnán´ı se softwarovou implementac´ı. Hardwarová implementace umoˇzn ˇuje pˇresné urˇcen´ı ˇcasu pˇr´ıchoz´ıho a odchoz´ıho PTP paketu na fyzické médium.

IEEE 1588 (PTP) Aplika ní vrstva Port

Rozhraní asového razítka

Rozhraní Hodin SW

Sí ový Protokol (OS)

Jednotka asového razítka

Hardwarové Hodiny

MAC

PHY

HW

Fyzické p ipojení

Obrázek 2.4: Architektura synchronizaˇcn´ı jednotky s PTP. [23] Architektura protokolu PTP je specifická t´ım, ˇze jsou oddˇelené ˇcasovˇe nároˇcné u ´koly, které jsou implementovány v hardwaru a pak samotn´ y protokol. D´ıky tomuto docház´ı


17

k rozdˇelen´ı hardwarové a softwarové ˇca´sti. Z toho vypl´ yvaj´ı niˇzˇs´ı nároky na v´ ykonnost procesoru. Hardwarová jednotka obsahuje velmi pˇresné hodiny a jednotku ˇcasového raz´ıtka (TSU Time Stamp Unit). Jednotka ˇcasového raz´ıtka zajiˇst’uje vloˇzen´ı ˇci vyjmut´ı ˇcasov´ ych znaˇcek z paketu. Softwarová ˇca´st implementuje protokol IEEE 1588 s vazbou na pˇresné hodiny a jednotku ˇcasového raz´ıtka (Obr. 2.4). Protokol podle IEEE 1588 je nezávisl´ y na operaˇcn´ım systému, a proto je tˇreba vytvoˇrit mezivrstvu, která bude komunikovat mezi operaˇcn´ım systémem a protokolem. M˚ uˇzeme tedy hovoˇrit o tˇrech vrstvách. Prvn´ı vrstva implementuje synchronizaci v s´ıti a lze j´ı nalézt v r˚ uzn´ ych komunikaˇcn´ıch zaˇr´ızen´ı (switch, router, PC). Mezivrstva oznaˇcovaná jako Abstraction Layer zajiˇst’uje pˇredáván´ı potˇrebn´ ych informac´ı mezi operaˇcn´ım systémem a PTP (protokolovou vrstvou). Komunikace této vrstvy s protokolovou vrstvou je realizována pomoc´ı fronty. Mezivrstva obsahuje nˇekolik rozhran´ı. Rozhran´ı ˇcasového raz´ıtka zpracovává jednotlivé zprávy ze s´ıt’ové komunikace a rozhran´ı hodin slouˇz´ı ke ˇcten´ı a modifikován´ı lokáln´ıch hodin. Pˇri realizaci mohou b´ yt pouˇzity napˇr´ıklad systémové hodiny z operaˇcn´ıho systému, pokud nebudou realizovány ˇza´dné hardwarové hodiny. Posledn´ım rozhran´ım je rozhran´ı portu, které se pouˇz´ıvá k vys´ılán´ı a pˇr´ıjmu PTP zpráv. PTP m˚ uˇze kromˇe UDP/IP vyuˇz´ıt jenom IP protokolu. Detailn´ı popis moˇzné hardwarové implementace pomoc´ı FPGA je popsán v ˇclánku ”Design and implementation of IEEE1588 time synchronization messages timestamping based on FPGA”[21].

2.3.2

Princip synchronizace u PTP

Princip synchronizace klienta je uveden na obrázku 2.5. Hodnoty zpoˇzdˇen´ı a poˇca´teˇcn´ıch ˇcas˚ u jsou z názorného d˚ uvodu zvoleny tak, aby se s nimi dobˇre poˇc´ıtalo a neodpov´ıdaj´ı realitˇe. Jelikoˇz ˇcasov´ y rozd´ıl mezi hlavn´ımi a podˇr´ızen´ ymi hodinami je souˇctem offsetu (rozd´ılu) hodin a pˇrenosov´ ym zpoˇzdˇen´ım s´ıtˇe, prob´ıhá synchronizace ve dvou fáz´ıch: oprava offsetu a korekce vlivu s´ıt’ového zpoˇzdˇen´ı. V prvn´ım fázi je vys´ılána synchronizaˇcn´ı zpráva “Sync”, která je následována zprávou “Následuj´ıc´ı zpráva”. Hodnoty Tm a Ts pˇredstavuj´ı aktuáln´ı ˇcasy na zaˇr´ızen´ı master a slave. Hodnoty TM a TS vyjadˇruj´ı ˇcasy, kdy byl odeslán nebo pˇrijat paket. Ve zprávˇe “Sync” se pˇrenáˇs´ı informaci o ˇcasu hlavn´ı ˇcasové základny v dobˇe, kdy byla zpráva odeslána. Tato hodnota se “Následuj´ıc´ı zprávou” potvrd´ı, nebo m˚ uˇze doj´ıt k upˇresnˇen´ı této hodnoty vlivem kontroln´ıch mechanism˚ u masteru. Vedlejˇs´ı ˇcasová základna tyto zprávy pˇrijme a provede v´ ypoˇcet offsetu na základˇe rozd´ılu svého intern´ıho ˇcasu a ˇcasu pˇrijatého v synchronizaˇcn´ıch zprávách. Na základˇe offsetu je následnˇe upravena hodnota ˇcasu v synchronizuj´ıc´ım se zaˇr´ızen´ı. Ve druhé fázi (obr. 2.6) se urˇcuje zpoˇzdˇen´ı mezi hlavn´ı a vedlejˇs´ı ˇcasovou základnou. Vedlejˇs´ı ˇcasová základna poˇsle zprávu “Dotaz” a zaˇcne mˇeˇrit dobu pˇrenosu zprávy. Hlavn´ı ˇcasová základna pˇrijme zprávu, pˇreˇcte si sv˚ uj aktuáln´ı ˇcas, kter´ y dopln´ı do zprávy “Od’ povˇed ” a odeˇsle zprávu zpˇet. Po pˇrijet´ı zprávy vedlejˇs´ı ˇcasovou základnou dojde k v´ ypoˇctu zpoˇzdˇen´ı a k opravˇe ˇcasu na zaˇr´ızen´ı.

18


Obrázek 2.5: Korekce offsetu [14] D´ıky tomu, ˇze mˇeˇren´ı je provádˇeno vˇzdy jen mezi dvˇema prvky s´ıtˇe, se v´ ysledná pˇresnost pohybuje v ˇra´dech des´ıtek nanosekund. Mˇeˇren´ı zpoˇzdˇen´ı je vykonáváno nepravidelnˇe. Hodnota intervalu je mezi 4 a 60 sekundami, kde 60 sekund je nastaveno jako základn´ı. D´ıky této moˇznosti lze ovlivnit zat´ıˇzen´ı s´ıtˇe, které m˚ uˇze b´ yt nepatrné. 2.3.2.1

Pr˚ uchoz´ı hodiny

Pojem transparent clock [25, 16, 17], kter´ y m˚ uˇzeme pˇreloˇzit jako pr˚ uchoz´ı hodiny, byl zaveden aˇz v druhé verzi standardu pro PTP protokol vydaného v roce 2008. D˚ uvodem byla niˇzˇs´ı v´ ysledná pˇresnost ˇcasu klienta pˇri pouˇzit´ı v´ıce prvk˚ u v s´ıti, které byly zapojeny sériovˇe. V pˇr´ıpadˇe vˇetˇs´ıho zat´ıˇzen´ı urˇcité cesty, která m˚ uˇze b´ yt dokonce asymetrická, docház´ı pˇri pˇrenosu k vˇetˇs´ımu zpoˇzdˇen´ı PTP paket˚ u urˇcit´ ym smˇerem. To se následnˇe projevuje ve vˇetˇs´ı nepˇresnosti synchronizace jednotliv´ ych zaˇr´ızen´ı, které se ve v´ ysledku sˇc´ıtaj´ı. Dále v pˇr´ıpadˇe zmˇeny konfigurace s´ıtˇe roste ˇcas k resynchronizaci vˇsech hodin za zmˇenˇen´ ym ’ s´ıt ov´ ym prvkem. Ve standardu IEEE 1588 jsou definovány dva reˇzimy pr˚ uchoz´ıch hodin (Transparent Clock TC) a to End-to-End a Peer-to-Peer. S´ıt’ová zaˇr´ızen´ı v reˇzimu pr˚ uchoz´ıch hodin neprovádˇej´ı synchronizaci sv´ ych vnitˇrn´ıch hodin. Princip TC hodin je takov´ y, ˇze mˇeˇr´ı a kompenzuj´ı zpoˇzdˇen´ı, které vzniká pˇri pr˚ uchodu synchronizaˇcn´ıho paketu pˇres blok TC hodin. End-to-End (E2E) TC pˇredává synchronizaˇcn´ı zprávu Sync od serveru nezmˇenˇenou a zamˇeˇruje se jen na pˇresné zmˇeˇren´ı zpoˇzdˇen´ı paketu v daném zaˇr´ızen´ı. Kaˇzdé zaˇr´ızen´ı


19

Obrázek 2.6: Mˇeˇren´ı zpoˇzdˇen´ı [14] nastavené v reˇzimu E2E TC a um´ıstˇené mezi masterem a slavem urˇcuje, kdy synchronizaˇcn´ı PTP paket pˇriˇsel a kdy odeˇsel a v´ yslednou délku zpoˇzdˇen´ı zaznamenává a pos´ılá dále. Klient tuto hodnotu spolu s hodnotami od serveru pouˇzije pˇri v´ ypoˇctu v´ ysledné odchylky svého ˇcasu. V pˇr´ıpadˇe pouˇzit´ı reˇzimu Peer-to-Peer (P2P) nen´ı mˇeˇreno jen zpoˇzdˇen´ı v daném zaˇr´ızen´ı, ale je zde zahrnováno i zpoˇzdˇen´ı trasy. Jednotlivá zaˇr´ızen´ı zjiˇst’uj´ı zpoˇzdˇen´ı jednotliv´ ych pˇripojen´ ych tras pomoc´ı Peer delay mechanismu. Namˇeˇrená zpoˇzdˇen´ı jsou následnˇe vyhodnocována a pˇripoˇc´ıtávána ke zpoˇzdˇen´ı jednotliv´ ych s´ıt’ov´ ych prvk˚ u a dále pˇredávána koncov´ ym klient˚ um. Klient tyto hodnoty vyuˇz´ıvá k urˇcen´ı pˇresnˇejˇs´ıho zpoˇzdˇen´ı a následnˇe k pˇresnˇejˇs´ı korekci lokáln´ıch hodin.

2.3.3

Vlastnosti PTP

Dosahovaná pˇresnost hardwarové implementace je v ˇra´du des´ıtek nanosekund. Bylo provedeno nˇekolik r˚ uzn´ ych reáln´ ych mˇeˇren´ı, které jsou popsány v kapitole 2.6.2. Hlavn´ım omezen´ım v pˇr´ıpadˇe hardwarová implementace PTP je nutnost nov´ ych zaˇr´ızen´ı s podporou daného protokolu. Proto je PTP momentálnˇe vyuˇz´ıván sp´ıˇse v menˇs´ıch s´ıt´ıch, kde lze um´ıstit jeden synchronizaˇcn´ı server s pˇresn´ ym ˇcasem, kter´ y distribuuje synchronizaci ke koncov´ ym bod˚ um s´ıtˇe. Tento protokol se v posledn´ım obdob´ı velice rychle vyv´ıj´ı a zaˇc´ıná b´ yt souˇca´st´ı jednotliv´ ych s´ıt’ov´ ych zaˇr´ızen´ı.

20


Obrázek 2.7: Blokové schéma vyuˇzit´ı pr˚ uchoz´ıch hodin

Obrázek 2.8: Jednotlivá zpoˇzdˇen´ı v s´ıti

2.4. SYNCHRONNÍ ETHERNET

2.4

21

Synchronn´ı Ethernet

Jako dalˇs´ı alternativou, která umoˇzn ˇuje synchronizaci v Ethernet s´ıti, je Synchronn´ı Ethernet. Synchronn´ı Ethernet (oznaˇcovan´ y jako SyncE) vyuˇz´ıvá pˇr´ımo fyzické vrstvy a takt je odvozován pˇr´ımo z pˇrenáˇseného bitového toku dat. Je zde vyuˇz´ıváno podobného principu jako napˇr´ıklad u E1 signálu v telekomunikac´ıch. Synchronn´ı Ethernet byl standardizován organizac´ı ITU-T ve spolupráci s IEEE a je popsán ve tˇrech doporuˇcen´ıch [5, 8, 7]. Synchronn´ı Ethernet nelze u ´plnˇe porovnávat s pˇredchoz´ımi protokoly jako je PTP ˇci NTP. Pˇri synchronizaci, která prob´ıhá po fyzické vrstvˇe, nen´ı moˇzné pˇrenáˇset ˇza´dnou informaci o ˇcase, a proto se zde mluv´ı o synchronizaci taktu. Pro urˇcitou správu a informaci o pˇresnosti se samozˇrejmˇe vyuˇz´ıvaj´ı protokoly vyˇsˇs´ıch vrstev. Konkrétnˇe se jedná o zprávy SSM (synchronization status message). Synchronn´ı Ethernet hlavnˇe ˇreˇs´ı synchronizaci taktu jednotliv´ ych zaˇr´ızen´ı. Pro vˇetˇsinu zaˇr´ızen´ı, které maj´ı mezi sebou komunikovat, je synchronizace taktu dostateˇcná, protoˇze nepotˇrebuj´ı znát pˇresn´ y ˇcas. Vzájemná synchronizace jim umoˇzn ˇuje lepˇs´ı fungován´ı, coˇz pˇrisp´ıvá ke zv´ yˇsen´ı kvality sluˇzby.

Obrázek 2.9: Funkce synchronn´ıho Ethernetu Struktura a funkce s´ıt’ového adaptéru u Synchronn´ıho Ethernetu je zobrazena na obrázku 2.9. Hlavn´ım blokem je synchronizaˇcn´ı jednotka, která dodává takt (nebo pˇrij´ımá) do (nebo z) fyzického rozhran´ı s´ıt’ového adaptéru. Tento signál m˚ uˇze b´ yt brán z extern´ıho vstupu nebo z vnitˇrn´ıho oscilátoru. V pˇr´ıpadˇe hlavn´ıho zaˇr´ızen´ı je vyˇzadována vysoká stabilita oscilátoru, a proto jsou tyto oscilátory mnohem pˇresnˇejˇs´ı. Dále je nutné urˇcit´ ym zp˚ usobem ˇr´ıdit a nastavovat Synchronizaˇcn´ı jednotku, a proto je nutné propojen´ı s MAC (Medium Access Layer). Velkou v´ yhodou u Synchronn´ıho Ethernetu je moˇznost pˇrenosu taktovac´ıho signálu pro jiná zaˇr´ızen´ı. Napˇr´ıklad do hlavn´ıho zaˇr´ızen´ı pracuj´ıc´ıho na Ethernetu m˚ uˇze b´ yt zaveden synchronizaˇcn´ı signál napˇr´ıklad ze s´ıtˇe SDH a na konci je tento signál vyveden a pˇripojen zase do jiné s´ıtˇe SDH. Synchronn´ı Ethernet m˚ uˇze slouˇzit k pˇreklenut´ı urˇcité vzdálenosti, kde je potˇreba pˇrenést synchronizaˇcn´ı informaci. Poˇzadavky na ˇcasové charakteristiky jsou uvedeny v doporuˇcen´ıch G.813 [3] a G.8262 [8]

22

2.5


Porovn´ an´ı jednotliv´ ych protokol˚ u

Vˇsechny protokoly, kromˇe synchronn´ıho Ethernetu, jsou pouˇz´ıvány v prostˇred´ı internetu a jejich zprávy se pˇrenáˇsej´ı po paketov´ ych s´ıt´ıch. Hlavn´ım problémem paketov´ ych s´ıt´ı je promˇenné zpoˇzdˇen´ı, které je dáno architekturou paketové s´ıtˇe a nelze ho pˇredv´ıdat. Kaˇzdé zaˇr´ızen´ı, které je vloˇzeno do pˇrenosové cesty, pˇridává k celkovému zpoˇzdˇen´ı urˇcitou malou ˇca´st a jednotlivé protokoly se snaˇz´ı toto zpoˇzdˇen´ı zmˇeˇrit a korigovat. Protokol NTP je jeden z nejstarˇs´ıch protokol˚ u, kter´ y se stále vyv´ıj´ı a dokáˇze konkurovat i nov´ ym protokol˚ um. Jeho hlavn´ı v´ yhodou je dostupnost po celém internetu. Pˇresnost tohoto protokolu nen´ı pˇr´ıliˇs vysoká. Mnohem lépe je na tom PTP protokol podle standartu IEEE 1588, kter´ y poskytuje mnohem vˇetˇs´ı pˇresnost. Pˇresnost tohoto protokolu je udávaná v ˇra´du des´ıtek nanosekund pˇri hardwarové implementaci [28] a okolo jedné mikrosekundy pˇri softwarové implementaci [20]. PTP protokol ve své hardwarové verzi vyuˇz´ıvá ke své synchronizaci jednotlivá zaˇr´ızen´ı s podporou tohoto protokolu, a proto nen´ı zat´ıˇzen zpoˇzdˇen´ım jin´ ych s´ıt’ov´ ych prvk˚ u, které by se v s´ıti nemˇeli vyskytovat.

2.6

Mˇ eˇ ren´ı v re´ aln´ e s´ıti

Základem práce byla anal´ yza a mˇeˇren´ı zpoˇzdˇen´ı v paketové s´ıti a mˇeˇren´ı pˇresnosti jednotliv´ ych synchronizaˇcn´ıch protokol˚ u. Jednotlivá mˇeˇren´ı jsou uvedena v této ˇca´sti a umoˇznila z´ıskat pˇrehled o principech fungován´ı a moˇznostech dalˇs´ıho vylepˇsen´ı jednotliv´ ych protokol˚ u.

2.6.1

Zpoˇ zdˇ en´ı paketov´ e s´ıtˇ e

Paketová s´ıt’ byla navrˇzena pro pˇrenos paket˚ u a to sebou pˇrináˇs´ı jisté v´ yhody i nev´ yhody. V´ yhodou je rozdˇelen´ı zpráv, které mohou b´ yt poslány r˚ uzn´ ymi cestami a tud´ıˇz lepˇs´ı vyuˇzit´ı pˇrenosov´ ych prostˇredk˚ u, ale zároveˇ n to m˚ uˇze b´ yt i nev´ yhodou, coˇz je náˇs pˇr´ıpad. Nelze zaruˇcit, aby se paket ˇs´ıˇril pˇres paketovou s´ıt’ pˇredem urˇcenou cestou. Zpoˇzdˇen´ı paketu pˇri pr˚ uchodu s´ıt´ı se mˇen´ı vlivem zmˇeny zat´ıˇzen´ı jednotliv´ ych bod˚ u s´ıtˇe nebo aktuáln´ı zmˇenou topologie s´ıtˇe napˇr´ıklad pˇri v´ ypadku urˇcitého spojen´ı. Mˇeˇren´ı zpoˇzdˇen´ı s´ıtˇe bylo provádˇeno pomoc´ı protokolu NTP, kdy byl zjiˇst’ován ˇcas ˇ zpoˇzdˇen´ı mezi klientem a serverem. Mˇeˇren´ı bylo provádˇeno v Ethernet s´ıti CVUT, kde klient byl um´ıstˇen na Bubeneˇcské koleji v Praze a server byl um´ıstˇen na Strahovsk´ ych kolej´ıch v Praze. Jednalo se o veˇrejn´ y NTP server. Kaˇzdou sekundu byl vyslán dotaz na NTP server a bylo zjiˇstˇeno zpoˇzdˇen´ı tam a zpˇet, které bylo zaznamenáno. V´ ysledky jsou zobrazeny ve formˇe histogramu (obr. 2.10). Detailn´ı popis mˇeˇren´ı a zp˚ usoby vyhodnocen´ı jsou uvedeny v Diplomové práci [24]. Ze zm´ınˇeného histogramu je vidˇet typické rozloˇzen´ı zpoˇzdˇen´ı jednotliv´ ych paket˚ u [19], které odpov´ıdá logaritmicko-normáln´ımu rozloˇzen´ı [27][18]. Pˇri mˇeˇren´ı jsme schopni pˇresnˇe zmˇeˇrit obousmˇerné zpoˇzdˇen´ı. Z pohledu synchronizace je d˚ uleˇzitˇejˇs´ı jednosmˇerné zpoˇzdˇen´ı (napˇr. od serveru ke klientovi), které poté slouˇz´ı ke korekci lokáln´ıch hodin klientské strany. Algoritmus pˇredpokládá zpoˇzdˇen´ı v obou smˇerech

ˇ REN ˇ Í V REALN ´ E ´ SÍTI 2.6. ME

23

ˇ Obrázek 2.10: Cetnost zpoˇzdˇen´ı paket˚ u pˇri propojen´ı na NTP server stejné. Dalˇs´ı d˚ uleˇzit´ y vliv na pˇresnost synchronizace maj´ı jednotlivá koncová zaˇr´ızen´ı, která pˇridávaj´ı dalˇs´ı zpoˇzdˇen´ı dané délkou zpracován´ı jednotliv´ ych poˇzadavk˚ u. Je to dáno operaˇcn´ım systémem, kter´ y má vˇzdy nˇejakou frontu u ´loh a jednotlivé priority jednotliv´ ych proces˚ u. Rozd´ıl mezi okamˇzikem, kdy je ˇcasové raz´ıtko vloˇzeno do paketu a kdy je paket skuteˇcnˇe odeslán, je dáno zat´ıˇzen´ım systému a to m˚ uˇze zp˚ usobovat velkou variabilitu zpoˇzdˇen´ı. Ke stejnému problému m˚ uˇze docházet také na druhé stranˇe pˇri pˇr´ıjmu paketu. PTP protokol toto ˇreˇs´ı hardwarovou implementac´ı hodin popsanou v kapitole 2.3.1. Hodnota rozptylu jednotliv´ ych paket˚ u, která nejv´ıce ovlivˇ nuje pˇresnost synchronizace ˇ na stranˇe klienta, je nejd˚ uleˇzitˇejˇs´ım parametrem. C´ım menˇs´ı bude rozptyl zpoˇzdˇen´ı, t´ım vˇetˇs´ı bude pˇresnost synchronizace, protoˇze j moˇzné vypoˇc´ıtat pˇresnˇejˇs´ı ˇcas. Nejvyˇsˇs´ı hodnota ˇcetnosti zpoˇzdˇen´ı pˇri mˇeˇren´ı na reálné s´ıti (obr. 2.10) je okolo hodnoty zpoˇzdˇen´ı 7 ms. Velikost konstantn´ıho zpoˇzdˇen´ı nen´ı d˚ uleˇzitá, protoˇze ji m˚ uˇzeme z pˇrijat´ ych paket˚ u vypoˇc´ıtat a eliminovat (kapitola 2.2.1). Naˇs´ım u ´kolem je eliminovat ruˇsivé p˚ usoben´ı paket˚ u, které pˇricházej´ı s velk´ ym zpoˇzdˇen´ım a negativnˇe ovlivˇ nuj´ı pˇresnost synchronizace.

2.6.2

Mˇ eˇ ren´ı PTP

Precision Time Protocol (IEEE 1588) vyuˇz´ıvá hierarchickou topologii ve tvaru stromu, stejnˇe jako je vyuˇz´ıvána základn´ı topologie v Ethernet s´ıti. To znamená, ˇze v s´ıti je dostupn´ y jeden hlavn´ı synchronizaˇcn´ı server, kter´ y poskytuje pˇresn´ y ˇcas dalˇs´ım s´ıt’ov´ ym zaˇr´ızen´ım jako jsou pˇrep´ınaˇce a koncové s´ıt’ové karty v reˇzimu klienta. Jak bylo popsáno v kapitole 2.3, mechanismus pro v´ ybˇer nejpˇresnˇejˇs´ıch hodin a vytvoˇren´ı synchronizaˇcn´ı hierarchie je implementován pˇr´ımo v PTP. Pˇri mˇeˇren´ı pˇresnosti tohoto protokolu byl pouˇzit jeden synchronizaˇcn´ı server s GPS

24


pˇrij´ımaˇcem, jeden Ethernet pˇrep´ınaˇc a jeden poˇc´ıtaˇc se s´ıt’ovou kartou s podporou PTP. Dále byl pouˇzit jeden obyˇcejn´ y pˇrep´ınaˇc a rozboˇcovaˇc bez podpory PTP, kter´ y byl vloˇzen do synchronizaˇcn´ı cesty za u ´ˇcelem sledován´ı vlivu na zhorˇsen´ı pˇresnosti synchronizace. 2.6.2.1

Popis jednotliv´ ych zaˇ r´ızen´ı

Jako hlavn´ı synchronizaˇcn´ı server byl pouˇzit ˇcasov´ y server od firmy Meinberg s oznaˇcen´ım LANTIME (Local Area Network Timeserver) M600/GPS. Tento server poskytuje velice pˇresn´ y ˇcas pˇres Ethernet (TCP/IP) s´ıt’. Jedná se o modulárn´ı koncepci serveru, a proto m˚ uˇze b´ yt rozˇsiˇrován o dalˇs´ı moduly ˇci rozhran´ı. V naˇs´ı konfiguraci server obsahuje ˇctyˇri základn´ı 100Base-T Ethernetové rozhran´ı, které podporuj´ı NTP a SNTP protokol, jeden 100Base-T Ethernetové rozhran´ı s podporou PTP, nˇekolik v´ ystup˚ u vyveden´ ych na BNC konektory s r˚ uznou taktovac´ı frekvenc´ı, RS232 rozhran´ı a vstup na GPS anténu. Server poskytuje mnoho s´ıt’ov´ ych sluˇzeb pˇres Ethernet rozhran´ı jako je napˇr´ıklad NTP v2, v3 a v4 (ve vˇsesmˇerovém i v´ıcesmˇerovém reˇzimu), SNTP, FTP, HTTP a dalˇs´ı. Hlavn´ı funkci PTP protokolu u serveru pln´ı jednotka ˇcasového raz´ıtka, která je implementována na FPGA a stará se o kontrolu datov´ ych paket˚ u na u ´rovni rozhran´ı MII (Media Independent Interface), které je mezi fyzickou vrstvou (PHY) a pˇr´ıstupovou vrstvou (MAC) (Obr. 2.4). Jestliˇze je v pˇr´ıchoz´ıch zprávách detekován PTP paket, jednotka ˇcasového raz´ıtka si zaznamená pˇresn´ y ˇcas pˇr´ıchodu a pˇredá tuto informaci dále. Následnˇe je tento ˇcas pouˇzit k v´ ypoˇctu zpoˇzdˇen´ı pˇrenosové cesty a ke korekci m´ıstn´ıch hodin. V pˇr´ıpadˇe odchoz´ıho PTP paketu je urˇcen pˇresn´ y ˇcas odeslán´ı, kter´ y je následnˇe poslán v následuj´ıc´ı zprávˇe (obr. 2.5). Tato zpráva je v angliˇctinˇe naz´ yvána jako follow up zpráva. Pˇresn´ y ˇcas hodin je urˇcován z GPS modulu a pomoc´ı fázového závˇesu je udrˇzován i pˇri v´ ypadku. Cel´ y proces je popsán na obrázku 2.11.

Obrázek 2.11: Blokové schéma synchronizaˇcn´ı karty PTP serveru [9] Nejd˚ uleˇzitˇejˇs´ım obvodem synchronizaˇcn´ıho serveru je intern´ı oscilátor a jeho stabilita taktu. PTP server je osazen velice stabiln´ım oscilátorem typu OCXO LQ, kter´ y má krátkodobou stabilitu okolo 1 · 10−9 a dlouhodobou stabilitu pˇribliˇznˇe 4 · 10−7 v reˇzimu


25

volného bˇehu bez synchronizace (free-running mode). D´ıky GPS modulu, kter´ y poskytuje velice pˇresn´ y ˇcas, je v´ ysledná pˇresnost synchronizace pˇri spolupráci s intern´ım oscilátorem −11 okolo hodnoty 1 · 10 . Vˇsechny tyto charakteristiky jsou teplotnˇe závislé a lze je nalézt v dokumentaci k PTP serveru [9]. Konfiguraci serveru je moˇzné provádˇet pomoc´ı konzole pˇripojené pˇres RS232 port nebo pomoc´ı Telnetu. Lze také vyuˇz´ıt jednoduch´ ych www stránek dostupn´ ych pˇres libovoln´ y webov´ y prohl´ıˇzeˇc. Dalˇs´ı komponentou pouˇzitou pˇri mˇeˇren´ı byl pr˚ umyslov´ y pˇrep´ınaˇc od firmy Hirschmann s podporou PTP (IEEE 1588). D´ıky modulárnosti tohoto pˇrep´ınaˇce je moˇzné pˇridávat dalˇs´ı porty a rozˇs´ıˇren´ı, nicménˇe postaˇcuje základn´ı konfigurace se 4 Ethernetov´ ymi porty, USB konektorem a s rozhran´ım V.24 pro správu pˇrep´ınaˇce. Konfigurace pˇrep´ınaˇce je samozˇrejmˇe moˇzná v´ıce zp˚ usoby. Posledn´ı komponentou s podporou PTP je s´ıt’ová karta PTP270PEX od firmy Meinberg. Tato karta vyuˇz´ıvá standardn´ı sbˇernice PCI-E (Express). S´ıt’ová karta pracuje typicky v reˇzimu klient, kdy synchronizuje sv˚ uj ˇcas na základˇe pˇr´ıchoz´ıch paket˚ u. S´ıt’ová karta také obsahuje jednotku ˇcasového raz´ıtka, která je implementována v obvodu FPGA a která pracuje podobnˇe jako u synchronizaˇcn´ıho serveru uvedeného na obrázku 2.11. S´ıt’ová karta má také nˇekolik v´ ystup˚ u s r˚ uzn´ ym taktem napˇr´ıklad 10MHz nebo PPS (kaˇzdou sekundu jeden puls). Tyto v´ ystupy budou pouˇzity pˇri mˇeˇren´ı, abychom z´ıskali odchylku ˇcasu serveru a klienta a t´ım pádem zjistili vliv jednotliv´ ych zaˇr´ızen´ı na pˇresnost synchronizace. Dále byl pouˇzit jeˇstˇe jeden standardn´ı rozboˇcovaˇc a pˇrep´ınaˇc. Pˇri mˇeˇren´ı byl zjiˇst’ován vliv tˇechto zaˇr´ızen´ı (bez podpory PTP) na pˇresnost v´ ysledné synchronizace. 2.6.2.2

S´ıt’ov´ e topologie a v´ ysledky mˇ eˇ ren´ı

V pˇredchoz´ı podkapitole byla popsána jednotlivá zaˇr´ızen´ı, která budou vyuˇz´ıvána pˇri mˇeˇren´ı. V kaˇzdé mˇeˇrené topologii mus´ı b´ yt obsaˇzen minimálnˇe PTP server a poˇc´ıtaˇc se ’ s´ıt ovou kartou, která podporuje PTP protokol. Tedy nejjednoduˇsˇs´ı topologi´ı je pˇr´ımé propojen´ı serveru a klienta (Obrázek 2.12).

Obrázek 2.12: Pˇr´ımé propojen´ı serveru a klienta Mˇeˇren´ı je následnˇe provádˇeno porovnán´ım nábˇeˇzn´ ych hran sekundov´ ych pulz˚ u (PPS Pulse per Second) ze serveru a klienta pomoc´ı osciloskopu. V pˇr´ıpadˇe, ˇze je ˇcas klienta a


26

serveru pˇresnˇe synchronizován, nen´ı namˇeˇren ˇza´dn´ y rozd´ıl mezi PPS od serveru a klienta. Tedy kaˇzdou sekundu je z´ıskána jedna hodnota, která vyjadˇruje rozd´ıl ˇcasu klienta od ˇcasu serveru. Tyto hodnoty jsou zaznamenány a zobrazeny ve formˇe grafu (obr. 2.14) a statistick´ ych hodnot (tabulka 2.1).

Obrázek 2.13: S´ıt’ová topologie se serverem, PTP pˇrep´ınaˇcem a klientem Velice podobn´ ych v´ ysledk˚ u se dosáhlo i v topologii, kdy byl mezi serverem a s´ıt’ovou kartou pˇripojen jeˇstˇe pˇrep´ınaˇc s podporou PTP od firmy Hirschmann. Topologie mˇeˇren´ı je zobrazena na obrázku 2.13. −8

x 10

pˇr´ıme´ propojen´ı pˇres PTP pˇrep´ınaˇc

3 2 1

∆t [s]

0 −1 −2 −3 −4 −5 0

50

100

150

200

250

300

t [s]

Obrázek 2.14: V´ ysledky mˇeˇren´ı pˇri pˇr´ımém propojen´ı a s PTP pˇrep´ınaˇcem Obrázek 2.14 zobrazuje jednotlivé odchylky ˇcasu serveru a ˇcasu klienta (s´ıt’ová karta v poˇc´ıtaˇci). Graf zobrazuje v´ ysledky mˇeˇren´ı na obou topologi´ıch zm´ınˇen´ ych v´ yˇse. V grafu


27

je pro pˇrehlednost zobrazeno jenom 300 hodnot, nicménˇe pˇri kaˇzdém mˇeˇren´ı bylo z´ıskáno v´ıce neˇz 1000 hodnot. Stˇredn´ı hodnota rozd´ılu ˇcasu serveru a klienta pˇri pˇr´ımém propojen´ı byla okolo 15 nanosekund. Nejvˇetˇs´ı zaznamenan´ y rozd´ıl byl 54 ns. Topologie se serverem, PTP pˇrep´ınaˇcem a PC mˇela stˇredn´ı hodnotu nepˇresnosti synchronizace 19,8 ns a nejvˇetˇs´ı zaznamenan´ y rozd´ıl ˇcas˚ u byl 58 ns. Tyto v´ ysledky opravdu potvrzuj´ı tvrzen´ı, ˇze pˇresnost synchronizace s hardwarovou implementac´ı je v ˇra´du des´ıtek maximálnˇe stovek nanosekund.

Obrázek 2.15: Topologie pro mˇeˇren´ı standardn´ıho pˇrep´ınaˇce a rozboˇcovaˇce Dále byl mˇeˇren vliv standardn´ıho pˇrep´ınaˇce a rozboˇcovaˇce na v´ yslednou pˇresnost synchronizace. Topologie je uvedena na obrázku 2.15. V´ ysledná pˇresnost synchronizace se zhorˇsila pˇribliˇznˇe desetkrát. −7

x 10 8

pˇrep´ınaˇc opakovaˇc

6 4

∆t [s]

2 0 −2 −4 −6 0

50

100

150 t [s]

200

250

300

Obrázek 2.16: V´ ysledky mˇeˇren´ı pˇri pouˇzit´ı standardn´ıho pˇrep´ınaˇce a rozboˇcovaˇce

28


V´ ysledná odchylka synchronizace ˇcasu je u pˇrep´ınaˇce a rozboˇcovaˇce velice podobná. Pˇri synchronizaci se hodnoty odchylek pohybovaly v kladn´ ych i záporn´ ych ˇc´ıslech a v´ ysledná stˇredn´ı hodnota pˇri mˇeˇren´ı s rozboˇcovaˇcem je 33 ns a s pˇrep´ınaˇcem je 106 ns. Maximáln´ı namˇeˇrená odchylka byla v pˇr´ıpadˇe rozboˇcovaˇce 787 ns a v pˇr´ıpadˇe pˇrep´ınaˇce 820 ns (Obrázek 2.16). Lze tedy ˇr´ıci, ˇze rozboˇcovaˇc je dosahuje lepˇs´ıch v´ ysledk˚ u neˇz pˇrep´ınaˇc. Pravdˇepodobnˇe to bude zp˚ usobeno funkc´ı jednotliv´ ych zaˇr´ızen´ı, kdy rozboˇcovaˇc okamˇzitˇe pos´ılá vˇsechny pakety vˇsemi smˇery, zat´ımco pˇrep´ınaˇc rozhoduje jak´ ym smˇerem se má dan´ y paket poslat, coˇz pˇrináˇs´ı vˇetˇs´ı zat´ıˇzen´ı a zpoˇzdˇen´ı jednotliv´ ych paket˚ u. Vˇetˇsina standardn´ıch pˇrep´ınaˇc˚ u vyuˇz´ıvá metody uloˇz a poˇsli (store and forward) nebo i jiné metody, které mohou pˇridávat dalˇs´ı variabiln´ı zpoˇzdˇen´ı do pˇrenosové cesty. Pˇri dalˇs´ıch mˇeˇren´ıch byl zkoumán vliv zat´ıˇzen´ı s´ıtˇe datov´ ymi pˇrenosy na v´ yslednou pˇresnost synchronizace ˇcasu. Byla vytvoˇrena topologie, kde bylo zapojeno v´ıce poˇc´ıtaˇc˚ u pˇres jeden pˇrep´ınaˇc ˇci opakovaˇc a mezi tˇemito poˇc´ıtaˇci byly pˇrenáˇseny velké soubory. Jelikoˇz náˇs rozboˇcovaˇc mˇel jenom pˇet port˚ u, vyuˇzili jsme jeˇstˇe jeden pˇrep´ınaˇc, abychom mohli vytvoˇrit dvˇe nezávislé cesty pro pˇrenos soubor˚ u. Rychlost rozboˇcovaˇce je 10 Mbit/s zat´ımco pˇrep´ınaˇc podporuje rychlost 100 Mbit/s. Topologie pro tento pˇr´ıpad je zobrazena na obrázku 2.17.

Obrázek 2.17: Topologie pro mˇeˇren´ı rozboˇcovaˇce se zat´ıˇzen´ım Rozboˇcovaˇc byl v tomto mˇeˇren´ı opravdu nejslabˇs´ım ˇclánkem. Z obrázku 2.18 je názornˇe vidˇet velk´ y rozd´ıl ˇcasu serveru a klienta, ke kterému doˇslo pˇri v´ ypadku synchronizace.


29

V´ ypadek synchronizace byl nejsp´ıˇse zp˚ usoben ztrátou synchronizaˇcn´ıch paket˚ u. V pˇr´ıpadˇe velkého zat´ıˇzen´ı docház´ı na rozboˇcovaˇci k mnoha koliz´ım, které negativnˇe ovlivn´ı pˇresnost synchronizace. V pr˚ ubˇehu mˇeˇren´ı byl rozpad synchronizace zaznamenán a byl zastaven datov´ y tok mezi PC. Po chvilce byla synchronizace znovu navázána, a tak jsem znovu obnovil pˇrenos dat. Situace s rozpadem synchronizace se opakovala (obrázek 2.18). −6

x 10

standardn´ı rozboˇcovaˇc bez zat´ızˇ en´ı standardn´ı rozboˇcovaˇc se zat´ızˇ en´ım

6 5 4

∆t [s]

3 2 1 0 −1 −2 −3 0

100

200

300

400

500

600

700

t [s]

Obrázek 2.18: V´ ysledky mˇeˇren´ı pˇri pouˇzit´ı rozboˇcovaˇce se zat´ıˇzen´ım a bez zat´ıˇzen´ı Pˇri pouˇzit´ı Hirschmann pˇrep´ınaˇce s podporou PTP byla v´ ysledná pˇresnost synchronizace se zat´ıˇzen´ım a bez zat´ıˇzen´ı velice podobná. Principy PTP protokolu, které byly popsány v pˇredeˇsl´ ych kapitolách, zaruˇcuj´ı urˇcitou pˇresnost synchronizace, coˇz se t´ımto mˇeˇren´ım ovˇeˇrilo. V´ ysledná pˇresnost synchronizace se tedy stále pohybuje pod hranic´ı 100 ns (Tabulka 2.1). Standardn´ı pˇrep´ınaˇc má horˇs´ı pˇresnost synchronizace pˇri zat´ıˇzen´ı datov´ ym tokem, nicménˇe tento vliv nen´ı nˇejak v´ yrazn´ y (Obrázek 2.20). Pˇri zat´ıˇzen´ı byla stˇredn´ı hodnota 238 ns a nejvˇetˇs´ı odchylka ˇcas˚ u serveru a klienta byla 1,21 µs. V pˇr´ıpadˇe, ˇze porovnáme pˇresnost synchronizace standardn´ıho pˇrep´ınaˇce a pˇrep´ınaˇce s podporou PTP pˇri zat´ıˇzen´ı tˇechto pˇrep´ınaˇc˚ u, zjist´ıme vˇetˇs´ı rozd´ıl (pˇribliˇznˇe 10 krát obrázek 2.21)

30


Obrázek 2.19: Topologie pro mˇeˇren´ı pˇrep´ınaˇce se zat´ıˇzen´ım Byly provedeny dalˇs´ı zkuˇsebn´ı mˇeˇren´ı s pozmˇenˇen´ ymi topologiemi a s jin´ ymi standardn´ımi zaˇr´ızen´ımi, ale v´ ysledky byli velice podobné mˇeˇrenému pˇrep´ınaˇci a rozboˇcovaˇci. Vˇsechny v´ ysledky jsou pˇrehlednˇe zapsány v tabulce 2.1. Tabulka pro jednotlivé topologie zobrazuje stˇredn´ı hodnotu, smˇerodatnou odchylku, hodnotu rozptylu a maximáln´ı hodnoty. V pˇr´ıpadˇe mˇeˇren´ı topologie, kde mˇela vˇsechna zaˇr´ızen´ı podporu PTP, byly v´ ysledky v ˇra´dech nanosekund. Odchylka synchronizace ˇcasu serveru a klienta nepˇrekroˇcila hodnotu 100 ns a pr˚ umˇerné hodnoty se pohybovali v ˇra´du des´ıtek nanosekund. V pˇr´ıpadˇe pouˇzit´ı standardn´ıch s´ıt’ov´ ych prvk˚ u (v tabulce topologie Server - Hub - PC nebo Server - Switch - PC)) jsou hodnoty rozptylu a maximáln´ı hodnoty v´ yraznˇe vyˇsˇs´ı, coˇz vypov´ıdá o horˇs´ı pˇresnosti synchronizace. V pˇr´ıpadˇe zat´ıˇzen´ı jednotliv´ ych datov´ ych prvk˚ u v s´ıti datov´ ym provozem, docház´ı u prvk˚ u bez podpory PTP protokolu k dalˇs´ımu zhorˇsen´ı pˇresnosti synchronizace, coˇz je v tabulce nejv´ıce vidˇet u topologie Server - Hub - PC (se zat´ıˇzen´ım).


31

−7

x 10 12

standardn´ı pˇrep´ınaˇc bez zat´ızˇ en´ı standardn´ı pˇrep´ınaˇc se zat´ızˇ en´ım

10 8 6

∆t [s]

4 2 0 −2 −4 −6 −8 0

50

100

150 t [s]

200

250

300

Obrázek 2.20: V´ ysledky mˇeˇren´ı standardn´ıho pˇrep´ınaˇce se zat´ıˇzen´ım a bez zat´ıˇzen´ı

−7

x 10 12

Hirschmann PTP pˇrep´ınaˇc pˇri zat´ızˇ en´ı pˇrenosem dat standardn´ı pˇrep´ınaˇc pˇri zat´ızˇ en´ı pˇrenosem dat

10 8 6

∆t [s]

4 2 0 −2 −4 −6 −8 0

50

100

150 t [s]

200

250

300

Obrázek 2.21: V´ ysledky mˇeˇren´ı stand. pˇrep´ınaˇce a Hirschmann pˇrep´ınaˇce se zat´ıˇzen´ım


32

Topologie Server – PC (obr. 2.12) Server – PTP switch – PC (obr. 2.13) Server – Hub – PC (obr. 2.15) Server – Switch – PC (obr. 2.15) Server – PTP switch – PC (se zat´ıˇzen´ım) (obr. 2.19) Server – Hub – PC (se zat´ıˇzen´ım) (obr. 2.17) Server – Switch – PC (se zat´ıˇzen´ım) (obr. 2.19) Server – PTP switch – switch – PC (zat´ıˇzen´ım)

Stˇredn´ı hodnota [s] -1,48e-8 -1,96e-8

Rozptyl

Min [s]

Max [s]

1,7e-16 2,2e-16

Smˇerodatná odchylka [s] 1,29e-8 1,49e-8

-5,4e-8 -5,8e-8

3,0e-8 3,75e-8

3,37e-8

5,5e-14

23,5e-8

-67,4e-8

78,7e-8

10,6e-8

5,7e-14

23,9e-8

-72,4e-8

82e-8

-2,02e-8

2,7e-16

1,66e-8

-7,1e-8

3,2e-8

24,91e-8

4,9e-12

222e-8

-338e-8

499e-8

23,85e-8

5,5e-14

23,6e-8

-79,5e-8

121e-8

12,6e-8

3,6e-14

18e-8

-46e-8

-86e-8

Tabulka 2.1: V´ ysledky mˇeˇren´ı pro r˚ uzné topologie pˇri r˚ uzn´ ych podm´ınkách

ˇ ´ 2.7. ZHODNOCENÍ SOUCASN EHO STAVU

2.7

33

Zhodnocen´ı souˇ casn´ eho stavu

Synchronizace ˇcasu pomoc´ı paketov´ ych s´ıt´ı je stále velice diskutovan´ ym problémem. Princip ˇcasové synchronizace byl poprvé vymyˇslen a pouˇzit pˇred v´ıce neˇz 20 roky u NTP protokolu. Mnoho zaˇr´ızen´ı vyˇzaduje stále vˇetˇs´ı pˇresnost synchronizace ˇcasu, která ovlivˇ nuje generován´ı taktu jak pro vnitˇrn´ı obvody zaˇr´ızen´ı, tak i jako extern´ı zdroj pro dalˇs´ı zaˇr´ızen´ı, a proto jsou synchronizaˇcn´ı protokoly stále vylepˇsovány. PTP protokol (standard IEEE1588) je nyn´ı nejpˇresnˇejˇs´ım protokolem pro synchronizaci ˇcasu v lokáln´ıch s´ıt´ıch. Jeho nev´ yhodou je nutnost pouˇzit´ı jednotliv´ ych zaˇr´ızen´ı s podporou tohoto protokolu, coˇz vyˇzaduje finanˇcn´ı investice. Pˇresnost PTP protokolu je v ˇra´du des´ıtek nanosekund. Dalˇs´ım protokolem, kter´ y se dnes hojnˇe vyuˇz´ıvá k synchronizaci ˇcasu v poˇc´ıtaˇc´ıch, je protokol NTP. Pˇresnost NTP protokolu je v ˇra´du jednotek milisekund. Pˇresnost ˇcasové synchronizace závis´ı na mnoha faktorech, které byly popsány v pˇredeˇsl´ ych kapitolách. Hlavn´ımi faktory jsou rozptyl zpoˇzdˇen´ı v jednotliv´ ych smˇerech pˇri pˇrenosu paket˚ u a pˇresné urˇcen´ı ˇcasu pˇr´ıchodu a odchodu paketu. D´ıky jednotliv´ ym mˇeˇren´ım a prostudovan´ ym ˇclánk˚ um [20], [17], [23], [28], [15] byly zjiˇstˇeny jednotlivé parametry, které nejv´ıce ovlivˇ nuj´ı v´ yslednou pˇresnost. Následuj´ıc´ı práce se zamˇeˇr´ı na moˇznosti vylepˇsen´ı synchronizaˇcn´ıho algoritmu. Nab´ız´ı se nˇekolik r˚ uzn´ ych moˇznost´ı, které budou analyzovány a pomoc´ı simulac´ı ovˇeˇreny.

34


Kapitola 3 C´ıle disertaˇ cn´ı pr´ ace C´ılem disertaˇcn´ı práce je vytvoˇrit algoritmus, kter´ y pomoc´ı synchronizaˇcn´ıho protokolu umoˇzn´ı zv´ yˇsit pˇresnost synchronizace ˇcasu na stranˇe klienta, coˇz umoˇzn´ı i pˇresnˇejˇs´ı gene´ rován´ı ˇr´ıd´ıc´ıho taktu pro samotné ˇci dalˇs´ı zaˇr´ızen´ı. Ukolem synchronizace ˇcasu je nastavit ˇ ˇcas klienta tak, aby byl totoˇzn´ y s ˇcasem serveru. Cas serveru je povaˇzován za referenˇcn´ı a je ˇr´ızen z pˇresného ˇcasového zdroje. Z obecného principu synchronizace (kap. 2.2.1), kdy docház´ı k v´ ymˇenˇe ˇcasov´ ych znaˇcek mezi serverem a klientem, jsme schopni velice pˇresnˇe vypoˇc´ıtat celkové zpoˇzdˇen´ı pr˚ uchodu paketu tam i zpˇet (zpoˇzdˇen´ı ve smyˇcce, RTT). Nicménˇe pro pˇresnou synchronizaci je d˚ uleˇzité stanovit zpoˇzdˇen´ı jednom smˇeru, coˇz nelze v praxi pˇresnˇe urˇcit. Vˇetˇsinou se pˇredpokládá, ˇze zpoˇzdˇen´ı jedn´ım smˇerem je stejné jako druh´ ym, a proto se zpoˇzdˇen´ı ve smyˇcce vydˇel´ı dvˇema. Kol´ısán´ı zpoˇzdˇen´ı je jedn´ım z nejd˚ uleˇzitˇejˇs´ıch parametr˚ u negativnˇe ovlivˇ nuj´ıc´ı synchronizaci. Pro vlastn´ı ˇreˇsen´ı disertaˇcn´ı práce jsem si stanovil následuj´ıc´ı c´ıle: 1. Anal´ yza a mˇeˇren´ı vlivu velikosti zpoˇzdˇen´ı s´ıtˇe na pˇresnost synchronizace. • R˚ uzné zat´ıˇzen´ı pˇrenosov´ ych cest zp˚ usobuje, ˇze variabiln´ı sloˇzka zpoˇzdˇen´ı se v jednotliv´ ych smˇerech liˇs´ı. • V pˇr´ıpadˇe hardwarové implementace PTP protokolu, kdy kaˇzdé s´ıt’ové zaˇr´ızen´ı má vlastn´ı hodiny a synchronizuj´ı se navzájem, je kol´ısán´ı zpoˇzdˇen´ı zanedbatelné. Ale i tak se sˇc´ıtaj´ı nepˇresnosti jednotliv´ ych synchronizovan´ ych s´ıt’ov´ ych zaˇr´ızen´ıch, které se nacházej´ı mezi hlavn´ım PTP serverem a koncov´ ym klientem. 2. Sestaven´ı modelu a vytvoˇren´ı simulaˇcn´ıho programu, kter´ y bude provádˇet synchronizaci ˇcasu klienta a reflektovat aktuáln´ı stav a funkci synchronizaˇcn´ıho algoritmu. • Simulaˇcn´ı program bude pouˇzit k porovnán´ı simulovan´ ych a namˇeˇren´ ych hodnot pˇri reálném mˇeˇren´ı. T´ım dojde k ovˇeˇren´ı modelu a správné funkˇcnosti programu. Vstupn´ımi parametry budou hodnoty pro nastaven´ı simulované s´ıtˇe jako je minimáln´ı a maximáln´ı zpoˇzdˇen´ı paket˚ u a rozptyl jednotliv´ ych hodnot zpoˇzdˇen´ı paket˚ u. 35

36

ˇ Í PRACE ´ KAPITOLA 3. CÍLE DISERTACN 3. Sn´ıˇzen´ı vlivu kol´ısán´ı zpoˇzdˇen´ı na pˇresnost synchronizace a zv´ yˇsen´ı pˇresnosti synchronizace ˇcasu a generován´ı taktu klienta. • Eliminaci vlivu je nutné provádˇet na stranˇe klienta a jako nejjednoduˇsˇs´ı algoritmus lze pouˇz´ıt napˇr´ıklad pr˚ umˇerován´ı jednotliv´ ych v´ ysledk˚ u korekc´ı ˇcasu zjiˇstˇen´ ych pˇri synchronizaci ˇcasu. 4. Sestaven´ı modelu a vytvoˇren´ı simulaˇcn´ıho programu s vylepˇsenou synchronizac´ı, kter´ y bude provádˇet synchronizaci ˇcasu klienta a bude obsahovat vylepˇsen´ı a rozˇs´ıˇren´ı synchronizaˇcn´ıho algoritmu. • Simulaˇcn´ı program bude obsahovat nové algoritmy a vylepˇsen´ı, které pˇrinesou vyˇsˇs´ı pˇresnost synchronizace ˇcasu a generován´ı taktu na stranˇe klienta. • Jednou z moˇznost´ı je implementace sofistikovan´ ych pr˚ umˇerovac´ıch ˇci filtraˇcn´ıch algoritm˚ u, které budou eliminovat kol´ısán´ı zpoˇzdˇen´ı. • Dalˇs´ı moˇznost´ı je pˇridán´ı druhého generátoru hodin na stranu klienta, kter´ y nebude pˇr´ımo ˇr´ızen z ˇcasov´ ych korekc´ı vypoˇc´ıtan´ ych po pˇr´ıchodu synchronizaˇcn´ıch paket˚ u, ale bude ˇr´ızen fázovou smyˇckou. Fázová smyˇcka by mohla porovnávat rozd´ıl mezi ˇcasem obou vnitˇrn´ıch hodin a jemnˇe by korigovala v´ ysledn´ y ˇcas na druh´ ych hodinách. Vyuˇzit´ı dvou hodin by mˇelo pˇrinést vyˇsˇs´ı stabilitu ˇcasu klienta. • Dalˇs´ım zp˚ usobem zv´ yˇsen´ı pˇresnosti synchronizace je pˇr´ımé dolad’ován´ı oscilátoru, kter´ y ˇr´ıd´ı ˇcas klienta a generuje takt. U vˇetˇsiny zaˇr´ızen´ı docház´ı ke zpomalován´ı ˇci ke zrychlován´ı bˇehu ˇcasu klienta a moˇznost jemného dolad’ován´ı oscilátoru pˇrináˇs´ı vysokou pˇresnost zejména z pohledu dlouhodobé stability ˇcasu a generován´ı taktu. C´ılem je vyuˇzit´ı paketové s´ıtˇe pro synchronizaci s následnou moˇznost´ı odvozen´ı taktu pro ostatn´ı zaˇr´ızen´ı.

Kapitola 4 N´ avrh a simulace synchronizaˇ cn´ıho algoritmu Principy a funkce synchronizaˇcn´ıch protokol˚ u byly vysvˇetleny v pˇredchoz´ıch kapitolách. Tato kapitola se vˇenuje simulaci synchronizaˇcn´ıho algoritmu tak, jak ho vyuˇz´ıvaj´ı jednotlivé synchronizaˇcn´ı protokoly. Jedná se o v´ ymˇenu ˇcasov´ ych zpráv a z´ıskán´ı ˇctyˇrech ˇcasov´ ych znaˇcek, ze kter´ ych urˇc´ıme v´ yslednou korekci ˇcasu hodin klienta. Tento postup je popsán pro NTP protokol na obrázku 2.2 a pro PTP na obrázku 2.6 a je velice podobn´ y. Jak bylo uvedeno, zásadn´ı vliv na pˇresnost synchronizace ˇcasu a generován´ı taktu má rozd´ılné zpoˇzdˇen´ı v r˚ uzn´ ych smˇerech pˇrenosu dat po paketové s´ıti a promˇenlivost tohoto zpoˇzdˇen´ı.

4.1

Model synchronizaˇ cn´ıch obvod˚ u - aktu´ aln´ı stav

´ Ukolem prvn´ı ˇca´sti je vytvoˇren´ı simulaˇcn´ıho programu, kter´ y bude odpov´ıdat reálnému chován´ı synchronizaˇcn´ıch protokol˚ u v s´ıti. Vstupn´ı parametry, které budeme zadávat, budou ovlivˇ novat jednotlivé vlastnosti Ethernet s´ıtˇe. Pˇres tuto s´ıt’ bude prob´ıhat komunikace meze klientem a serverem. Základn´ı blokové schéma, které zobrazuje strukturu serveru a klienta je zobrazen na obrázku 4.1. Strana serveru (hlavn´ıho poskytovatele ˇcasu) je pomˇernˇe jednoduchá. At’ uˇz se jedná o NTP server nebo PTP server, základem je pˇresn´ y ˇcas, kter´ y mus´ı splˇ novat urˇcitou pˇresnost a stabilitu. Tento ˇcas je pˇredáván do jednotky Zpracován´ı ˇcasov´ ych znaˇcek“, která se stará ” o komunikaci s klienty a poskytuje jim pˇresn´ y ˇcas. Pˇrenos paket˚ u prob´ıhá pˇres paketovou ’ ’ s´ıt . Dnes je nejv´ıce rozˇs´ıˇrena s´ıt Ethernet. Zde m˚ uˇze b´ yt zastoupen r˚ uzn´ y poˇcet zaˇr´ızen´ı, coˇz záleˇz´ı na vzdálenosti mezi serverem a klientem. U PTP se pˇredpokládá vzdálenost mnohem menˇs´ı s adekvátn´ım hardwarov´ ym vybaven´ım, aby bylo moˇzné vyuˇz´ıt vyˇsˇs´ı pˇresnosti synchronizace popsané v kapitole 2.6.2. V pˇr´ıpadˇe klienta je situace sloˇzitˇejˇs´ı, protoˇze na stranˇe klienta mus´ı b´ yt provádˇeno vyhodnocen´ı, zda vypoˇctená korekce ˇcasu je správná a o kolik se má upravit ˇcas klienta. Hlavnˇe u NTP protokolu jsou implementovány r˚ uzné zpˇresˇ nuj´ıc´ı algoritmy a korekce ˇcasu nen´ı provádˇena ihned po v´ ypoˇctu prvn´ı korekce. Vˇetˇsinou je vypoˇc´ıtáno nˇekolik korekc´ı 37

38

´ ˇ ÍHO ALGORITMU KAPITOLA 4. NAVRH A SIMULACE SYNCHRONIZACN

Obrázek 4.1: Blokové schéma synchronizace ˇcasu ˇcasu, které se urˇcit´ ym zp˚ usobem pr˚ umˇeruj´ı, aby byla urˇcena jedna pˇresnˇejˇs´ı korekce ˇcasu klienta. Po kaˇzdém pˇr´ıjmu synchronizaˇcn´ıho paketu je vypoˇc´ıtán ˇcasov´ y rozd´ıl klienta a serveru podle vzorce 2.4 a tento v´ ysledek je dále zpracováván vyhodnocovac´ım algoritmem, kter´ y urˇc´ı v´ yslednou korekci hodin klienta. Dále klient obsahuje uˇz jen hodiny, které jsou ˇr´ızeny lokáln´ım oscilátorem. Pˇresnost a stabilita lokáln´ıho oscilátoru je mnohem menˇs´ı neˇz u synchronizaˇcn´ıch server˚ u, a proto m˚ uˇze docházet ke zpoˇzd’ován´ı ˇci ke zrychlován´ı ˇcasu klienta. Vyhodnocovac´ı algoritmus m˚ uˇze fungovat r˚ uzn´ ymi zp˚ usoby, a proto se mu budeme vˇenovat v následuj´ıc´ı podkapitole podrobnˇeji.

4.1.1

Vyhodnocovac´ı algoritmus klienta

Pˇri vyhodnocen´ı jednotliv´ ych ˇcasov´ ych rozd´ıl˚ u serveru a klienta a urˇcen´ı v´ ysledné korekce klienta je nutné urˇcit pr˚ umˇernou hodnotu, která se mus´ı co nejv´ıce bl´ıˇzit pˇresné korekci hodin. Jako prvn´ı vyhodnocovac´ı algoritmus se nab´ız´ı obyˇcejná pr˚ umˇerná hodnota z nˇekolika pˇrijat´ ych ˇcasov´ ych rozd´ıl˚ u. Zde m˚ uˇze b´ yt problém s t´ım, ˇze budeme ˇcekat neˇz z´ıskáme potˇrebn´ y poˇcet hodnot. Jako v´ yhodnˇejˇs´ı algoritmus se jev´ı vyuˇzit´ı filtr˚ u. Existuj´ı r˚ uzné druhy filtr˚ u a kaˇzd´ y filtr m˚ uˇze m´ıt jin´ y ˇra´d. Jako základn´ı filtr byl pouˇzit FIR filtr (Finite Impulse Response) s ˇra´dem 10. Amplitudová charakteristika filtru je zobrazena na obrázku 4.2. Jako vstupn´ı hodnoty pro filtr jsou pouˇzity ˇcasové korekce K1 vypoˇc´ıtané z pˇrijat´ ych paket˚ u.

ˇ ÍCH OBVODU ˚ - AKTUALN ´ Í STAV 4.1. MODEL SYNCHRONIZACN

39

V´ ychoz´ı parametry algoritmu pro vyhodnocován´ı ˇcasové korekce byly stanoveny experimentálnˇe. Pˇri návrhu jsem zvolil doln´ı propust s mezn´ım kmitoˇctem propustného pásma 0,03 Hz a vzorkovac´ım kmitoˇctem 1 Hz. Po pr˚ uchodu hodnot filtrem jsou v´ ysledné hodnoty jeˇstˇe vydˇeleny ˇc´ıslem 5, aby velikost u ´pravy lokáln´ıch hodin byla pozvolná a aby nedoˇslo k rozkmitán´ı celého systému. Hodnota 5 byla zvolena s ohledem na dostateˇcnou rychlost u ´pravy ˇcasu lokáln´ıch hodin klienta, ale zároveˇ n i pˇresnost ˇcasu. Pokud zvol´ıme vyˇsˇs´ı hodnotu (napˇr. 10) budou v´ ysledné hodnoty korekc´ı K2 po vydˇelen´ı menˇs´ı a u ´prava ˇcasu hodin bude pozvolnˇejˇs´ı. V pˇr´ıpadˇe malé hodnoty máme naopak rychl´ y systém, kter´ y se v pˇr´ıpadˇe zmˇeny dokáˇze rychle pˇrizp˚ usobit, ale tento systém je mnohem náchylnˇejˇs´ı na promˇenlivé zpoˇzdˇen´ı v s´ıti a m˚ uˇze doj´ıt i k nestabilitˇe systému. Volba parametru je závislá na poˇzadavc´ıch na systém a vˇetˇsinou se vol´ı kompromis mezi rychlost´ı a pˇresnost´ı systému. Magnitude Response (dB) 0

−10

Magnitude (dB)

−20

−30

−40

−50

−60

−70 0

0.1

0.2

0.3

0.4 0.5 0.6 Normalized Frequency (×π rad/sample)

0.7

0.8

0.9

Obrázek 4.2: Fitr FIR s ˇra´dem 10 Bylo provedeno nˇekolik simulac´ı s r˚ uzn´ ymi vstupn´ımi podm´ınkami. Vstupn´ı veliˇciny definuj´ı chován´ı Ethernetu. Pˇri kaˇzdé simulaci nastavujeme stˇredn´ı hodnotu zpoˇzdˇen´ı paketu v s´ıti a dále k této hodnotˇe pˇriˇc´ıtáme urˇcit´ y rozptyl. Byla provedena simulace a následnˇe i mˇeˇren´ı s emulátorem s´ıtˇe pro stˇredn´ı hodnotu zpoˇzdˇen´ı 3 ms a 10 ms a s rozptylem 1, 2 a 3 ms. Jako pˇr´ıklad zde uvedu odsimulované hodnoty pˇri nastaven´ı stˇredn´ı hodnoty zpoˇzdˇen´ı s´ıtˇe 3 ms a rozptylu hodnot do maximáln´ı velikosti ± 1 ms. Obrázek 4.3 zobrazuje korekce ˇcasu klienta vypoˇctené z pˇrijat´ ych paket˚ u (ˇcasov´ ych raz´ıtek). Z obrázku je vidˇet, ˇze rozptyl zpoˇzdˇen´ı paket˚ u v r˚ uzn´ ych smˇerech pr˚ uchodu s´ıt´ı zp˚ usob´ı podobn´ y rozptyl nepˇresnost´ı vypoˇc´ıtan´ ych korekc´ı. Samozˇrejmˇe nejvˇetˇs´ı ˇcetnost hodnot korekc´ı je do 1 ms, ale lze naj´ıt i v´ ysledné korekce, které pˇresahuj´ı hodnotu 3 ms. Korekce vypoˇctené z pˇrijat´ ych paket˚ u K1 dále vstupuj´ı do filtru. V´ ystupn´ı hodnoty filtru jsou znormovány (vydˇeleny 5). V´ ysledné korekce K2, které jsou pouˇzity k u ´pravˇe hodin klienta, jsou zobrazeny na obrázku 4.4 a jsou v´ yraznˇeji niˇzˇs´ı neˇz vstupn´ı korekce. Hodnoty korekc´ı ˇcasu lokáln´ıch hodin jsou pˇribliˇznˇe od - 200 do 200 µs.


2500 2000 1500 1000

k [µs]

500 0 −500 −1000 −1500 −2000 −2500 10

20

30

40

50

60

70

80

90

100

t [s]

Obrázek 4.3: Korekce K1 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms

400 300 200 100

k [µs]

40

0 −100 −200 −300 −400 0

10

20

30

40

50

60

70

80

90

t [s]



41

Jak´ ym zp˚ usobem tato korekce ovlivn´ı v´ yslednou pˇresnost ˇcasu klienta je zobrazeno na obrázku 4.5. Je patrné, ˇze v´ ysledná pˇresnost synchronizace ˇcasu se pohybuje v rozmez´ı do ± 1 ms. V´ ysledek pˇresnosti pˇribliˇznˇe odpov´ıdá velikosti rozptylu zpoˇzdˇen´ı paket˚ u v paketové s´ıti, kter´ y byl v prvn´ı simulaci zvolen 1 ms.

1500

1000

∆t [µs]

500

0

−500

−1000

0

20

40

60

80

100

120

t [s]

Obrázek 4.5: Odchylka ˇcasu klienta od ˇcasu serveru v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms Druhá simulace byla provedena s odliˇsn´ ymi parametry s´ıtˇe. Stˇredn´ı hodnota zpoˇzdˇen´ı paket˚ u v s´ıti byla ponechána na 3 ms, ale rozptyl zpoˇzdˇen´ı, kter´ y se pˇriˇc´ıtá ke stˇredn´ı hodnotˇe byl zvˇetˇsen na 2 ms. Tedy zpoˇzdˇen´ı paketu v jednom smˇeru se m˚ uˇze pohybovat od 1 ms do 5 ms. Toto zvˇetˇsen´ı rozptylu by mˇelo m´ıt za následek zhorˇsen´ı pˇresnosti synchronizace ˇcasu na stranˇe klienta. Obrázek 4.6 zobrazuje korekci ˇcasu K1 vypoˇc´ıtanou z ˇcasov´ ych raz´ıtek NTP paket˚ u. Obrázek 4.7 dále zobrazuje vyfiltrovanou korekci K2, která slouˇz´ı k u ´pravˇe ˇcasu klienta. V´ ysledné korekce v porovnán´ı s pˇredeˇslou simulac´ı jsou pˇribliˇznˇe dvakrát vˇetˇs´ı, coˇz odpov´ıdá pˇredpokladu. Rozptyl paket˚ u pˇ r´ımo ovlivˇ nuje v´ yslednou pˇ resnost synchronizace ˇ casu klienta.


4000

2000

k [µs]

0

−2000

−4000

−6000

10

20

30

40

50

60

70

80

90

100

t [s]


600

400

200

k [µs]

42

0

−200

−400

0

10

20

30

40

50

60

70

80

90

100

t [s]



43

Rozd´ıl ˇcas˚ u klienta a serveru zobrazuje obrázek 4.8. V´ ysledná pˇresnost synchronizace ˇcasu klienta je pˇribliˇznˇe dvakrát horˇs´ı a rozd´ıl ˇcas˚ u dosahuje hodnot 2 ms. 4000

3000

∆t [µs]

2000

1000

0

−1000

−2000

−3000

0

20

40

60

80

100

120

140

160

180

200

t [s]

Obrázek 4.8: Odchylka ˇcasu klienta od ˇcasu serveru v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 2 ms Zpoˇ zdˇ en´ı s´ıtˇ e Stˇredn´ı Rozptyl hodnota [s] 3e-3 1e-3 3e-3 2e-3 3e-3 3e-3 1e-2 1e-3 1e-2 2e-3 1e-2 3e-3

V´ ysledn´ a pˇ resnost Stˇredn´ı Smˇerodatná hodnota [s] odchylka [s] 5,5e-6 3,5e-4 9,5e-6 6,6e-4 -6,8e-6 9,2e-4 2,6e-6 3,4e-4 5,1e-6 6,9e-4 9,9e-6 1,1e-3

synchronizace Min [s] Max [s] -1,3e-3 -2,3e-3 -3,3e-3 -1,2e-3 -2,3e-3 -3,8e-3

1,5e-3 2,4e-3 3,6e-3 1,2e-3 2,5e-3 3,7e-3

Tabulka 4.1: V´ ysledky simulac´ı pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe Simulac´ı bylo provedeno nˇekolik i s jin´ ymi stˇredn´ımi hodnotami zpoˇzdˇen´ı. Jednotlivé v´ ysledky jsou uvedeny v tabulce 4.1. Statistické hodnoty byly vypoˇc´ıtány aˇz po stabilizaci hodin klienta. Vliv zmˇeny stˇredn´ı hodnoty zpoˇzdˇen´ı paket˚ u v simulované s´ıti na v´ yslednou pˇresnost synchronizace je zanedbateln´ y. Hlavn´ım faktorem, kter´ y má vliv na pˇresnost synchronizace ˇcasu klienta, je promˇenlivé zpoˇzdˇen´ı paket˚ u v jednotliv´ ych smˇerech pˇrenosu. ˇ ım vˇ C´ etˇ s´ı rozptyl zpoˇ zdˇ en´ı, t´ım horˇ s´ı pˇ resnost synchronizace ˇ casu klienta.

44


4.2

Mˇ eˇ ren´ı synchronizace v re´ aln´ em prostˇ red´ı

Pˇredchoz´ı podkapitola se zab´ yvala simulac´ı funkce synchronizaˇcn´ıho protokolu. V této kapitole se pokus´ıme vytvoˇrit stejné podm´ınky, jaké byly pouˇzity pˇri simulaci a provést reálné mˇeˇren´ı v reálné s´ıti. Abychom mohli upravovat zpoˇzdˇen´ı jednotliv´ ych paket˚ u v reálné s´ıti, potˇrebujeme zaˇr´ızen´ı, které bude zmˇenu zpoˇzdˇen´ı umoˇzn ˇovat. Byl pouˇzit s´ıt’ov´ y emulátor Simena [10], kter´ y byl zapojen mezi synchronizaˇcn´ı kartu a synchronizaˇcn´ı server. Jako synchronizaˇcn´ı server byl vyuˇzit PTP server LANTIME M600 a jako s´ıt’ová karta byla vyuˇzita karta PTP270PEX stejnˇe jako pˇri mˇeˇren´ı PTP s´ıtˇe popsané v kapitole 2.6.2. Základn´ı princip synchronizace ˇcasu v s´ıti PTP i NTP je stejn´ y, a proto m˚ uˇzeme namˇeˇrené v´ ysledky pouˇz´ıt pro porovnán´ı s pˇredeˇsl´ ymi simulacemi. Blokové schéma zp˚ usobu mˇeˇren´ı je uvedeno na obrázku 4.9.

Obrázek 4.9: Blokové schéma mˇeˇren´ı s emulátorem s´ıtˇe S´ıt’ov´ y emulátor Simena má nˇekolik s´ıt’ov´ ych port˚ u a umoˇzn ˇuje nastavovat jednotlivá zpoˇzdˇen´ı mezi porty. Je moˇzné nastavit konstantn´ı zpoˇzdˇen´ı a nebo pˇridat dalˇs´ı variabiln´ı sloˇzku, coˇz v naˇsem pˇr´ıpadˇe potˇrebujeme. Emulátor umoˇzn ˇuje definovat, jak velká variabiln´ı sloˇzka (rozptyl hodnot zpoˇzdˇen´ı) se má generovat a dále je moˇzné zvolit, podle jakého rozloˇzen´ı se budou generovat. Bylo zvoleno normáln´ı rozloˇzen´ı, které odpov´ıdá skuteˇcnému chován´ı v paketov´ ych s´ıt´ıch (viz. anal´ yza zpoˇzdˇen´ı v kapitole 2.6.1). Jednotlivá zpoˇzdˇen´ı jsme nastavovali stejnˇe jako u pˇredchoz´ıch simulac´ıch. V´ ysledkem prvn´ıho mˇeˇren´ı, kdy emulátor mˇel nastavenou stˇredn´ı hodnotu zpoˇzdˇen´ı na 3 ms a rozptyl hodnot byl nastaven na 1 ms, je pˇresnost ˇcasu klienta zobrazena na obrázku 4.10. V´ ysledn´ y rozd´ıl ˇcasu klienta a serveru dosahuje hodnot aˇz 3 ms, coˇz je horˇs´ı v´ ysledek neˇz za stejn´ ych podm´ınek pˇri simulaci. V pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 2 ms (obrázek 4.11) je také nepˇresnost synchronizace ˇcasu vˇetˇs´ı. Pravdˇepodobnˇe to bude dáno t´ım, ˇze s´ıt’ová karta s PTP protokolem nevyuˇz´ıvá ˇza´dn´ ych statistick´ ych v´ ypoˇct˚ u ke zlepˇsen´ı pˇresnosti. Z principu PTP protokolu se provád´ı synchronizace jen mezi dvˇema body s´ıtˇe, a proto se nepˇredpokládá velké kol´ısán´ı zpoˇzdˇen´ı paket˚ u. Z toho vypl´ yvá, ˇze vyuˇzit´ı filtraˇcn´ıch algoritm˚ u zlepˇsuje v´ yslednou pˇresnost synchronizace.

ˇ REN ˇ Í SYNCHRONIZACE V REALN ´ EM ´ PROSTRED ˇ Í 4.2. ME

45

−3

4

x 10

3

2

∆t [s]

1

0

−1

−2

−3

−4 0

100

200

300

400

500

600

700

800

900

1000

t [s]

Obrázek 4.10: Odchylka ˇcasu klienta od ˇcasu serveru v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms −3

x 10

6

4

∆t [s]

2

0

−2

−4

−6

−8 0

100

200

300

400

500

600

700

800

900

1000

t [s]

Obrázek 4.11: Odchylka ˇcasu klienta od ˇcasu serveru v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 2 ms

46

´ ˇ ÍHO ALGORITMU KAPITOLA 4. NAVRH A SIMULACE SYNCHRONIZACN −3

x 10 4

3

2

1

∆t [s]

0

−1

−2

−3

−4

−5

−6 0

100

200

300

400

500

600

700

800

900

1000

t [s]

Obrázek 4.12: Odchylka ˇcasu klienta od ˇcasu serveru v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 10 ms a rozptylu 1 ms U mˇeˇren´ı (obr. 4.12), kde byla nastavena stˇredn´ı hodnota zpoˇzdˇen´ı na 10 ms a rozptyl na 1 ms, jsou v´ ysledky podobné pˇredchoz´ımu mˇeˇren´ı se stˇredn´ı hodnotou 3 ms a s rozptylem 1 ms. To potvrzuje pˇredpoklad, ˇze pˇresnost synchronizace ˇcasu závis´ı na variabiln´ı sloˇzce zpoˇzdˇen´ı. Veˇskerá jednotlivá mˇeˇren´ı shrnuje tabulka 4.2, kde jsou uvedeny jednotlivé v´ ysledky. Tabulka obsahuje také mˇeˇren´ı, kde bylo nastaveno nulové zpoˇzdˇen´ı. Emulátor s´ıtˇe i pˇri tomto nastaven´ı ovlivˇ nuje procházej´ıc´ı pakety a t´ım pádem i v´ yslednou pˇresnost synchronizace ˇcasu klienta. Zpoˇ zdˇ en´ı dan´ e emul´ atorem Stˇredn´ı Rozptyl hodnota [s] 3e-3 1e-3 3e-3 2e-3 1e-2 1e-3 1e-2 3e-3 0 0

V´ ysledn´ a pˇ resnost Stˇredn´ı Smˇerodatná hodnota [s] odchylka [s] 2,3e-4 1,3e-3 2,6e-4 2,5e-3 -3,1e-4 1,3e-3 1,3e-3 3,7e-3 9,8e-5 1,2e-4

synchronizace Min [s] Max [s] -3,6e-3 -8,0e-3 -5,5e-3 -9,9e-3 -1,6e-4

3,4e-3 6,7e-3 3,2e-3 9,9e-3 3,5e-4

Tabulka 4.2: V´ ysledky mˇeˇren´ı s emulátorem s´ıtˇe pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe V´ ysledná pˇresnost synchronizace je pomˇernˇe n´ızká a je závislá na variabilitˇe zpoˇzdˇen´ı paket˚ u. PTP protokol je navrˇzen pro pˇresnou synchronizaci a pravdˇepodobnˇe nepoˇc´ıtá s

´ ˇ Í SYNCHRONIZACE 4.3. NAVRH NA ZLEPSEN

47

velk´ ym variabiln´ım zpoˇzdˇen´ım paket˚ u v s´ıti. Dalˇs´ı ˇca´st práce se zab´ yvá moˇznostmi vylepˇsen´ı v´ ysledné pˇresnosti synchronizace ˇcasu na stranˇe klienta.

4.3

N´ avrh na zlepˇ sen´ı synchronizace

Kapitola 4.1 a 4.2 se vˇenovala simulaci a mˇeˇren´ı v reálné s´ıti. C´ılem této kapitoly je navrhnout vylepˇsen´ y synchronizaˇcn´ı algoritmus tak, aby doˇslo ke zv´ yˇsen´ı pˇresnost ˇcasu na stranˇe klienta. Jednou z metod je vyuˇzit´ı optimalizovaného filtru, aby byla pˇresnˇejˇs´ı korekce ˇcasu klienta. Dalˇs´ı moˇznost´ı je vyuˇzit´ı nˇekolika hodin na stranˇe klienta, které se budou vzájemnˇe dolad’ovat. Bylo navrˇzeno rozˇs´ıˇren´ı standardn´ıho blokového schématu uvedeného na obrázku 4.1 a nové blokové schéma je uvedeno na obrázku 4.13.

Obrázek 4.13: Rozˇs´ıˇrené blokové schéma synchronizace ˇcasu Z blokového schématu je patrné znaˇcné rozˇs´ıˇren´ı strany klienta. Doˇslo k pˇridán´ı druh´ ych lokáln´ıch hodin oznaˇcen´ ych jako H2 a k nim pˇr´ısluˇsej´ıc´ıch obvod˚ u. Smyˇcka lokáln´ıch hodin

48


H1 z˚ ustala stejná jako u základn´ıho stavu (kap. 4.1). Pˇri hledán´ı vhodného filtru je potˇreba se zab´ yvat stabilitou celého obvodu. Stabilita a jednotlivá rizika jsou popsána v kapitole 4.3.1, kde v´ ysledkem bylo nahrazen´ı FIR filtru IIR filtrem, kter´ y dosahoval lepˇs´ıch v´ ysledk˚ u. Vlastnostem a nastaven´ı filtru se vˇenuje podrobnˇeji kapitola 4.3.1.2. Za u ´ˇcelem vyˇsˇs´ı pˇresnosti synchronizace ˇcasu je v´ ysledn´ y ˇcas hodin H1 porovnáván ˇ s ˇcasem hodin H2. Cas lokáln´ıch hodin H2 je zpˇresˇ nován pomoc´ı korekc´ı K4, které jsou vypoˇc´ıtávány s menˇs´ı frekvenc´ı neˇz v pˇr´ıpadˇe hodin H1, které jsou ˇr´ızeny korekc´ı K2. O urˇcen´ı v´ ysledné korekce K4 se stará pr˚ umˇerovac´ı filtr, kter´ y shromaˇzd’uje ˇcasové rozd´ıly jednotliv´ ych hodin H1 a H2 (Korekce K3). Dalˇs´ı a zároveˇ n posledn´ı smyˇcka se stará o dolad’ován´ı lokáln´ıho oscilátoru a v blokovém schématu je oznaˇcena jako PLL. Pokud lokáln´ı oscilátor nen´ı zcela pˇresn´ y, bude se ˇcas klienta a serveru postupnˇe rozcházet a v´ ysledné korekce jednotliv´ ych hodin budou stále kladné ˇci záporné. Stabilita lokáln´ıho oscilátoru je velice d˚ uleˇzitá i v pˇr´ıpadˇe vyuˇzit´ı taktovac´ıho signálu pro dalˇs´ı zaˇr´ızen´ı a vytvoˇren´ı pˇresného generátoru taktu. Fázová smyˇcka lokáln´ıho oscilátoru má za u ´kol urˇcit v´ yslednou nepˇresnost z korekc´ı K3 a doladit lokáln´ı oscilátor na co nejpˇresnˇejˇs´ı hodnotu z pohledu dlouhodobé stability. Jednotliv´ ym blok˚ um a v´ ysledk˚ um pˇresnosti synchronizace ˇcasu klienta se vˇenuj´ı následuj´ıc´ı ˇca´sti této kapitoly.

4.3.1

N´ avrh vhodn´ eho filtru - stabilita obvodu

Pˇri návrhu vhodného filtru jsem narazil na problém se stabilitou celého obvodu. Je potˇreba si uvˇedomit, ˇze ˇca´st s filtrem a lokáln´ımi hodinami H1, pˇredstavuje uzavˇrenou smyˇcku. Blokové schéma smyˇcky je uvedeno na následuj´ıc´ım obrázku 4.14. Z obrázku je patrné, ˇze filtr v této smyˇcce pracuje jako regulátor, kter´ y vyhodnocuje odchylky ˇcas˚ ua pomoc´ı korekce K2 ˇr´ıd´ı lokáln´ı hodiny H1. Problematiku ˇr´ızen´ı a stability jednotliv´ ych obvod˚ u m˚ uˇzeme naj´ıt detailnˇe rozpracovanou napˇr´ıklad v knize [11].

Obrázek 4.14: Regulaˇcn´ı smyˇcka Pˇri ˇreˇsen´ı regulaˇcn´ıho obvodu uvaˇzujme jako vstupn´ı veliˇcinu ˇcas (oznaˇcen´ y jako W ) a v´ ystupn´ı veliˇcinu regulaˇcn´ıho obvodu také ˇcas (oznaˇcen´ y jako Y ). Z pomˇeru mezi ˇza´danou veliˇcinou Y a regulovanou veliˇcinou W m˚ uˇzeme urˇcit pˇrenos ˇr´ızen´ı (vztah 4.1).


GW =

GF · GH Y = W 1 + GF · GH

49

(4.1)

kde GW je pˇrenos ˇr´ızen´ı, W je vstupn´ı veliˇcina (ˇcas), Y je v´ ystupn´ı veliˇcina (ˇcas), GF je pˇrenos filtru (regulátoru), GH je pˇrenos hodin (regulované soustavy). Souˇcin vˇsech ˇclen˚ u ve smyˇcce pˇredstavuje pˇrenos otevˇreného regulaˇcn´ıho obvodu (ORO) a oznaˇcuje se jako GO (vztah 4.2). GO = GF · GH

(4.2)

Charakteristick´ y mnohoˇclen 1 + GO pˇredstavuje v´ yraz ve jmenovateli u pˇrenosu ˇr´ızen´ı a vlastnˇe i u vˇsech ostatn´ıch pˇrenos˚ u regulaˇcn´ıho obvodu a je velice d˚ uleˇzit´ y pro stabilitu obvodu. Pokud charakteristick´ y mnohoˇclen poloˇz´ıme rovn´ y 0 z´ıskáme charakteristickou rovnici (4.3). 1 + GO = 0

(4.3)

Pˇri vyˇsetˇrován´ı stability diskrétn´ıch obvodu je potˇreba vycházet z charakteristického mnohoˇclenu, resp. charakteristické rovnice. Pro diskrétn´ı regulaˇcn´ı obvod se pouˇz´ıvá Ztransformace. Diskr´ etn´ı RO je stabiln´ı pr´ avˇ e tehdy, kdyˇ z velikost vˇ sech koˇ ren˚ u charakteristick´ eho mnohoˇ clenu bude menˇ s´ı neˇ z 1 [30].

Obrázek 4.15: Oblast stability diskrétn´ıch regulaˇcn´ıch obvod˚ u V mém pˇr´ıpadˇe je stabilita obvodu závislá hlavnˇe na pˇrenosu regulátoru (filtru) a pˇrenos hodin lze povaˇzovat za jednotkov´ y. Proto se zamˇeˇr´ım na vyˇsetˇren´ı filtru. Dalˇs´ım hlavn´ım aspektem, na kter´ y dále naraz´ıme, je zpoˇzdˇen´ı jednotliv´ ych druh˚ u filtr˚ u.

50 4.3.1.1

´ ˇ ÍHO ALGORITMU KAPITOLA 4. NAVRH A SIMULACE SYNCHRONIZACN Vlastnosti a v´ ysledky FIR filtru

FIR filtry se mohou zdát jako ideáln´ı pro realizaci regulátoru, protoˇze jsou vˇzdy stabiln´ı a vˇsechny póly maj´ı um´ıstˇeny v nule. Magnitude Response (dB) 0

−10

Magnitude (dB)

−20

−30

−40

−50

−60

−70 0

0.1

0.2

0.3

0.4 0.5 0.6 0.7 Normalized Frequency (×π rad/sample)

0.8

0.9

Obrázek 4.16: Amplitudová charakterist. fitru FIR ˇra´du 20 s mezn´ım kmitoˇctem 0,03 Hz Byl proveden návrh filtru FIR stejného typu, jako byl uveden v pˇredchoz´ı kapitole na obrázku 4.2, ale doˇslo ke zv´ yˇsen´ı stupnˇe filtru na 20. Kmitoˇcet propustného pásma FIR filtru byl ponechán na 0,03 Hz a vzorkovac´ı kmitoˇcet 1 Hz. Provedeme návrh filtru a z´ıskáme pˇrenosovou funkci (4.4). Z´ıskaná pˇrenosová funkce má následuj´ıc´ı tvar:

H[z] =

Y [z] = 0, 004085 + 0, 006067z −1 + 0, 01124z −2 + 0, 02003z −3 + X[z] 0, 03221z −4 + 0, 04691z −5 + 0, 06268z −6 + 0, 07771z −7 + 0, 09014z −8 + 0, 09834z −9 + 0, 1012z −10 + 0, 09834z −11 + 0, 09014z −12 + 0, 07771z −13 + 0, 06268z −14 + 0, 04691z −15 + 0, 03221z −16 + 0, 02003z −17 + 0, 01124z −18 + 0, 006067z −19 + 0, 004085z −20 (4.4)

Amplitudová charakteristika filtru je zobrazena na obrázku 4.16 a zobrazen´ı nul a pól˚ u je uvedeno na obrázku 4.17. Z amplitudové charakteristiky je zˇrejmé, ˇze se zvˇetˇsila strmost daného filtru. Stabilita filtru je také vyhovuj´ıc´ı, vˇsechny póly jsou v nule. Pod´ıvejme se na v´ ysledek synchronizace ˇcasu v navrˇzeném systému (obrázek 4.18). Z obrázku je patrné rozkmitán´ı celého systému. D˚ uvodem je velké zpoˇzdˇen´ı filtru, které zp˚ usobuje velmi pomalou reakci v´ ystupn´ı veliˇciny na vstupn´ı (pˇrekmitnut´ı zmˇeny ˇcasu hodin do vˇetˇs´ıch odchylek s opaˇcn´ ym znaménkem neˇz byla p˚ uvodn´ı chyba). D˚ uvodem


51

Obrázek 4.17: Zobrazen´ı nul a pól˚ u filtru FIR ˇra´du 20 s mezn´ım kmitoˇctem 0,03 Hz je i chyba daná zpoˇzdˇen´ım s´ıtˇe, která je na blokovém schématu 4.14 oznaˇcena jako chybová veliˇcina. Z toho vypl´ yv´ a, ˇ ze cel´ y syst´ em je potˇ reba ˇ reˇ sit jako syst´ em se zpoˇ zdˇ en´ım a jedn´ım z hlavn´ıch poˇ zadavk˚ u je minimalizace zpoˇ zdˇ en´ı. Samotná stabilita filtru nestaˇc´ı. Proto je v následuj´ıc´ı sekci uveden návrh realizace pomoc´ı IIR filtru.


5

6

x 10

4

2

∆t [µs]

52

0

−2

−4

−6

−8

0

1

2

3

4

5

6

7

t [s]

Obrázek 4.18: V´ ysledek synchronizace ˇcasu klienta s filtrem FIR ˇra´d 20

´ ˇ Í SYNCHRONIZACE 4.3. NAVRH NA ZLEPSEN 4.3.1.2

53

Vlastnosti a v´ ysledky IIR filtru

IIR filtry maj´ı oproti FIR filtr˚ um mnohem vˇetˇs´ı strmost pˇri niˇzˇs´ım stupni filtru. To je velice v´ yhodné, jelikoˇz ˇc´ım niˇzˇs´ı stupeˇ n filtru, t´ım niˇzˇs´ı je i zpoˇzdˇen´ı celého filtru. V pˇr´ıpadˇe návrhu IIR filtru je potˇreba vˇetˇs´ı kontroly návrhu, protoˇze IIR filtr m˚ uˇze b´ yt nestabiln´ı, zat´ımco FIR filtr je vˇzdy stabiln´ı. Pˇri návrhu IIR filtru byla zvolena doln´ı propust s mezn´ım kmitoˇctem propustného pásma 0,03 Hz a vzorkovac´ım kmitoˇctem 1 Hz (stejnˇe jako u FIR filtru) a byla vyuˇzita Butterworthova aproximace. Byl pouˇzit IIR filtr ˇra´du 4, kter´ y má dostateˇcnou strmost a dostateˇcnˇe rychlou odezvu v regulaˇcn´ı smyˇcce. Amplitudová charakteristika IIR filtru ˇra´du 4 je uvedena na obrázku 4.19. Magnitude Response (dB) 0 −20 −40

Magnitude (dB)

−60 −80 −100 −120 −140 −160 −180 −200 0

0.1

0.2

0.3

0.4 0.5 0.6 0.7 Normalized Frequency (×π rad/sample)

0.8

0.9

Obrázek 4.19: Filtr IIR s ˇra´dem 4 Zobrazen´ı nul a pól˚ u je uvedeno na obrázku 4.20 a filtr IIR je stabiln´ı (Póly oznaˇcené kˇr´ıˇzkem). Pˇrenosová funkce je dána vztahem 4.5.

H[z] =

4, 373e−6 z −4 + 1, 749e−1 z −3 + 2, 624e−5 z −2 + 1, 749e−5 z −3 + 4, 373e−6 z −4 (4.5) 1 − 3, 754z −1 + 5, 291z −2 − 3, 319z −3 + 0, 7816z −4

V pˇr´ıpadˇe pouˇzit´ı IIR filtru pˇri synchronizaci ˇcasu se systém choval korektnˇe a k rozkmitán´ı soustavy nedoˇslo. Z pohledu ˇreˇsen´ı stability zm´ınˇeného systému se zpoˇzdˇen´ım m˚ uˇzeme vyuˇz´ıt Nyquistovo kritérium stability [11]. Toto kritérium umoˇzn ˇuje ovˇeˇrit stabilitu regulaˇcn´ıho obvodu na základˇe kmitoˇctové charakteristiky. Nyquist˚ uv diagram je uveden na obrázku 4.21. Kritérium stability ˇr´ıká, ˇze regulaˇcn´ı obvod bude stabiln´ı tehdy

54

´ ˇ ÍHO ALGORITMU KAPITOLA 4. NAVRH A SIMULACE SYNCHRONIZACN Pole/Zero Plot 1 0.8 0.6

Imaginary Part

0.4 0.2 4

0 −0.2 −0.4 −0.6 −0.8 −1 −1.5

−1

−0.5

0 Real Part

0.5

1

1.5

Obrázek 4.20: Zobrazen´ı nul a pól˚ u filtru IIR ˇra´du 4 s mezn´ım kmitoˇctem 0,03 Hz a jen tehdy, kdyˇz amplitudo-fázová kmitoˇctová charakteristika otevˇreného regulaˇcn´ıho obvodu neobklopuje kritick´ y bod [-1; j0]. Z uveden´ ych v´ ysledk˚ u vypl´ yvá, ˇze samotn´ y systém s IIR filtrem je stabiln´ı. Z pohledu vstupn´ı hodnoty filtru je ale také nutné poˇc´ıtat s chybovou veliˇcinou (obr. 4.14), která zde reprezentuje nepˇresnost zpoˇzdˇen´ı v reálné paketové s´ıti. V pˇr´ıpadˇe správné funkce ˇcasového protokolu se bude korekce K1 bl´ıˇzit nule, ale v pˇr´ıpadˇe chyb (napˇr´ıklad pˇri v´ ypadku spojen´ı) m˚ uˇze doj´ıt k nekorektn´ım hodnotám ˇcas˚ u (pˇr´ıpadnˇe korekc´ı), které je potˇreba pˇredem odstranit. Pˇri návrhu je proto dobré provést simulace pro r˚ uzné hodnoty zpoˇzdˇen´ı s´ıtˇe a ovˇeˇrit si tak stabilitu systému. Navrˇzené filtry byly podrobeny d˚ ukladnému testován´ı pomoc´ı simulac´ı. Pˇri kaˇzdé simulaci je nastavována stˇredn´ı hodnota zpoˇzdˇen´ı paket˚ u v s´ıti a rozptyl zpoˇzdˇen´ı paket˚ u, kter´ y je pˇriˇc´ıtán ke stˇredn´ı hodnotˇe zpoˇzdˇen´ı. Simulace byly provádˇeny pro stˇredn´ı hodnotu zpoˇzdˇen´ı 3 ms a 10 ms a s rozptylem 1, 2 a 3 ms. V´ ysledky jsou jako pˇr´ıklad uvedeny pro stˇredn´ı hodnotu zpoˇzdˇen´ı 3 ms s rozptylem 1 ms. Na prvn´ım obrázku 4.22 je zobrazen v´ ysledek v´ ypoˇctu korekce vypoˇc´ıtané z pˇrijat´ ych paket˚ u (v blokovém schématu je oznaˇcena jako K1). Tato korekce je následnˇe vyhodnocována IIR filtrem. V´ ysledné vypoˇc´ıtané korekce z´ıskané po pr˚ uchodu hodnot filtrem (v blokovém schématu oznaˇcené jako K2) jsou zobrazeny na obrázku 4.23. V´ ysledné hodnoty korekc´ı v porovnán´ı s bˇeˇzn´ ym stavem, kde byl pouˇzit FIR filtr zobrazen´ y na obrázku 4.4, jsou mnohem niˇzˇs´ı. Jedná se pˇribliˇznˇe o desetinásobné zmenˇsen´ı hodnoty korekc´ı, které z IIR filtru z´ıskáváme. To má i v´ yznamn´ y vliv na v´ yslednou pˇresnost synchronizace, která je uvedena na obrázku 4.24.


55

Nyquist Diagram 1 0.8 0.6

Imaginary Axis

0.4 0.2 0 −0.2 −0.4 −0.6 −0.8 −1 −1

−0.8

−0.6

−0.4

−0.2

0 Real Axis

0.2

0.4

0.6

0.8

1

Obrázek 4.21: Nyquist˚ uv diagram pro filtr IIR s ˇra´dem 4

2000

k [µs]

1000

0

−1000

−2000

−3000 0

10

20

30

40

50

60

70

80

90

t [s]


56


25 20 15 10

k [µs]

5 0 −5 −10 −15 −20 −25 10

20

30

40

50

60 t [s]

70

80

90

100

110


250 200 150 100

∆t [µs]

50 0 −50 −100 −150 −200 0

20

40

60

80

100

120

140

160

t [s]

Obrázek 4.24: Odchylka ˇcasu serveru od ˇcasu klienta v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms


4.3.2

57

Simulace a v´ ysledky druh´ ych hodin

V této podkapitole je uvedeno vylepˇsen´ı v´ ysledné synchronizace ˇcasu v podobˇe pˇridan´ ych ´ dalˇs´ıch hodin. Uˇcelem tˇechto hodin je zamezit velkému kol´ısán´ı pˇresnosti ˇcasu, a proto bude ˇr´ızen´ı prob´ıhat mnohem pomaleji neˇz je tomu v pˇr´ıpadˇe prvn´ıch hodin. Jak je uvedeno v blokovém schématu principu synchronizace (obr. 4.13), jsou druhé hodiny nastavovány a ˇ ast blokového schématu je uvedena na obrázku 4.25. dolad’ovány z prvn´ıch hodin. C´ Korekce K3

Porovnávač as z lokálních časů Hodin H1

Průměrovací Filtr

as Lokální Hodiny H2 Lokální oscilátor

Korekce K4

Takt

PLL

ˇ ast blokového schématu s hodinami H2 Obrázek 4.25: C´ Stejnˇe jako hodiny H1 jsou i hodiny H2 ˇr´ızeny stejn´ ym taktem. V reálném prostˇred´ı se pouˇz´ıvá oscilátor, kter´ y má urˇcitou m´ıru stability. Bˇehem simulace jsem zvolil takt 1 MHz (perioda 1 µs), kter´ y jsem také definovan´ ym zp˚ usobem na poˇca´tku znepˇresnil (typicky ˇra´dovˇe odchylka 2 Hz) a analyzoval jsem správnou funkci dolad’ován´ı oscilátoru. Podrobnˇeji to bude rozepsáno dále. ´ Hodiny H2 se chovaj´ı stejnˇe jako hodiny H1. Uprava ˇcasu hodin je provádˇena pomoc´ı korekce K4, která vycház´ı z pr˚ umˇerovac´ıho filtru. Samozˇrejmˇe na zaˇca´tku jsou hodiny H2 nastaveny pˇr´ımo z hodin H1 a to po dostateˇcném ustálen´ı ˇcasu hodin H1. V pˇr´ıpadˇe simulace dojde k ustálen´ı hodin H1 bˇehem 1 s. Cyklus synchronizace se provád´ı jednou za 10 ms, tedy kaˇzd´ ych 10 ms je vyslán nov´ y dotaz na server a po zaslán´ı odpovˇedi jsou vypoˇc´ıtány jednotlivé korekce. V´ ysledn´ y ˇcas hodin H2 a hodin H1 je porovnáván v bloku nazvan´ ym jako Porovnávaˇc ˇcas˚ u. V´ ysledkem je rozd´ıl ˇcas˚ u hodin H1 a H2. Tento rozd´ıl je dále propagován jako korekce K3, která vstupuje do pr˚ umˇerovac´ıho filtru a také do ’ fázového závˇesu, kter´ y ˇr´ıd´ı dolad ován´ı oscilátoru. 4.3.2.1

Pr˚ umˇ erovac´ı filtr

Pr˚ umˇerovac´ı filtr slouˇz´ı k ukládán´ı hodnot jednotliv´ ych korekc´ı K3 a po z´ıskán´ı dostateˇcného poˇctu hodnot urˇc´ı v´ yslednou korekci K4 pro hodiny H2. Jelikoˇz je potˇreba

58


z´ıskat korekci jednou za urˇcité delˇs´ı obdob´ı, nebylo moˇzné pouˇz´ıt ˇza´dn´ y standardn´ı filtr, protoˇze stupeˇ n filtru by byl extrémnˇe velik´ y. Také by docházelo ke korekci pˇri kaˇzdé vstupn´ı hodnotˇe, coˇz je neˇza´douc´ı. Pro pr˚ umˇerovac´ı filtr zavedeme obecnou veliˇcinu δ (delta), která bude urˇcovat poˇcet pr˚ umˇerovan´ ych vzork˚ u. Tato δ také urˇcuje dobu, za kterou jsou hodiny korigovány. Pr˚ umˇerovac´ı filtr provád´ı prost´ y pr˚ umˇer hodnot, kter´ y vypoˇc´ıtá jednu hodnotu z δ pˇredchoz´ıch hodnot. Hlavn´ım c´ılem je zamezit neˇza´douc´ım v´ ychylkám, které m˚ uˇzou negativnˇe ovlivnit pˇresnost ˇcasu hodin H2. Na základˇe proveden´ ych simulac´ı s r˚ uznou hodnotou δ, byla jako optimáln´ı hodnota zvolna hodnota 50. V pˇr´ıpadˇe vˇetˇs´ı hodnoty δ je ˇ ım vˇetˇs´ı potˇreba si uvˇedomit, ˇze tato hodnota má vliv na rychlost u ´pravy ˇcasu hodin H2. C´ poˇcet pr˚ umˇerovan´ ych hodnot, t´ım delˇs´ı bude ˇcas potˇrebn´ y k pˇresnému doladˇen´ı hodin z chybného poˇca´teˇcn´ıho stavu. Proto je vhodné zachovat hodnotu δ v mez´ıch stanoven´ ych následuj´ıc´ım vztahem (4.6): 30 ≤ δ ≤ 100

(4.6)

V závislosti na velikosti rozd´ılu ˇcasu hodin H1 a H2 bylo zvoleno odstupˇ nován´ı velikost´ı jednotliv´ ych v´ ysledn´ ych korekc´ı K4. Samotn´ y pr˚ umˇer x rozd´ılu ˇcas˚ u H1 a H2 z´ıskan´ ych z poˇctu hodnot δ nelze pˇr´ımo pouˇz´ıt jako korekci K4. D˚ uvodem je nemˇen´ıc´ı se ˇcas hodin H2, které se koriguj´ı jednou za delˇs´ı ˇcasov´ yu ´sek dan´ y hodnotou δ. Proto je korekce K4 urˇcována podle následuj´ıc´ıch vztah˚ u: x=

Pδ

i=1

H1i − H2i δ

(4.7)

V´ ysledná korekce K4 je pro jednotlivé pˇr´ıpady vypoˇc´ıtána takto: Pokud x > 5µs nebo x < −5µs tak K4 =

Pokud 5µs ≥ x > 2µs nebo

Pokud 2µs ≥ x > 1µs nebo

x · 10 δ

(4.8)

− 5µs ≤ x < −2µs tak K4 =

− 2µs ≤ x < −1µs tak K4 =

Pokud 1µs ≥ x ≥ −1µs tak K4 =

x δ

x ·4 δ

x ·2 δ

(4.9)

(4.10)

(4.11)

Skuteˇcné hodnoty jednotliv´ ych korekc´ı K4 jsou uvedeny na následuj´ıc´ım obrázku 4.26 spoleˇcnˇe s korekcemi K2, které jsou urˇcovány IIR filtrem. Pˇri porovnán´ı je v´ ysledná velikost korekce K4 menˇs´ı a pozvolnˇejˇs´ı, coˇz bylo hlavn´ım c´ılem. To v´ yrazn´ ym zp˚ usobem ovlivn´ı v´ yslednou pˇresnost hodin H2.


59

30 Korekce K2 Korekce K4 20

k [µs]

10

0

−10

−20

40

50

60

70

80

90 t [s]

100

110

120

130

140

Obrázek 4.26: V´ ysledné korekce K4 a K2 pˇri stˇredn´ı hodnotˇe zpoˇzdˇen´ı 3 ms a rozptylu 1 ms 4.3.2.2

V´ ysledn´ a pˇ resnost hodin H2

Hodiny H2 jsou ˇr´ızeny stejn´ ym lokáln´ım oscilátorem jako hodiny H1, ale ˇcas hodin H2 je upravován a zpˇresˇ nován pomoc´ı korekc´ı K4 (blokové schéma na obrázku 4.25). Hodnoty korekc´ı K4 byly uvedeny na obrázku 4.26 v pˇredeˇslé podkapitole. Tyto korekce jsou pˇriˇc´ıtány k ˇcasu hodin H2 a postupnˇe docház´ı ke zpˇresˇ nován´ı ˇcasu H2 tak, aby se co nejv´ıce bl´ıˇzil ˇcasu serveru. Rozd´ıl ˇcasu serveru a hodin H2 zobrazuje následuj´ıc´ı obrázek 4.27. Je zde vidˇet, ˇze po stabilizaci je maximáln´ı rozd´ıl ˇcasu mezi hodinami H2 a serverem okolo 50 µs. Pokud porovnáme tento v´ ysledek s hodinami H1 na stranˇe klienta (obr. 4.24) nebo pokud si hodiny H1 a H2 dáme do stejného grafu, ukáˇze se nám v´ ysledn´ y efekt zpˇresnˇen´ı ˇcasu. Toto porovnán´ı je uvedeno na obrázku 4.28. Modrá kˇrivka reprezentuje rozd´ıl ˇcasu hodin H1 a serveru, ˇcervená kˇrivka ukazuje rozd´ıl ˇcasu hodin H2 a serveru. Na zaˇca´tku je ˇcas hodiny H2 u ´myslnˇe posunut a je zde vidˇet postupné zpˇresnˇen´ı ˇcasu hodin H2. Hodiny H1 jsou samozˇrejmˇe v tomhle ohledu rychlejˇs´ı, protoˇze jsou ˇr´ızeny z pˇrijat´ ych paket˚ u a IIR filtru, jak uˇz bylo zm´ınˇeno dˇr´ıve v kap. 4.3.1.2. V´ ysledn´ y pr˚ ubˇeh rozd´ılu ˇcasu hodin H2 a serveru je vyrovnan´ y a pˇresnˇejˇs´ı. V´ ysledky simulace potvrdily pˇredpoklad chován´ı celého

60


100

∆t [µs]

50

0

−50 50

100

150 t [s]

200

250

300

Obrázek 4.27: Rozd´ıl ˇcasu serveru a hodin H2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms systému. Pokud porovnáme maximáln´ı odchylky ˇcas˚ u hodin H1 a H2 oproti serveru (H1 max okolo 200 µs a H2 max okolo 50 µs), tak se v´ ysledná pˇresnost zlepˇsila 4x. Pˇresnost v ˇra´du des´ıtek mikrosekund pˇri pr˚ umˇerném zpoˇzdˇen´ı s´ıtˇe 3 ms a rozptylem paket˚ u 1 ms je velice dobrá. Vˇsechny v´ ysledky, které byly v této podkapitole uvedeny, byly simulovány za stejn´ ych podm´ınek nastaven´ı s´ıtˇe. Jedná se o pˇr´ıpad, kdy stˇredn´ı hodnota zpoˇzdˇen´ı s´ıtˇe byla nastavena na 3 ms a rozptyl tohoto zpoˇzdˇen´ı byl 1 ms. Z toho vypl´ yvá, ˇze zpoˇzdˇen´ı jedn´ım smˇerem bylo generováno v rozmez´ı od 2 ms do 4 ms. Simulace byly provádˇeny i pro ostatn´ı hodnoty zpoˇzdˇen´ı, stejnˇe jako pˇri simulaci aktuáln´ıho stavu v kapitole 4.1, abychom mohli jednotlivé v´ ysledky porovnat. Následuj´ıc´ı tabulky 4.3 a 4.4 zobrazuj´ı v´ ysledky pˇresnosti ˇcasu klienta oproti ˇcasu serveru pro jednotlivé simulace. Tabulka 4.3 zobrazuje v´ yslednou pˇresnost ˇcasu hodin H1 pro jednotlivé varianty simulac´ı. Rozd´ıl v´ ysledn´ ych hodnot oproti tabulce 4.1, kde pˇri simulac´ıch byl pouˇzit jin´ y filtr, je znateln´ y. Podle vypoˇc´ıtan´ ych statistick´ ych hodnot pˇrináˇs´ı pouˇzit´ı IIR filtru zlepˇsen´ı pˇresnosti synchronizace ˇcasu o necel´ y jeden ˇra´d. V pˇr´ıpadˇe porovnán´ı pˇresnosti hodin H1 a H2 na stranˇe klienta je vidˇet rozd´ıl pˇribliˇznˇe o jeden ˇra´d. Hodiny H2 vykazuj´ı vyˇsˇs´ı stabilitu, která jiˇz byla ukázána na obrázku 4.28, kde je zobrazeno porovnán´ı pˇresnosti synchronizace ˇcasu hodin H1 a H2. V´ ysledky simulac´ı potvrdily pˇredpoklad, kdy v´ ysledná pˇresnost ˇcasu hodin H2 dosahuje nejvyˇsˇs´ıch hodnot. Pro názornost zde uvedu i graf porovnán´ı ˇcasu hodin H1 a H2 pro simulace se stˇredn´ı


61

Hodiny H1 Hodiny H2

400 300 200

∆t [µs]

100 0 −100 −200 −300 −400 50

100

150

200

250

t [s]

Obrázek 4.28: Rozd´ıl ˇcasu serveru a ˇcasu hodin H1 a H2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms hodnotou zpoˇzdˇen´ı 3 ms a rozptylem 3 ms (Obr. 4.29) a se stˇredn´ı hodnotou zpoˇzdˇen´ı 10 ms a rozptylem 1 ms (Obr. 4.30). Jak uˇz bylo ˇreˇceno dˇr´ıve, stˇredn´ı hodnota zpoˇzdˇen´ı nemá zásadn´ı vliv na v´ yslednou pˇresnost synchronizace, coˇz je názornˇe vidˇet jak v tabulkách, tak i v pˇr´ıpadˇe porovnán´ı obrázk˚ u 4.28 a 4.30.

62


Zpoˇ zdˇ en´ı s´ıtˇ e Stˇredn´ı Rozptyl hodnota [s] 3e-3 1e-3 3e-3 2e-3 3e-3 3e-3 1e-2 1e-3 1e-2 2e-3 1e-2 3e-3

V´ ysledn´ a pˇ resnost synchronizace hodin H1 Stˇredn´ı Smˇerodatná Min [s] Max [s] hodnota [s] odchylka [s] 4,2e-6 6,4e-5 -2,2e-4 2,2e-4 8,6e-6 1,2e-4 -4,4e-4 4,6e-4 1,2e-5 1,6e-4 -6,3e-4 6,4e-4 -7,9e-6 5,8e-5 -2,2e-4 1,8e-4 7,2e-6 1,2e-4 -4,3e-4 4,1e-4 1,1e-5 1,8e-4 -6,5e-4 6,1e-4

Tabulka 4.3: V´ ysledky pˇresnosti synchronizace hodin H1 pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe

Zpoˇ zdˇ en´ı s´ıtˇ e Stˇredn´ı Rozptyl hodnota [s] 3e-3 1e-3 3e-3 2e-3 3e-3 3e-3 1e-2 1e-3 1e-2 2e-3 1e-2 3e-3

V´ ysledn´ a pˇ resnost synchronizace hodin H2 Stˇredn´ı Smˇerodatná Min [s] Max [s] hodnota [s] odchylka [s] 3,8e-6 1,8e-5 -4,8e-5 4,6e-5 8,8e-6 3,2e-5 -8,3e-5 9,2e-5 8,5e-6 4,2e-5 -1,1e-4 1,1e-4 -5,2e-6 2,1e-5 -3,4e-5 7,2e-5 1,2e-5 3,1e-5 -5,2e-5 8,6e-5 2,2e-5 4,3e-5 -7,1e-5 1,1e-4

Tabulka 4.4: V´ ysledky pˇresnosti synchronizace hodin H2 pˇri r˚ uzn´ ych podm´ınkách nastaven´ı s´ıtˇe


63

1000

Hodiny H1 Hodiny H2

800 600

∆t [µs]

400 200 0 −200 −400 −600 0

50

100

150 t [s]

200

250

Obrázek 4.29: Rozd´ıl ˇcasu serveru a ˇcasu hodin H1 a H2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 3 ms

400

Hodiny H1 Hodiny H2

300

∆t [µs]

200

100

0

−100

−200

0

50

100

150

200

t [s]

Obrázek 4.30: Rozd´ıl ˇcasu serveru a ˇcasu hodin H1 a H2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 10 ms a rozptylu 1 ms

64 4.3.2.3

´ ˇ ÍHO ALGORITMU KAPITOLA 4. NAVRH A SIMULACE SYNCHRONIZACN Lok´ aln´ı oscil´ ator a jeho dolad’ov´ an´ı

Dalˇs´ım d˚ uleˇzit´ ym bodem, kter´ y byl ˇreˇsen v rámci disertaˇcn´ı práce, je stabilizace a doladˇen´ı lokáln´ıho oscilátoru, kter´ y ˇr´ıd´ı jak hodiny H1 tak i hodiny H2. V pˇr´ıpadˇe jednotliv´ ych zaˇr´ızen´ı a v´ yrobk˚ u se stabilita pouˇzit´ ych oscilátor˚ u znaˇcnˇe liˇs´ı. Kvalitativnˇe vyˇsˇs´ı tˇr´ıda zaˇr´ızen´ı vyuˇz´ıvá lepˇs´ıch oscilátor˚ u, coˇz je ale vykoupeno vyˇsˇs´ı cenou celého zaˇr´ızen´ı a i u tˇechto zaˇr´ızen´ı je potˇreba urˇcité dolad’ován´ı daného oscilátoru (nucená synchronizace). Pokud má lokáln´ı oscilátor na stranˇe klienta urˇcitou odchylku (∆t), bude docházet k nepˇretrˇzitému pˇredb´ıhán´ı ˇci zpoˇzd’ován´ı hodin klienta H. Ht+1 = Ht + ∆t

(4.12)

Z pohledu synchronizaˇcn´ıho algoritmu budou m´ıt v´ ysledné korekce stále stejnou nenulovou hodnotu (bud’ stále kladnou ˇci zápornou). Synchronizaˇcn´ı algoritmus bude stále korigovat ˇcas klienta, kter´ y se bude drˇzet v urˇcitém rozmez´ı, ale v´ ysledná pˇresnost (pˇri porovnán´ı rozd´ılu ˇcasu serveru a klienta) bude horˇs´ı. Princip ˇr´ızen´ı oscilátoru je znázornˇen na obrázku 4.31, kter´ y pˇredstavuje v´ yˇrez z celkového blokového schématu na obrázku 4.13. Lokáln´ı oscilátor udává takt, kter´ y ˇr´ıd´ı jedˇ jednotliv´ notlivé hodiny a ty si na základˇe taktu poˇc´ıtaj´ı sv˚ uj vnitˇrn´ı ˇcas. Cas ych hodin je upravován jednotliv´ ymi korekcemi K2 nebo K4, které provádˇej´ı bud’ pˇriˇcten´ı nebo odeˇcten´ı malého ˇcasu (ˇra´dy mikrosekund) tak, aby doˇslo k celkovému zpˇresnˇen´ı jednotliv´ ych hodin.

Korekce K2

as

as

Lokální Hodiny H1

Lokální Hodiny H2

Takt Výstup

Generátor taktu

Lokální oscilátor

Korekce K4

Takt

PLL

Korekce K3

ˇ ast blokového schématu s oscilátorem Obrázek 4.31: C´ Lokáln´ı oscilátor b´ yvá ˇr´ızen pomoc´ı napˇet´ı a cel´ y systém pro ˇr´ızen´ı kmitoˇctu oscilátoru ˇci fáze se naz´ yvá fázov´ y závˇes (PLL - Phase Lock Loop). Teorie okolo fázov´ ych závˇes˚ u je velice d˚ ukladnˇe propracovaná [26] a existuj´ı r˚ uzné varianty ˇreˇsen´ı analogov´ ych ˇci digitáln´ıch fázov´ ych závˇes˚ u. Pro doladˇen´ı kmitoˇctu lokáln´ıho oscilátoru nám staˇc´ı základn´ı princip fázového závˇesu uvedeného na obrázku 4.32. Pokud si prom´ıtneme tento obrázek do pˇredchoz´ıho blokového schéma 4.31 pˇredstavuje blok VCO (Voltage-controlled oscillator) Lokáln´ı oscilátor, kter´ y je ˇr´ızen napˇet´ım. Frekvence f0 je v naˇsem pˇr´ıpadˇe takt, kter´ y vstupuje do jednotliv´ ych

´ ˇ Í SYNCHRONIZACE 4.3. NAVRH NA ZLEPSEN fr

Referenní kmito et

Fázový detektor

Filtr F(s)

65

VCO

fo Výstupní kmito et

Dělič kmitočtu1/N

Obrázek 4.32: Fázov´ y závˇes hodin H1 a H2. Blok dˇeliˇc kmitoˇctu nen´ı ve vˇsech pˇr´ıpadech nutn´ y a m˚ uˇze b´ yt vynechán. V´ ysledná frekvence f0 je dána vztahem 4.13. f0 = N · fr

(4.13)

D˚ uleˇzit´ ym blokem je Fázov´ y detektor, kter´ y porovnává v´ ystupn´ı kmitoˇcet s referenˇcn´ım ´ kmitoˇctem. Uprava referenˇcn´ıho kmitoˇctu mus´ı b´ yt v naˇsem pˇr´ıpadˇe ˇr´ızena na základˇe korekc´ı K3, které pˇricházej´ı na vstup obvodu PLL. Tyto korekce mohou b´ yt vyhodnocovány r˚ uznˇe a jeden z moˇzn´ ych postup˚ u, kter´ y byl vyuˇzit pˇri simulaci, je popsan´ y dále. V´ ystup z fázového detektoru procház´ı filtrem a v´ ysledná velikost napˇet´ı ˇr´ıd´ı kmitoˇcet oscilátoru. Bˇehem simulace je ˇr´ızen´ı oscilátoru zjednoduˇseno a blok PLL se také chová jako pr˚ umˇerovac´ı filtr (podkapitola 4.3.2.1). Provád´ı se dlouhodobé vyhodnocován´ı korekce K3, která udává rozd´ıl hodin H1 a H2 a následnˇe docház´ı k v´ ypoˇctu pr˚ umˇeru tˇechto dat. Simulaˇcn´ı program provád´ı pr˚ umˇerován´ı s velikost´ı okna 100 vzork˚ u. Tato hodnota je optimáln´ı vzhledem k rychlosti odezvy celého systému. V pˇr´ıpadˇe bloku PLL je potˇreba z´ıskat jednu pr˚ umˇernou hodnotu korekce k, která stanov´ı, jak´ ym smˇerem je potˇreba lokáln´ı ’ oscilátor doladit. V´ ysledná korekce k ovlivˇ nuje dolad ován´ı lokáln´ıho oscilátoru podle následuj´ıc´ıch podm´ınek (tabulka 4.5) a pˇrevodn´ı charakteristika je uvedena na obrázku ˇc´ıslo 4.33. V´ ysledná korekce [µs] k>5 5≥k>2 2≥k>1 1 ≥ k ≥ -1 -1 > k ≥ -2 -2 > k ≥ -5 -5 > k

´ Uprava oscilátoru [Hz] ∆f = −0, 05 1 k − 120 ∆f = 120 k 1 ∆f = 40 + 40 +0 1 k − 40 ∆f = 40 k 1 ∆f = 120 + 120 ∆f = +0, 05

Tabulka 4.5: Funkce doladˇen´ı oscilátoru pˇri simulaci V´ ysledná závislost u ´pravy frekvence na velikosti korekce (tabulka 4.5) byla vytvoˇrena experimentálnˇe pˇri simulac´ıch a jejich v´ ysledc´ıch. V pˇr´ıpadˇe velké korekce, která je vˇetˇs´ı

66


0.06

0.04

0.02

0

−0.02

−0.04

−0.06

−8

−6

−4

−2

0

2

4

6

8

Obrázek 4.33: Pˇrevodn´ı charakteristika doladˇen´ı oscilátoru neˇz ±5 µs je stanoven krok dolad’ován´ı na ±1/20 Hz. D˚ uvodem této limitn´ı hodnoty je poˇzadavek, aby nedoˇslo k velkému rozladˇen´ı oscilátoru napˇr´ıklad pˇri chybˇe, a proto tato hodnota nen´ı závislá na korekci k. Pokud je korekce mezi ±5 a ±1 µs, je oscilátor dolad’ován podle vztah˚ u uveden´ ych v tabulce 4.5, které jsou závislé na hodnotˇe v´ ysledné korekce k. Pokud je v´ ysledná korekce menˇs´ı neˇz 1 µs, povaˇzujeme lokáln´ı oscilátor a ˇcasy jednotliv´ ych ’ hodin za stabilizované a nedocház´ı k dalˇs´ımu dolad ován´ı oscilátoru. Simulace je realizována s oscilátorem o frekvenci 1 MHz. Na zaˇca´tku simulace byla nepˇresnost lokáln´ıho oscilátoru nastavena na +2 Hz. Tato nepˇresnost zp˚ usob´ı pˇredb´ıhán´ı hodin, coˇz zapˇr´ıˇcin´ı pˇreváˇznˇe kladnou korekci, která je zobrazena na obrázku 4.34. Z tohoto obrázku je patrné, ˇze v´ ysledné korekce hodin H2 (ˇcervená kˇrivka) je pˇreváˇznˇe nad hodnotou 0 ˇcemuˇz odpov´ıdá i stˇredn´ı hodnota 26 µs uvedená v tabulce 4.6. Tato hodnota se v´ yznamnˇe liˇs´ı oproti v´ ysledku simulace uvedené v tabulce 4.4, kdy byla fázová smyˇcka a dolad’ován´ı oscilátoru funkˇcn´ı. V pˇr´ıpadˇe funkˇcn´ıho dolad’ován´ı je stˇredn´ı hodnota odchylky ˇcasu serveru a hodin H2 3,8 µs. V pˇr´ıpadˇe funkˇcn´ıho dolad’ován´ı oscilátoru m˚ uˇzeme simulaci vidˇet na následuj´ıc´ım obrázku 4.35. Na zaˇca´tku byla odchylka nastavena o 2 Hz a následnˇe jsme sledovali schopnost zpˇetného doladˇen´ı k hodnotˇe nula, kdy je takt oscilátoru 1 MHz a kdy ˇcas hodin je poˇc´ıtán pˇresnˇe. V´ ysledek v pˇr´ıpadˇe simulace s jin´ ymi vstupn´ımi parametry je zobrazen na obrázku 4.36. Jedná se o simulaci, kde stˇredn´ı hodnota zpoˇzdˇen´ı je 3 ms a rozptyl 2 ms. Lze tedy ˇr´ıci, ˇze doladˇen´ı oscilátoru má v´ yznamn´ y vliv na celkovou pˇresnost synchronizace a to zejména na rozd´ıl stˇredn´ı hodnoty ˇcasu klienta oproti ˇcasu serveru.


67

Hodiny H1 Hodiny H2 300

∆t [µs]

200

100

0

−100

−200

50

100

150 t [s]

200

250

300

Obrázek 4.34: Rozd´ıl ˇcasu serveru a ˇcasu hodin H1 a H2 pˇri chybˇe lokáln´ıho oscilátoru o 2 Hz v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylem 1 ms

Zpoˇ zdˇ en´ı s´ıtˇ e Stˇredn´ı Rozptyl Dolad’. hodnota [s] oscilátoru 3e-3 1e-3 ne 3e-3 1e-3 ano 3e-3 2e-3 ne 3e-3 2e-3 ano

V´ ysledn´ a pˇ resnost synchronizace hodin H2 Stˇredn´ı Smˇerodatná Min [s] Max [s] hodnota [s] odchylka [s] 2,6e-5 1,7e-5 -2,2e-5 7,1e-5 3,8e-6 1,8e-5 -4,8e-5 4,6e-5 2,9e-5 2,6e-5 -2,3e-5 9,9e-5 8,8e-6 3,2e-5 -8,3e-5 9,2e-5

Tabulka 4.6: V´ ysledky pˇresnosti synchronizace hodin H2 v závislosti na doladˇen´ı oscilátoru

68


2

1.5

∆f [Hz]

1

0.5

0

−0.5

−1

0

50

100

150 t [s]

200

250

300

Obrázek 4.35: Dolad’ován´ı lokáln´ıho oscilátoru s poˇca´teˇcn´ı chybou 2 Hz v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms

2

1.5

∆f [Hz]

1

0.5

0

−0.5

−1

0

50

100

150

200

250

t [s]

Obrázek 4.36: Dolad’ován´ı lokáln´ıho oscilátoru s poˇca´teˇcn´ı chybou 2 Hz v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 2 ms

Kapitola 5 Z´ avˇ er Hlavn´ım tématem této disertaˇcn´ı práce je synchronizace ˇcasu v paketov´ ych s´ıt´ıch, a to zejména moˇznosti rozˇs´ıˇren´ı a vylepˇsen´ı stávaj´ıc´ıch metod synchronizace ˇcasu a jejich algoritm˚ u. V rámci disertaˇcn´ı práce bylo postupováno systematicky od základn´ı anal´ yzy problému pˇres jednotlivá mˇeˇren´ı parametr˚ u s´ıtˇe aˇz po modelován´ı synchronizace ˇcasu, návrhy na zlepˇsen´ı ˇcinnosti algoritmu synchronizace ˇcasu a prokázán´ı jeho u ´ˇcinnosti. Jednotlivé v´ ysledky a c´ıle disertaˇcn´ı práce jsou uvedeny dále vˇcetnˇe postupu prac´ı provádˇen´ ych bˇehem ˇreˇsen´ı disertaˇcn´ı práce.

5.1

Splnˇ en´ı c´ıl˚ u disertaˇ cn´ı pr´ ace

V této ˇca´sti jsou uvedeny v´ ysledky a zp˚ usoby dosaˇzen´ı vytyˇcen´ ych c´ıl˚ u disertaˇcn´ı práce. Na základˇe toho lze konstatovat, ˇze vytyˇcené c´ıle byly beze zbytku splnˇeny.

5.1.1

Anal´ yza a mˇ eˇ ren´ı vlivu velikosti zpoˇ zdˇ en´ı s´ıtˇ e na pˇ resnost synchronizace

Zpoˇzdˇen´ı v paketov´ ych s´ıt´ıch a hlavnˇe kol´ısán´ı zpoˇzdˇen´ı v jednotliv´ ych smˇerech pˇrenosu maj´ı zásadn´ı vliv na v´ yslednou pˇresnost synchronizace. Vˇsechny synchronizaˇcn´ı algoritmy zaloˇzené na pˇrenosu ˇcasov´ ych raz´ıtek pˇres paketovou s´ıt’ (podrobnˇe popsáno v kapitole 2) pˇredpokládaj´ı stejné zpoˇzdˇen´ı paketu v obou smˇerech pˇrenosu. Na základˇe tohoto pˇredpokladu se dá vypoˇc´ıtat odchylka ˇcasu klienta a serveru (vztah 2.4). Problémem paketov´ ych s´ıt´ı je zpoˇzdˇen´ı paket˚ u v jednotliv´ ych smˇerech, které nen´ı v obecném pˇr´ıpadˇe stejné. Proto prvn´ım c´ılem bylo analyzovat zpoˇzdˇen´ı mezi dvˇema body v s´ıti. Mˇeˇren´ı zpoˇzdˇen´ı paket˚ u v reálné s´ıti se vˇenuje kapitola 2.6.1, kde bylo provádˇeno mˇeˇren´ı ˇ napˇr´ıˇc s´ıt´ı CVUT. V´ ysledky jsou zobrazeny ve formˇe histogramu (obr. 2.10). Ze zm´ınˇeného histogramu je vidˇet rozloˇzen´ı dob zpoˇzdˇen´ı jednotliv´ ych paket˚ u. V´ ysledky tˇechto zpoˇzdˇen´ı odpov´ıdaj´ı logaritmicko-normáln´ımu rozdˇelen´ı. Tyto v´ ysledky byly oˇcekávány a potvrzuj´ı pˇredpoklad pˇri pˇrenosu paket˚ u v s´ıti. 69

70

´ ER ˇ KAPITOLA 5. ZAV

Dále bylo provedeno mˇeˇren´ı pˇri pouˇzit´ı synchronizaˇcn´ıho protokolu PTP (kapitola 2.3), kter´ y disponuje hardwarov´ ym vylepˇsen´ım pro pˇresné urˇcen´ı pˇr´ıchodu synchronizaˇcn´ıch paket˚ u. Protokol PTP je urˇcen pro menˇs´ı s´ıtˇe a v nich dosahuje vysoké pˇresnosti synchronizace. Jednotlivé s´ıt’ové prvky mus´ı m´ıt implementovánu hardwarovou podporu tohoto protokolu, a proto c´ılem vybran´ ych mˇeˇren´ı bylo vyhodnocen´ı vlivu standardn´ıch ’ s´ıt ov´ ych prvk˚ u na v´ yslednou pˇresnost synchronizace. Mˇeˇren´ı na r˚ uzn´ ych topologi´ıch s´ıtˇe jsou popsána v kapitole 2.6.2. V´ ysledná pˇresnost synchronizace (rozd´ıl ˇcasu klienta od ˇcasu serveru) pro jednotlivá mˇeˇren´ı je pˇrehlednˇe shrnuta v tabulce 2.1. V pˇr´ıpadˇe vyuˇzit´ı s´ıt’ov´ ych zaˇr´ızen´ı bez hardwarové podpory synchronizaˇcn´ıho protokolu PTP klesne pˇresnost synchronizace z des´ıtek nanosekund aˇz na stovky nanosekund ˇci jednotky mikrosekund.

5.1.2

Simulaˇ cn´ı program s aktu´ aln´ım stavem a funkc´ı synchronizaˇ cn´ıho algoritmu

C´ılem bylo nasimulovat reáln´ y stav, tak jak je dnes protokol pro synchronizaci ˇcasu v paketov´ ych s´ıt´ıch pouˇz´ıván. Jelikoˇz dnes existuje nˇekolik r˚ uzn´ ych protokol˚ u (kapitola 2), tak nebylo moˇzné implementovat a simulovat vˇsechny vlastnosti jednotliv´ ych protokol˚ u, a proto se simulace zamˇeˇruj´ı na spoleˇcné vlastnosti vypl´ yvaj´ıc´ı z podstaty pˇrenosu paket˚ u v paketové s´ıti. Základn´ı princip a pˇrenos ˇcasov´ ych znaˇcek v jednotliv´ ych paketech je pro vˇsechny synchronizaˇcn´ı protokoly stejn´ y. Základn´ı simulace, popsaná v kapitole 4.1, vycház´ı ze znalosti fungován´ı synchronizaˇcn´ıho algoritmu. Strana klienta provád´ı v´ ypoˇcet korekce ˇcasu lokáln´ıch hodin na základˇe pˇrijat´ ych ˇcasov´ ych znaˇcek. Jednotlivé korekce jsou zpracovány algoritmem, kter´ y provád´ı pr˚ umˇerován´ı hodnot jednotliv´ ych korekc´ı a v´ ysledkem je korekce K2 pro lokáln´ı hodiny klienta. Tento cyklus se stále opakuje a u ´ˇcelem je co nejvˇetˇs´ı zpˇresnˇen´ı ˇcasu lokáln´ıch hodin klienta. Hlavn´ım promˇenn´ ym parametrem pˇri simulaci je promˇenná doba zpoˇzdˇen´ı pˇrenosu paket˚ u v s´ıti Ethernet. Byl zkoumán vliv nastaven´ı zpoˇzdˇen´ı v jednotliv´ ych smˇerech pˇrenosu na celkovou pˇresnost synchronizace ˇcasu na stranˇe klienta. V´ ysledky pro jednotlivé simulace jsou pˇrehlednˇe zobrazeny v tabulce 4.1. Tyto v´ ysledky byly porovnány s v´ ysledky zjiˇstˇen´ ymi pˇri mˇeˇren´ı v reálné s´ıti popsan´ ymi v kapitole 4.2. Pˇri mˇeˇren´ı bylo vyuˇzito s´ıt’ového emulátoru, kter´ y byl pˇripojen mezi synchronizaˇcn´ım serverem a klientem. V´ ysledná pˇresnost synchronizace ˇcasu pˇri mˇeˇren´ı v reálné s´ıti s emulátorem byla o ˇra´d niˇzˇs´ı neˇz v pˇr´ıpadˇe simulac´ı.

5.1.3

Sn´ıˇ zen´ı vlivu kol´ıs´ an´ı zpoˇ zdˇ en´ı na pˇ resnost synchronizace a zv´ yˇ sen´ı pˇ resnosti synchronizace

Za u ´ˇcelem vylepˇsen´ı synchronizaˇcn´ıho algoritmu byly zkoumány moˇznosti zv´ yˇsen´ı pˇresnosti synchronizace ˇcasu a generován´ı taktu v závislosti na kol´ısán´ı zpoˇzdˇen´ı jednotliv´ ych paket˚ u. Prvn´ı vylepˇsen´ı spoˇc´ıvá v anal´ yze a návrhu filtru (kapitola 4.3.1), kter´ y

ˇ Í PRO PRAXI A BUDOUCÍ PRACE ´ 5.2. VYUZIT

71

zajiˇst’uje filtraci korekc´ı vypoˇc´ıtan´ ych na základˇe ˇcas˚ u pˇrenáˇsen´ ych v jednotliv´ ych paketech. Pro dalˇs´ı vylepˇsen´ı stability a pˇresnosti synchronizace ˇcasu a generován´ı pˇresného taktu byl navrˇzen systém dvou lokáln´ıch hodin a systém zpˇetného dolad’ován´ı lokáln´ıho oscilátoru (kapitola 4.3.2.3). Tento systém má v´ yznamn´ y vliv na zamezen´ı krátkodob´ ych v´ ykyv˚ ua ’ zajiˇst uje dlouhodobou stabilitu generován´ı taktu. Jednotlivá vylepˇsen´ı jsou implementována do simulaˇcn´ıho programu (kapitola 4.3), kter´ y byl dalˇs´ım c´ılem této disertaˇcn´ı práce,jak je uvedeno dále.

5.1.4

Vytvoˇ ren´ı simulaˇ cn´ıho programu s vylepˇ senou synchronizac´ı

Hlavn´ım u ´kolem této disertaˇcn´ı práce bylo zkoumat moˇznosti vylepˇsen´ı pˇresnosti synchronizace hodin na stranˇe klienta s návaznost´ı na generován´ı pˇresného taktu klientem. Bylo postupnˇe vytvoˇreno a testováno nˇekolik postup˚ u, které vedly k vytvoˇren´ı konceptu vyuˇz´ıvaj´ıc´ıho dvou lokáln´ıch hodin. Popis a ˇreˇsen´ı problému je detailnˇe rozebráno v kapitole 4.3 a hlavn´ı blokové schéma systému na stranˇe klienta je uvedeno na obrázku 4.13. Hlavn´ı princip vylepˇsen´ı spoˇc´ıvá v pˇridán´ı druh´ ych lokáln´ıch hodin H2, které jsou dolad’ovány smyˇckou s pr˚ umˇerován´ım odchylky ˇcasu, a dále zaveden´ı zpˇetné vazby na doladˇen´ı lokáln´ıho oscilátoru, kter´ y udává takt pro lokáln´ı hodiny H1, H2 a zároveˇ n slouˇz´ı pro generován´ı extern´ıho taktu pro pˇr´ıpadná dalˇs´ı zaˇr´ızen´ı. V´ ysledky simulac´ı jsou uvedeny v kapitole 4.3 vˇcetnˇe porovnán´ı pˇresnost´ı vnitˇrn´ıch hodin H1 a H2 pˇri simulaci se stˇredn´ı hodnotou zpoˇzdˇen´ı v s´ıti 3 ms a rozptylem 1 ms (obrázek 5.1, 4.28). V pˇr´ıpadˇe porovnán´ı pˇresnosti hodin H1 a H2 na stranˇe klienta je patrn´ y rozd´ıl pˇribliˇznˇe o jeden ˇra´d, pˇriˇcemˇz hodiny H2 vykazuj´ı vyˇsˇs´ı stabilitu (obrázek 5.1). V´ ysledky simulac´ı potvrdily pˇredpoklad, ˇze v´ ysledná pˇresnost ˇcasu hodin H2 dosahuje vyˇsˇs´ı stability oproti hodinám H1. Jak uˇz bylo ˇreˇceno dˇr´ıve, stˇredn´ı hodnota zpoˇzdˇen´ı nemá zásadn´ı vliv na v´ yslednou pˇresnost synchronizace, coˇz je názornˇe vidˇet jak v tabulkách 4.3 a 4.4, tak i v pˇr´ıpadˇe porovnán´ı graf˚ u v kapitole 4.3.2.2. Dalˇs´ı vliv na v´ yslednou pˇresnost synchronizace má stabilita a dolad’ován´ı lokáln´ıho oscilátoru. Lokáln´ı oscilátor udává takt pro lokáln´ı hodiny H1, H2 a pro generátor extern´ıho taktu. Problematika doladˇen´ı je ˇreˇsena v kapitole 4.3.2.3. Doladˇen´ı oscilátoru má v´ yznamn´ y vliv na celkovou pˇresnost synchronizace.

5.2

Vyuˇ zit´ı pro praxi a budouc´ı pr´ ace

Tato disertaˇcn´ı práce byla vypracována na u ´rovni teorie a simulac´ı, které vycházej´ı z reáln´ ych namˇeˇren´ ych dat. Dalˇs´ım u ´kolem by mˇela b´ yt implementace navrˇzen´ ych vylepˇsen´ı do reálného zaˇr´ızen´ı klienta, aby bylo moˇzné experimentálnˇe ovˇeˇrit oˇcekávané v´ ysledky. Mˇelo by doj´ıt k vylepˇsen´ı pˇresnosti synchronizace tak, jak bylo ukázáno v simulac´ıch. Dalˇs´ı moˇznou oblast´ı v´ yzkumu je vyuˇzit´ı adaptivn´ıch filtr˚ u, které mohou ovlivnit v´ yslednou pˇresnost synchronizace ˇcasu a stabilitu ˇcasu klienta.

´ ER ˇ KAPITOLA 5. ZAV

72

5000 Hodiny H1 Hodiny H2

4500 4000 3500

ˇ Cetnost

3000 2500 2000 1500 1000 500 0 −250

−200

−150

−100

−50 0 ∆t [µs]

50

100

150

200

250

Obrázek 5.1: Histogram ˇcetnost´ı rozd´ılu ˇcasu serveru a ˇcasu hodin H1 a H2 v pˇr´ıpadˇe stˇredn´ı hodnoty zpoˇzdˇen´ı 3 ms a rozptylu 1 ms

Literatura [1] RFC 1305, Network Time Protocol (Version 3), 1992. [2] RFC 2030, Simple Network Time Protocol (SNTP) Version 4, 1996. [3] Recommendation ITU–T G.813, Timing characteristics of SDH equipment slave clocks (SEC), 2003. [4] IEEE 802.3, Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 2005. [5] Recommendation ITU–T G.8261, Timing and synchronization aspects in packet networks, 2006. [6] IEEE 1588, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, 2008. [7] Recommendation ITU–T G.8264, Distribution of timing information through packet networks, 2008. [8] Recommendation ITU–T G.8262, Timing characteristics of a synchronous Ethernet equipment slave clock (EEC), 2010. [9] Server lantime m600/gps/ptp. [online], 2012. Dostupn´ y z WWW: . [10] Simena network emulator. [online], 2012. Dostupn´ y z WWW: . [11] J. Balátˇe. Automatické ˇr´ızen´ı. BEN, 2003, 663 s, ISBN 80-7300-020-2. [12] S. Bregni. Synchronization of Digital telecommunications Networks. Wiley, 2002. [13] J. Burch, K. Green, J. Nakulski, and D. Vook. Verifying the performance of transparent clocks in ptp systems. In Precision Clock Synchronization for Measurement, Control and Communication, 2009. ISPCS 2009. International Symposium on, pages 1 –6, oct. 2009. 73

74

LITERATURA

[14] J. C. Eidson. Measurement, Control and Communication Using IEEE1588. Springer, 2006. [15] D. Fontanelli and D. Macii. Accurate time synchronization in ptp-based industrial networks with long linear paths. In Precision Clock Synchronization for Measurement Control and Communication (ISPCS), 2010 International IEEE Symposium on, pages 97–102, Sept 2010. [16] G. M. Garner, M. Ouellette, and M. J. Teener. Using an ieee 802.1as network as a distributed ieee 1588 boundary, ordinary, or transparent clock. In Precision Clock Synchronization for Measurement Control and Communication (ISPCS), 2010 International IEEE Symposium on, pages 109–115, 2010. [17] J. Han and D. Jeong. A practical implementation of ieee 1588-2008 transparent clock for distributed measurement and control systems. Instrumentation and Measurement, IEEE Transactions on, 59(2):433–439, 2010. [18] P. Jareˇs and J. Vodráˇzka. Modelling of data stream time characteristics for use of inverse multiplexer. Advances in Electrical and Electronic Engineering, 12(4), 2014. ˇ a tech[19] D. Jaruˇsková. Pravdˇepodobnost a matematick´ a statistika. Vyd. 2. Praha: Cesk´ ˇ nika - nakladatelstv´ı CVUT, 2006. 138 s. ISBN 80-01-03427-5. [20] T. Kovacshazy and B. Ferencz. Performance evaluation of ptpd, a ieee 1588 implementation, on the x86 linux platform for typical application scenarios. In Instrumentation and Measurement Technology Conference (I2MTC), 2012 IEEE International, pages 2548 –2552, may 2012. [21] Q. Mingzhu, W. Xiaoli, and Y. Zhiqiang. Design and implementation of ieee1588 time synchronization messages timestamping based on fpga. In Electric Utility Deregulation and Restructuring and Power Technologies (DRPT), 2011 4th International Conference on, pages 1566 –1570, july 2011. [22] C. D. Murta, P. R. Torres, and P. Mohapatra. Qrpp1-4: Characterizing quality of time and topology in a time synchronization network. In Global Telecommunications Conference, 2006. GLOBECOM ’06. IEEE, pages 1 –5, 27 2006-dec. 1 2006. [23] T. Neagoe, V. Cristea, and L. Banica. Ntp versus ptp in computer networks clock synchronization. In Industrial Electronics, 2006 IEEE International Symposium on, volume 1, pages 317 –362, july 2006. ˇ [24] M. Pravda. Simulaˇcn´ı model obnovy synchronizace z paket˚ u. Master’s thesis, CVUT, FEL, Katedra telekomunikaˇcn´ı techniky, Praha, 2008. [25] R. L. Scheiterer, N. Chongning, D. Obradovic, G. Steindl, and F. J. Goetz. 1 microsecond-conform line length of the transparent clock mechanism defined by the

LITERATURA

75

precision time protocol (ptp version 2). In Precision Clock Synchronization for Measurement, Control and Communication, 2008. ISPCS 2008. IEEE International Symposium on, pages 92–97, 2008. [26] J. L. Stensby. Phase-Locked Loops: Theory and Applications. CRC Press, 1997, 400 s, ISBN: 0849394716,. [27] J. Vodrazka and P. Lafata. Transmission delay modeling of packet communication over digital subscriber line. Advances in Electrical and Electronic Engineering, 11(4), 2013. [28] H. Weibel. High precision clock synchronization according to ieee 1588 implementation and performance issues. Dostupn´ y z WWW: http://www.engineering.zhaw.ch/fileadmin/user upload/engineering/ Institute und Zentren/INES/Documents/IEE1588/embedded World 05 Contribution final 02.pdf, 2005. [29] F. Zezulka. Synchronizace v distribuovan´ ych ˇr´ıdic´ıch systémech: Precision time protocol (ptp) podle ieee 1588. In Automa. – ISSN 1210-9592., pages 17–19, u ńor 2010. ˇ [30] P. Z´ıtek, M. Hofreiter, and J. Hlava. Automatické ˇr´ızen´ı. Vyd. 3. Praha: CVUT, 2004. 148 s. ISBN 80-01-03020-2.

76

LITERATURA

Publikace autora Publikace vztahuj´ıc´ı se k t´ ematu disertaˇ cn´ı pr´ ace Spoluautorsk´ y pod´ıl je u vˇsech publikac´ı stejn´ y.

Publikace v recenzovan´ ych ˇ casopisech [A1]

[A2]

[A3]

[A4]

Pravda, M. - Vodráˇzka, J. Designing of Method for Improving Synchronization Accuracy in Packet Networks In: International Journal of Emerging Technologies in Computational and Applied Sciences (IJETCAS). 2013, vol. 3, p. 244-249. Available from WWW: ISSN 22790055. Pod´ıl doktoranda 50% Pravda, M. - Lafata, P. - Vodráˇzka, J. Time Synchronization in Packet Networks and Influence of Network Devices on Synchronization Accuracy In: Elektrorevue. 2010, vol. 13, no. 2010/84, p. 84-1-84-6. Available from WWW: ISSN 1213-1539. Pod´ıl doktoranda 33% Pravda, M. Protokoly k synchronizaci ˇcasu pro paketovou s´ıt’ In: Access server. 2008, roˇc. 6., ˇc. 2008100001, s. 1-6. Dostupn´ y z WWW: ISSN 1214-9675. Pod´ıl doktoranda 100% Pravda, M. Synchronizaˇcn´ı jednotka pro paketovou s´ıt’ In: Access server. 2008, roˇc. 6., ˇc. 2008100004, s. 1-5. Dostupn´ y z WWW: . ISSN 1214-9675. Pod´ıl doktoranda 100%

Publikace ve sborn´ıc´ıch konferenc´ı evidovan´ ych ve Web of science [A5]

Pravda, M. - Lafata, P. - Vodráˇzka, J. Precise Time Protocol in Ethernet over SDH Network In: 34th International Conference on Telecommunications and Signal Processing. Brno: VUT v Brnˇe, FEKT, 2011, p. 170-174. ISBN 978-1-4577-1409-2. Pod´ıl doktoranda 33% 77

78

LITERATURA [A6]

[A7]

[A8]

Pravda, M. - Vodráˇzka, J. - Lafata, P. Simulations and Measurements of Packet Network Synchronization by Precision Time Protocol In: 35th International Conference Telecommunications and Signal Processing. Brno: Vysoké uˇcen´ı technické v Brnˇe, Fakulta elektrotechniky a komunikaˇcn´ıch technologi´ı, 2012, art. no. 0203, p. 116-120. ISBN 978-1-4673-1118-2. Pod´ıl doktoranda 33% Pravda, M. - Kocur, Z. Time Synchronization through Network Time Protocol and Improvement of Its Accuracy In: TSP - 32nd International Conference on Telecommunications and Signal Processing. Budapest: Asszisztencia Szervez˝o Kft., 2009, ISBN 978-963-06-7716-5. Pod´ıl doktoranda 50% Pravda, M. - Lafata, P. - Vodráˇzka, J. Precision Clock Synchronization Protocol and Its Implementation into Laboratory Ethernet Network In: TSP 2010 - 33rd International Conference on Telecommunications and Signal Processing. Budapest: Asszisztencia Szervez˝o Kft., 2010, p. 286-291. ISBN 978-963-88981-0-4. Pod´ıl doktoranda 33%

Publikace ve sborn´ıc´ıch mezin´ arodn´ıch konferenc´ı [A9]

Kocur, Z. - Pravda, M. - Vodráˇzka, J. Enhancement Ethernet Network ˇ ˇ e, 2009, vol. 1, Emulator In: Digital Technologies 2009. Zilina: TU v Zilinˇ ISBN 978-80-554-0150-8. Pod´ıl doktoranda 33%

Ostatn´ı publikace [A10]

Pravda, M. Transmission of Synchronization across Packet Network. In: ˇ e vysoké uˇcen´ı technické v Praze, 2010, p. 132Workshop 2010. Praha: Cesk´ 133. ISBN 978-80-01-04513-8. Pod´ıl doktoranda 100%

Publikace nevztahuj´ıc´ı se k t´ ematu disertaˇ cn´ı pr´ ace Skripta [A11]

ˇ a Lafata, P. - Hampl, P. - Pravda, M. Digitáln´ı technika 1. vyd. Praha: Cesk´ ˇ technika - nakladatelstv´ı CVUT, 2011. 164 s. ISBN 978-80-01-04914-3. Pod´ıl doktoranda 33%

Publikace ve sborn´ıc´ıch konferenc´ı evidovan´ ych ve Web of science [A12]

Lafata, P. - Pravda, M. Analyzing and Modeling of Far-End Crosstalk in Twisted Multi-Pair Metallic Cables In: 2011 International Conference on Applied Electronics. Plzeˇ n: Západoˇceská univerzita v Plzni, 2011, p. 223226. ISSN 1803-7232. ISBN 978-80-7043-987-6. Pod´ıl doktoranda 50%

LITERATURA [A13]

[A14]

Pravda, M. - Zavrtálek, J. - Nemˇc´ık, M. Voice Transmission Quality Testing and the Design of Measuring Unit In: TSP 2010 - 33rd International Conference on Telecommunications and Signal Processing. Budapest: Asszisztencia Szervez˝o Kft., 2010, p. 397-401. ISBN 978-963-88981-0-4. Pod´ıl doktoranda 33% Pravda, M. - Nemˇc´ık, M. Voice Transmission Quality Tester In: Applied Electronic 2010. Pilsen: University of West Bohemia, 2010, p. 277-280. ISSN 1803-7232. ISBN 978-80-7043-865-7. Pod´ıl doktoranda 50%

Ostatn´ı publikace [A15]

Nemˇc´ık, M. - Pravda, M. - Vodráˇzka, J. Mˇeˇriˇc kvality pˇrenosu ˇreˇci In: Access server. 2010, roˇc. 8, ˇc. 1, s. 1-4. Dostupn´ y z WWW: ISSN 1214-9675. Pod´ıl doktoranda 33%

Funkˇ cn´ı vzorky [A16] [A17] [A18]

Pravda, M. Synchronizaˇcn´ı jednotka pro paketovou s´ıt’ [Funkˇcn´ı vzorek]. 2008. Vlastn´ık: STROM telecom s.r.o. Nemˇc´ık, M. - Pravda, M. Mˇeˇriˇc kvality pˇrenosu ˇreˇci [Funkˇcn´ı vzorek]. 2009. ˇ Vlastn´ık: CVUT FEL Pravda, M. - Vodráˇzka, J. - Zavrtálek, J. Mˇeˇriˇc kvality hovoru (VTQ tester) ˇ [Funkˇcn´ı vzorek]. 2010. Vlastn´ık: CVUT FEL

Projekty [A19]

[A20]

[A21]

[A22]

ˇ Intern´ı grant CVUT CTU0904113 - Pravda, M. Pˇrenos synchronizace pˇres paketovou s´ıt’ Fakulta elektrotechnická, katedra telekomunikaˇcn´ı techniky, 2009 ˇ Intern´ı grant CVUT SGS10/182/OHK3/2T/13 - Pravda, M. Metody mˇeˇren´ı kvality pˇrenosu ˇreˇci v r˚ uzn´ ych typech s´ıt´ı a moˇzné zp˚ usoby synchronizace Fakulta elektrotechnická, katedra telekomunikaˇcn´ı techniky, 2010 ˇ Projekt G1 830 - Pravda, M. Implementace nov´ FRVS ych technologi´ı a pom˚ ucek do laboratorn´ı v´ yuky pˇredmˇetu Pˇrenosové systémy Fakulta elektrotechnická, katedra telekomunikaˇcn´ı techniky, 2010 ˇ Projekt G1 2211 - Pravda, M. Vytvoˇren´ı nov´ FRVS ych v´ yukov´ ych materiál˚ u a pom˚ ucek do laboratorn´ı v´ yuky pˇredmˇetu Digitáln´ı technika Fakulta elektrotechnická, katedra telekomunikaˇcn´ı techniky, 2011

79

Fakulta elektrotechnická Katedra telekomunikační techniky

Recommend Documents