shrnutí na jaře 2023
Cílem tohoto textu je oprášit téma IEEE1588 = PTP ve světle některých našich (FCCPS) aktuálních zkušeností.
Píše se rok 2023 a PTP nadále zůstává "téměř na dosah ruky" :-)
Díky nadšení některých zákazníků se blíží kulminace testovacích projektů a připravují se některá masovější ostrá nasazení.
Disclaimer: Autor tohoto textu je dlouholetým prodejcem a příznivcem hardwaru Meinberg.
Stručně zrekapitulujme:
Původní IEEE1588-2002 = PTP v1 bylo převážně proprietárním dítkem
několika úhlavních výrobců. Switche s podporou fungovaly v režimu
Boundary Clock, neznámým pojmem byl Transparent Clock.
S využitím PTP v1 vznikla první generace produktů pro reálné nasazení,
dostavily se důležité zkušenosti a rozběhly se práce na standardizaci
PTP ve verzi 2.
IEEE1588-2008 = PTP v2 vznikalo zřejmě v podstatně širším a pestřejším
kolektivu a přineslo mnohé technické novinky - především již zmíněný
režim Transparent Clock, a prakticky povinnou podporu ve switchích.
(Přinejmenším zpočátku to tak vypadalo, povinná podpora později poněkud změkla.)
Jednalo se o první "liberální" a otevřenou verzi, k jejíž podpoře
se přihlásilo větší množství výrobců hardwaru.
Součástí standardu byla nyní paleta volitelných atributů / kolmých dimenzí
konfigurace fungování protokolu:
Hlavní část konfigurace PTP pro kartu Meinberg HPS100
Zřejmě teprve následně, po uveřejnění IEEE1588-2008, začaly vznikat profily.
Motivací bylo, že žádná implementace PTP stacku reálně neuměla všechno,
všechny kombinace uvedených navzájem kolmých dimenzí - a ani to nebylo potřeba,
a technicky by to v některých případech nedávalo moc smysl.
Stejně už pomalu krystalizovaly jakési "oborově specifické" konfigurace.
Mělo tedy smysl, bavit se u konkrétního zařízení o kompatibilitě
s konkrétním standardizovaným profilem.
První vznikl asi "power profile", nedlouho po něm "telecom profile",
svoje si přisadili přátelé z oboru studiové techniky a televizního vysílání,
další profil je výrazně ovlivněn automobilní palubní technikou atd.
Momentálně máme nejméně 3 varianty Power profilu, 3 varianty Telecom profilu,
2 varianty "broadcast" profilu atd. Ne všechny profily jsou podmnožinou
výše uvedených standardních "dimenzí", některé vyžadují speciální vlastnosti
hardwaru mimo rámec IEEE1588 (802.1AS, White Rabbit).
Na webu IEEE je k dispozici k nahlédnutí seznam profilů.
Profily PTP podporované kartou Meinberg HPS100
Zhruba po další dekádě bylo zřejmé, že uplynulo poměrně dost
vody pod mostem. Bujení profilů a požadavky na další, nové inovace
vedly komunitu ke kodifikaci nové revize - dostala jméno
IEEE1588-2019, a byla oficiálně vydána v červnu 2020.
Tentokrát nebylo účelem, radikálně se odstřihnout od stávající normy
(z roku 2008) - cílem bylo, přijmout pod křídla kanonické normy
některé rozumné úpravy a zajímavé inovace z jednotlivých profilů,
které si už pár let rostly po svém jako polní kvítí.
Nová revize například přivítala do rodiny další poněkud
nekanonický profile zvaný White Rabbit. Tuším se v časové tísni
na poslední chvíli do revize 2019 nedostala volitelná podpora
PTP Authentication TLV (podpis).
Přestože se tentokrát nejednalo o revoluci, bylo možno pozorovat
zajímavé okrajové efekty - například když asi nejdůležitější
open-source PTP stack "linuxptp" (obsahující démona ptp4l)
zvedl verzi protokolu deklarovanou v hlavičce paketů z 2.0
na 2.1, a přestal fungovat proti uzlům, které nadále deklarují verzi 2.0.
Např. Meinberg :-) Stačí v dotyčném zdrojovém souboru ptp4l
vrátit číslo verze na 2.0, a všechno dál funguje...
Určitý vývoj probíhá v oblasti BMCA algoritmů.
(Konkrétní varianta BMCA se obecně váže ke konkrétnímu profilu.)
Například zřejmě padne tradiční dogma, že konkrétní slave se drží
konkrétního mastera podle "shůry daných" metrik, a sám se nesnaží
autonomně hodnotit jitter a další statistiky více masterů
podle svého.
Výhledově se zdá, že bude implementována podpora na straně slava
pro simultánní závěs na více grandmasterů, případně vedle primárního
závěsu ještě jeden či více dalších, právě aby bylo možno "po svém"
měřit jitter více upstream zdrojů a na základě tohoto svého měření
se rozhodovat, kterého upstream GM se chytit. Podobně, jako to odedávna
dělá NTP - ovšem v případě PTP o pár řádů přesněji.
Další "poněkud nekanonickou" vlastností, která byla přijata pod
křídla IEEE1588-2019, je Synchronous Ethernet (SyncE) - resp. volněji
formulovaná podpora pro "physical layer syntonization".
SyncE v principu nepředstavuje nic složitého - je třeba především zařídit,
aby hodiny framingu na Ethernetu běžely synchronně podle vnější reference
a byly využitelné jako reference pro slava. K tomu je potřeba vstup
reference do PHY na masteru a výstup z PHY na straně slava.
Je vhodné, aby pro toto byla podpora ve PHY čipech, ale zřejmě to lze
v krajním případě naroubovat i na standardní Ethernet PHY transceivery.
Slave tak jako tak provádí "clock recovery" a hodiny na Ethernetu
jsou tak jako tak isochronní, do isochronního SERDES bitstreamu
se vkládají "vycpávkové" rámce... tzn. kódování fyzické vrstvy
je snadno využitelné pro fázový závěs na straně slava.
Vedle syntonizace hodin fyzické vrstvy specifikuje SyncE ještě
přenos režijních rámců pro signalizaci jakosti a případně dohadování,
kdo je SyncE master a kdo SyncE slave.
Popravdě protokolový stack PTP a relace SyncE mohou běžet na sobě
navzájem nezávisle - např. u výrobce Meinberg na straně slava
může SyncE figurovat v MRS kaskádě dle dalších okolností
buď jako samostatný zdroj upstream reference,
nebo zkombinovaný s příjmem PTP...
Pokud mluvíme o evoluci IEEE1588, stojí za zmínku pravidelný dýchánek
všech přátel časomíry a zejména PTP zvaný ISPCS
= International IEEE Symposium on Precision Clock Synchronization for Measurement, Control & Communication.
Jedná se o každoroční konferenci spojenou s malou výstavkou a nemalým plugfestem,
trvající několik málo dnů (momentálně vidím 5, tuším to bývalo méně).
Akce se koná zjevně pod záštitou IEEE. Ročník 2016 se konal v Praze.
Ohledně historie toho není mnoho k nalezení - asi nejstarší zmínkou je záznam o
ISPCS 2007
na web.archive.org, kde jsou jako sponzoři zmiňováni IEEE, NIST a Rakouská akademie věd (sídlem ve Vídni).
Archivovaná webová stránka nesla copyright právě Rakouské akademie věd :-) což je zajímavé
- právě v Rakousku ve Vídni sídlí firma Oregano Systems
(před pár lety přátelsky převzatá firmou Meinberg), která dlouhá léta vyvíjí
mj. PTP stack v podobě "intellectual propterty core" pro FPGA,
kteroužto součástku právě výrobce Meinberg dlouhá léta používá jako
základní kámen svých flexibilních a výkonných PTP grandmasterů...
To byly zřejmě relativně pionýrské začátky. Už mnoho let se na pozici čelných sponzorů
ISPCS střídají největší výrobci "časoměrného hardwaru", mezi nimi Meinberg a úhlavní konkurenti,
a registrovaní řečníci přicházejí jednak od těchto a dalších velkých výrobců (boxů a křemíku),
jednak z akademické sféry po celém světě.
Aktuálně lze u Meinbergů v konfiguraci pozorovat profily zvané
např. "Default IEEE1588-2008 P2P" a "Default IEEE1588-2008 E2E".
Mají relativně velkou množinu dalších parametrů ponechánu volně
konfigurovatelnou. Také je k dispozici profile "custom" (IMS)
nebo "none" (microSync).
Výše uvedené "profily" jsou dost možná Meinbergovic proprietární
šablony. Dále ve zkratce zmíníme konkrétní standardizované profily PTP,
které jsou specifikovány všelijakými oborově-specifickými normami.
Podrobnosti nad rámec tohoto textu rádi vysvětlíme svým zákazníkům v rámci technické podpory nebo školení.
Mezi prvními profily, o kterých se začalo mluvit v mezích IEEE1588-2008
byl Power Profile.
Původně byl označován takto prostě, později se rozbujel
do několika variant: C37.238-2011, C37.238-2017 a IEC 61850-9-3 (2016).
C37.238 je dnes označován jako norma IEEE, osobně dle názvu normy
bych čekal spíš IEC... to je asi jedno, různé normotvorné asociace
od sebe normy rády navzájem přebírají.
Základními vlastnostmi Power Profilu jsou L2 multicast P2P, switche povinně TC. V zásadě tento profil shrnuje většinu tehdejších novinek/vymožeností PTP v2 z roku 2008.
Varianta C37.238-2011 měla povinně VLAN tag.
Varianta C37.238-2017 je by default bez VLAN tagu,
ale má povinně Organization Extension TLV a volitelně Alternative Timezone TLV.
Varianta IEC 61850-9-3 nemá VLAN tag ani povinné TLV "přílohy".
Zpočátku dogmatický postoj PTP komunity, že odteď budiž podpora ve switchích povinná, zřejmě vzal poměrně rychle zasvé. Během několika let vznikly pod záštitou ITU dosud tři varianty "telecom profiles" známé jako G.8265.1, G.8275.1 a G.8275.2.
Zatímco například G.8275.1 vyžaduje podporu ve switchích a dokonce SyncE, G.8275.2 hovoří teoreticky o "partial on-path support", reálně je ochoten fungovat i na sítích zcela bez HW podpory (korekcí) PTP provozu. Dosažená přesnost samozřejmě odpovídá parametrům poskytnuté přenosové sítě. Ve finále pro potřeby nasazení rozhoduje, zda parametry dosažitelné na konkrétní trase/síti vyhovují "potřebám daného nasazení".
Charakteristickým prvkem G.8275.2 je "lucky packet algorithm" = vysoká četnost časoměrných zpráv, ze kterých je vyselektován malý zlomek "transakcí", které měly nejkratší přenosové zpoždění.
Společným jmenovatelem Telecom Profiles je L3 unicast E2E. Podpora ve switchích se očekává možná spíš BC než TC.
V oblasti studiové techniky se tradičně používají "diskrétní" synchronizační signály cca BlackBurst (video) a WordClock (audio). Dále DVB technologie potřebuje 1PPS + 10 MHz. Toto vše je samozřejmě k dispozici jako výstupy ústředen Meinberg, ale tématem tohoto textu je PTP.
V souvislosti s postupným přechodem na TCP/IP (a Ethernet) je protokol už několik let zmiňován také ve studiové technice. A vznikly nejméně dva relevantní profily: SMPTE ST 2059-2 a AES67 Media.
V konfiguraci zařízení Meinberg je možno v případě ST 2059-2 volit P2P nebo E2E, transport L2 nebo L3, adresaci multicast nebo unicast nebo hybrid. Poměrně pestrá je také vedlejší "profile-specific" konfigurace, kde lze volit například základní snímkový kmitočet studia nebo "daily jam time"... Konfigurace AES67 je chudší zhruba o profile-specific atributy a také enkapsulace je pouze nad L3.
Time Sensitive Networking je název jedné pracovní skupiny IEEE, a také se tak označuje soubor protokolů na Ethernetu, které se této oblasti týkají. Jeden z nich je IEEE1588, pro který má TSN svůj vlastní profile: 802.1AS.
Profile 802.1AS je "svůj". K původnímu PTP přidává některá rozšíření, a v té souvislosti norma 802.1AS hovoří o gPTP. Další normy z rodiny TSN se týkají především traffic shapingu na ethernetové síti, garancí latence a šířky pásma. Toto vše striktně nevybočuje ze standardního Eth framingu na lince, ale vyžaduje určitou podporu navíc v čipsetu switche (pokročilý queueing). Nezdá se, že by TSN uzákonilo "preempci paketu v průběhu jeho odesílání".
White Rabbit je profile protokolu PTP vzešlý z CERNu.
Smyslem jeho existence je maximální rozlišení a přesnost časování,
hluboko pod 1 ns.
White Rabbit tohoto dosahuje kombinací několika standardních
vlastností (každý switch je povinně PTP-aware, a to v režimu BC, atd.)
a kvůli němu přibyly do normy IEEE1588 některé finesy, jako je SyncE,
oficiálně posvěcená manuální kalibrace asymetrií (offsetů)
či provoz bez BMCA. Charakteristickým prvkem je také speciální
patentovaná konstrukce fázového komparátoru, jehož vlastnostmi
je právě dáno dosažitelné rozlišení.
Firma Meinberg podporu profilu White Rabbit nemá a neplánuje, především protože externí GM do stávajícího sortimentu WR hardwaru koncepčně nezapadá. Každý WR switch totiž umí fungovat jako GM.
Firma Meinberg uvedla první modely svého hardwaru pro PTPv2
nedlouho po jeho standardizaci v roce 2008.
První generace PTP grandmasteru Meinberg se prodávala
jako factory option v šasi LanTime M600 - před několika
lety se přestala vyrábět, především pro morální věkovitost.
Následovala inovovaná druhá generace již pro IMS šasi (TSU-GbE),
která se ovšem v katalogu dlouho neohřála, a byla nahrazena
aktuálním modelem grandmaster karty pod označením HPS100.
Na společné platformě FPGA IP core od firmy Oregano
vznikly i další produkty zn. Meinberg a vývoj dále pokračuje.
Patrně obchodním rozhodnutím výrobce se karta HPS100 stala exkluzivním příslušenstvím nové modulární rodiny časových ústředen Meinberg, interně zvané "IMS": šasi LanTime M3000, M1000 a další postupně přibývají.
Karta HPS100 umí fungovat jako grandmaster nebo slave, podporuje řadu běžných profilů, díky PTP stacku Oregano je široce konfigurovatelná i v rovině jednotlivých atributů.
Základem karty HPS100 je FPGA s integrovaným dvoujádrovým ARM CPU. Právě hardwarová implementace v FPGA dává této GM kartě její jedinečný transakční výkon, flexibilitu konfigurace a "odolnost proti budoucnosti" (možnost aktualizace FPGA v rámci updatu firmwaru).
Karta obsahuje svůj vlastní IP stack, oddělený od managementu šasi.
Na rozdíl od produktů LanTime, které jako hardwarová koncepce
a obchodní značka vznikly v minulém tisíciletí, microSync je mládě.
V obchodní rovině se patrně jedná o reakci na tlak konkurence.
Co do mechanického formátu a vnějších rozhraní se jedná o takový
"švýcarský armádní nůž" - který má v základní výbavě širokou
paletu různých výstupních (a vstupních) signálů,
ale není mechanicky modulární.
Technicky se jedná o příbuzného výše uvedené karty HPS100, který získal samostatnost. ARMový linuxový firmware, pojmenovaný microOS nebo Meinberg OS, byl rozvinut do podoby, kdy nabízí možnosti konfigurace přinejmenším konkurující tradičnímu LanTime OS. Jediné FPGA uvnitř (s on-chip ARM MCU) servíruje PTP na dvou z celkových čtyř Ethernetových portů, z toho jeden port umí fungovat i jako slave (oba dva umí master režim).
Konfigurační rozhraní rodiny microSync je od LanTime OS značně odlišné, přesto podobně mocné - některé věci jsou udělané jinak a snad i lépe. Výkonově je PTP na microSyncu podobě licenčně odstupňované jako u HPS100, jenom strop celkové průchodnosti je o něco níž.
Rodina produktů microSync se rozrostla do několika větví, se sadou výstupů optimalizovanou pro různé oblasti určení: energetika, obecná laboratoř, studiové audio/video.
SyncBox je čistý slave, "konvertor PTP na diskrétní signály" - např. 1PPS nebo IRIG. Má tři výstupy jednotlivě programovatelné. Nemusí se jednat o BNC/TTL, jsou i další možnosti (factory options). Podporuje několik profilů, mj. Power Profile dle C37.238-2017 i IEC61850-9-3. Tato generace SyncBoxu nemá LanTime OS, konfigurace se provádí tlustým klientem Meinberg Device Manager.
Časoměrná karta do PCI-e slotu, s hardwarovou implementací PTP od firmy Oregano.
Podporuje širokou paletu profilů PTP a nějaké další funkce na diskrétních vstupech/výstupech.
Karta funguje na Ethernetu a TCP/IP autonomně, bez účasti operačníh systému.
Pomocí driverů pro běžné operační systémy lze z karty získávat přesné časové značky
a ovládat její další funkce.
PTP grandmastery jsou dlouhodobě dostupné, podpora PTP ve slave zařízeních
je také k dispozici už několik let (v síťovkách pod Linuxem).
Dlouhou dobu byla ale zásadním problémem dostupnost použitelných switchů!
Výrobci z první ligy switchů pro DC / telco / enterprise a také pro průmyslové použití mají každý v sortimentu alespoň jednotlivé vybrané modely, které PTP v nějaké podobě podporují.
Dnešní levné kancelářské SoHo switche PTP nepodporují.
Také menší výrobci "průmyslových" switchů (převážně z Asie) na podporu PTP zatím většinou rezignují. Výjimkou je např. taiwanský výrobce ATOP, který to s podporou PTP myslí zjevně poměrně vážně. Podrobnosti ponechme mimo rámec tohoto textu - ohledně switchů ATOP máme samostatnou přehledovu stránku a vybrané modely jsme zalistovali do e-shopu.
Volba switche/switchů s ohledem na PTP není zrovna triviálním úkolem.
Možných oblastí problémů je několik:
Volba switche je proto nakonec vždy téma na "průzkum bojem".
Zejména díky některým našim nekonečně ochotným zákazníkům
(nesmíme jmenovat, NDA) už máme v tomto směru určité zkušenosti
- naším "testovacím koutkem" prošlo několik značek switchů
s podporou PTP, zvlášť pokrokoví zákazníci platí své interní
rozvojové a pilotní projekty apod. Určité know-how tedy už máme.
Máte-li záměry s určitou značkou a modelem switche,
ale nejste si jisti, jak je to doopravdy s podporou PTP,
a máte možnost zařídit zápůjčku, rádi posloužíme
praktickou "recenzí" zapůjčeného zařízení.
Jak již zmíněno v předchozí kapitole, podpora PTP dosud není
"jednou banální fajfkou z mnoha v seznamu pro nákupčího".
Dokumentace je užitečná, ale pro spolehlivý verdikt nedostatečná.
Podporu PTP je bohužel třeba posoudit nejlépe testem
v nějakém zapojení, které se alespoň skladbou hardwaru
(když už ne počty) blíží uvažované ostré topologii.
Dále je otázkou, jak podporu PTP posoudit.
Ďábel se totiž skrývá v detailech.
"Nakonfiguroval jsem to a tváří se to, že se to chytlo"
je sice dobrý důvod k optimismu, ale také velice povrchní
hodnocení. Že se napohled spojil protokol, to samo o sobě
ještě neznamená, že celý "časovací signálový řetězec"
funguje skutečně správně.
Chceme-li podrobněji zhodnotit správné fungování PTP,
je vhodné se ponořit pod kapotu a trochu se ušpinit od oleje.
Vytáhnout si ladící výstupy a odposlechy kde se dá,
pozorovat cvrkot na síti a vývoj odchylek.
Konkrétně je vhodné se pokusit o tyto kroky:
Měření odchylky 1PPS se záznamem na HDD dává neocenitelný přehled - přesný obrázek např. počátečního ustalování libovolného časoměrného slava s fázovým závěsem. Tenhle sekáč se nezakecá (pokud zaznamenává skutečně každý tik 1PPS = každý sekundový vzorek). Takový časosběrný přehled nemáte šanci pořídit prostým dvoukanálovým osciloskopem.
Užitečné vybavení pro shora uvedenou testovací a měřící činnost:
Málokterý switch zvládá jak P2P tak E2E. Mnohé switche zvládají to či ono. Konkrétně E2E je obvykle náročné na CPU switche a hůř "škáluje" - což se projeví při vyšší zátěži. Kamenem úrazu je také podpora provozu PTP skrz trunky 802.1Q tagged VLAN.
Wireshark, zobrazen je PCAP pořízený skrz 4 rozhraní (2x duplex)
Situace ohledně podpory PTP v operačních systémech je... zajímavá.
Dlouhá léta platilo, že Linux podporu má, Windows podporu nemají.
Ale, počínaje Windows 10 21H2 (nebo už 1909 ?), případně Windows 11 (Build 10.0.22000.194), do Windows přibyla podpora HW značkování paketů.
K mání je čerstvá přehledová kapitola ohledně NDIS packet timestamping API.
Otázkou patrně zůstává, nakolik je tato podpora pod Windows prakticky použitelná.
Minimálně dokumentace je zatím strohá a možná lehce matoucí.
Základním předpokladem je podpora "hardwarového značkování" paketů.
Tato podpora dnes existuje v hardwaru síťových karet/čipů několika výrobců,
konkrétně v novějších modelech Intel (řekněme i210/i350 a mladších),
Broadcom a nově snad i Realtek. Na straně operačního systému by měla
navazovat podpora v HW-specifickém ovladači od výrobce síťovky,
a nejlépe také jednotné API operačního systému, do kterého by
HW-specifický ovladač časové značky předával.
Systémové API by také mělo pokrývat ladění hodin PHC v hardwaru síťovky,
kteréžto probíhá softwarově (PTP služba běží v softwaru).
A právě standardní API v kernelu a podpora v ovladačích jsou těmi SW součáskami,
které Linux má (už dlouho, kvalitní) a Windows teoreticky už mají,
ale otázkou je zatím dopracovanost.
Ohledně Windows některé kusy dokumentace například tvrdí,
že jedinou možnou cestou je cross-timestamping (diferenciální značky
opřené o nepřesné systémové hodiny), ovšem jiný útržek dokumentace
naznačuje, že snad bude možné značkovat i přímo volnoběžným
nativním časem PHC v síťovce.
Jinde se lze dočíst, že selektivní značkování PTP (filtrace v hardwaru)
lze použít pouze pro enkapsulaci na UDP (tzn. na L2 smůla).
V self-help fórech firmy Intel visí vlákna z přelomu 2021/22 [např. , anebo],
kdy tyto vlastnosti byly pod Windows nové, ze kterých by bylo možno
vyvozovat, že podpora HW timestampingu na různých čipech zn. Intel
byla pod Windows přinejmenším zpočátku značně "řidší", než pod Linuxem
(na síťovkách, které to hardwarově umí).
Návaznou otázkou je podpora aplikačním softwarem.
Například pod Linuxem existuje kanonický projekt linuxPTP (démon ptp4l a jeho doprovod)
a high-res časové značky ze síťovky lze také použít v tcpdumpu/wiresharku.
Existují i další open-source implementace PTP, ale nezaznamenal jsem, že by některá z nich
využívala zbrusu nové funkce WinAPI pro packet timestamping.
Pozor: zdá se, že podporu PTP obsahuje už i w32time - přinejmenším zdrojáky, které Microsoft
pěstuje na githubu.
V debatě na uvedeném odkazu sedí informace, že PTP pod Windows má šanci fungovat s transportem nad IPv4,
a vidím také měření delaye E2E. Toto by zřejmě odpovídalo PTP Enterprise Profile
(od roku cca 2013 ve stádiu draftu u IETF, autoři Heiko Gerstung a Doug Arnold, oba z firmy Meinberg).
Fakt je, že E2E měření je jedinou možností v 99% stávajících LAN sítí,
protože podpora P2P ve switchích je zatím velká vzácnost.
Snad jen E2E delay transakce multicastem... no nic.
Ohledně podpory PTP a timestampingu pod Windows osobně zažívám jisté deja vu
- nemohu nevzpomenout na Winsock 1.x někdy před třiceti lety.
A co znamenal příchod Winsock 2.0.
Bohužel PTP není pod Windows zdaleka taková "killer feature" jako TCP/IP.
Pod Windows samozřejmě "odjakživa" fungují karty s kompletní implementací PTP stacku v hardwaru a firmwaru karty. V systému pak může běžet serviska a proprietární ovladač, které zajistí synchronizaci systémových hodin s PTP kartou, poskytnutí přesného času user-space aplikacím a případné další speciální funkce hardwaru karty. Tzn. funguje to podobně jako karta rádiového přijímače času (opět viz sortiment Meinberg).
Meinberg white paper: Time Synchronization in Telecom Networks
Meinberg Tutorial: Telecom Profile with Full On-Path Support
Meinberg Tutorial: The PTP Telecom Profile for Frequency Synchronization
The Wikipedia entry on IEEE1588 = PTP
White Rabbit project: Heslo na wikipedii, Oficiální homepage, Podrobnější přehled hardwarových produktů, Technické podrobnosti o synchronizaci, Tutorial (slideshow)