(podzim 2023)
Asi díky mému vztahu k sortimentu Meinberg (synchronizace času) a konkrétně IEEE1588 PTP příležitostně zpozoruji buzzword TSN, když se mihne kolem. U Meinbergů v souvislosti s PTP profilem 802.1AS, který je součástí TSN. Mimo sortiment Meinberg se jednalo dosud až na výjimky o setkání papírová, hardware s údajnou podporou TSN jsem držel v ruce asi jednou.
PTP profil 802.1AS je podivín: předně si upravuje IEEE1588 PTP na "svoje" gPTP, tj. 802.1AS není podmnožinou IEEE1588-2008. Dále má svůj vlastní režim provozu switchů (hybrid BC/TC), má svůj vlastní BMCA.
Tu a tam se v ceníku některého z menšinových výrobců ethernetových switchů objeví model s údajnou podporou TSN, ale dostupnost je neznámá a manuál buď není nebo je "tajuplný".
Nedávno jsem postřehl nuanci v množině 802.xyz přípodotků, která naznačuje generační předěl v plemenném názvosloví TSN. (Těžko mluvit o generačním předělu ohledně dosud prakticky prázdné množiny fyzického hardwaru.)
A právě tato nuance mě ponoukla k tomuto spisku.
Následující dvě kapitoly shrnují TSN "před a poté".
TSN je často vysvětlováno směrem od průmyslové komunikace, řekněme komunikace mezi PLC někde ve výrobním provozu. V tomto prostředí se tradičně používají "průmyslové sběrnice" mnoha druhů (fieldbus v širším slova smyslu) - někdy proprietární od fyzické vrstvy výš, často založené na komoditní fyzické vrstvě: RS485, CAN a potomstvo, v modernější době často Ethernet.
Jedním z typických koncepčních schémat komunikace je "distribuované zrcadlení process image", kde si jednotlivé uzly na sběrnici v rychlém sledu předávají "žezlo" (token passing) a každý odvysílá svůj vlastní segment sdílené "tabulky proměnných". Může se tak dít bez jednoznačného mastera, nebo jeden uzel komunikaci nějakým způsobem moderuje, případně z pozice mastera cyklicky oslovuje jednotlivé slavy (což je způsob relativně nejméně efektivní). Cyklus může běžet nebržděně a z hlediska lidského reálného času asynchronně, nebo mohou cykly startovat v pevném taktu.
Právě cyklická komunikace v deterministickém taktu bývá dávána
za příklad praktického uspořádání low-latency komunikace v real-time nasazení.
Laskavý čtenář přimhouří oko nad okolností, že přenosové zpoždění jako takové
s přidělováním vysílacího času vlastně nesouvisí.
Pro potřeby tohoto vysvětlení budiž dílčí pointou, že "cyklická data"
jsou v tutorialech ohledně TSN zmiňována ve smyslu "spěchající provoz",
s požadavky na nízkou latenci. V protikladu k "acyklickým datům",
která protečou samotížně, až na ně dojde řada.
První vlna TSN řeší upřednostnění časově kritických dat pomocí vcelku standardních
schopností běžných čipsetů ethernetových switchů: na bázi řazení egressu do několika
fyzických front s odstupňovanou prioritou.
Pravda je, že už algoritmy řazení do front v této první vlně budí určité podezření,
že možná budou vyžadovat v hardwaru určité úsilí navíc, nad rámec běžných schopností,
které stačí na 802.1p, IP DSCP apod.
Konkrétně už první vlna TSN zavádí tato 802 čísílka a k nim vysvětlivky:
802.1AS = svého druhu PTP, vyžaduje přinejmenším HW značkování + související podporu ve firmwaru (lepší je komplet HW implementace). Řekněme, že PTP už není úplný exot.
Popravdě, už ty divotvorné frontovací strategie jsou na pováženou.
Ale pořád tu nikdo nenaznačuje, že by se snad mělo kvůli latencím prioritního
provozu přerušovat odesílání paketu, který už je vysílán,
už ho kus odlétl do fyzického média. To by totiž znamenalo
udělat pauzu a paket prakticky zahodit, poté co by fyzická
vrstva příjemce konstatovala vadné CRC.
...nebo snad ne ?
No a přesně tuto novinku přinášejí poslední dva přírůstky do TSN 802.xyz zoo:
Tedy: dlouhý neprioritní paket, loudající se z prvního místa ve frontě směrem ven, lze podle nových norem v rámci druhé vrstvy přerušit = rozdělit na fragmenty. Následně odvysílat spěchající provoz, a pak navázat dalším fragmentem přerušeného neprioritního paketu. Toto proložení proběhne bez ztráty pomalého paketu. Zdá se, že "peklo zamrzlo".
Pomalý paket lze přerušit = rozfragmentovat i navícekrát. Minimální velikost payloadu uvnitř fragmentu je 60 Bajtů. Místo přerušení podléhá nějakému pravidlu pro zarovnání (snad po 8 oktetech, alespoň v prvních draftech z roku 2014 se o tom hovořilo ve smyslu TBD) a sama podpora Frame Preemption přidává ke každému rámci pár bajtů navíc. Tzn. efektivita ve smyslu pásma má své meze a minimální latence pro prioritní provoz taky neklesne na úplnou nulu. Ale lepší 60B než 1500B nebo nedejbože jumbo.
Formát letmo produkovaných fragmentů pomalého provozu je vymyšlen tak, aby jednotlivý fragment měl platné CRC. Proto nedochází k zahazování přerušených pomalých paketů, a proto také není potřeba úprava fyzické vrstvy: lze použít standardní PHY transceivery a standardní SERDES nebo MII transport mezi MAC/PHY. Úpravu křemíku ale samozřejmě vyžaduje MAC vrstva. (Kdo ví něco o Ethercatu, zažívá patrně v tuto chvíli lehké deja vu.)
Norma také pamatuje na kompatibilitu se staršími ethernetovými porty / uzly,
které Frame Preemption nepodporují. K zapnutí této vlastnosti v MAC vrstvě
se přikročí teprve poté, co se oba partneři na fyzickém spoji dohodnou,
že oba tuto vlastnost podporují.
K této dohodě NEdochází v rámci IEEE 802.3 clauses 28 & 40 - TSN definuje
k tomuto účelu speciální rámce zvané VERIFY a RESPOND. V podstatě dotaz-odpověď,
transakce je provedena pro každý směr nezávisle (každý z obou partnerů se svým
jménem zeptá a očekává odpověď).
Pokud stavíte síť a aplikaci s využitím TSN, dávejte si pozor, co kupujete za komponenty. Je třeba samozřejmě vycházet z reálných potřeb aplikace. Pokud míříte na frame preemption / interspersing, buďte si vědomi, že se jedná v letech 2022-2023 stále o novinku, která se teprve začíná objevovat v čipsetech switchů. Tzn. v tom případě nepovažujte za bernou minci přítomnost buzzwordu "TSN" v katalogovém listu, ale hledejte 802.3br a 802.1Qbu.
Například "klientský" čip Intel i225, který údajně podporuje vše potřebné, prošel během několika let asi třemi revizemi křemíku, než mu konečně výrobce vychytal dětské nemoci.
Obecně asi nebude problém, pokud systém využívající TSN kupujete jako ucelenou proprietární stavebnici od konkrétního výrobce. Pozor ale na hardware "z volného trhu" = pokud se snažíte integrovat systém z komponent od různých výrobců. Zde platí "důvěřuj, ale prověřuj". Papír katalogového listu unese hodně (a co teprve PDFko) - reálně je třeba, uvažované konfigurace si otestovat na vzorcích hardwaru.
Což mi připomíná... ono to asi nepůjde snadno pasivně odposlechnout (např. skrz optický splitter).
Síťovkou bez podpory samozřejmě nikoli.
Pokud se použije síťovka s podporou (např. i225, viz níže) tak nejprve
není jisté, že do pasivního odposlechu zafunguje dvoustranný handshake
VERIFY+RESPOND.
A pokud odposlechová síťovka pochopí a fragmenty přijme, tak zas pokud všechno klapne,
dostane odposlouchávající user space již rekombinované kompletní rámce = nemá šanci,
vidět jednotlivé fragmenty. Pokud bude fragmentace někde skřípat (sem tam nějaký fragment
bude chybět nebo bude mít vadné CRC) tak se to projeví ztrátou celých paketů v odposlechnutém PCAPu.
Určitou informaci by mohlo poskytnout porovnání přenosových latencí se zapnutou preempcí vs. bez preempce
- na to stačí odposlech se synchronní časovou základnou a HW značkováním v odposlechu.
Úplný detailní odposlech fragmentů leda specializovaným analyzátorem (nebo dobrým osciloskopem).
Inu nemůže být každý den posvícení.
TSN technology: basics of Ethernet Frame Preemption, part 1 and part 2
Ludwig Winkel, Siemens AG:
IEEE 802.3br
Interspersing express traffic (IET)
Task Force (TF)
Baseline 2014-05-14
I225/I226 Time-Sensitive Networking Features Brief