NetLab jak pomalé to může být

Tohle je statická kopie kapitoly pro vyhledávače. Interaktivní verze má animované obrázky, kontrolní otázky a tlačítka, která příklad načtou do kalkulačky.

Přepínač: kolize zmizely, čekání ne

Původní Ethernet byl jeden kabel, na kterém se všichni střídali. Když začali dva naráz, byla to kolize, obě strany zmlkly na náhodnou dobu a zkusily to znovu. Je to přesně to, čemu se CAN vyhnul arbitráží — a je to důvod, proč se u Ethernetu nedalo nic zaručit.

Přepínač tenhle problém odstranil. Každé zařízení má vlastní kabel, přepínač si pamatuje, kdo je kde, a rámec pošle jen tam, kam patří. Kolize v moderní síti neexistují.

Jenže tím se problém přesunul, ne vyřešil. Když dva rámce chtějí na tentýž výstup, přepínač jeden z nich uloží do fronty. Nic se neztratí a nic se neopakuje — ale čeká se, a čekání je pro regulační smyčku úplně stejně zlé jako opakování. Jen se to hůř hledá, protože nikde není chybový čítač.

Dva způsoby, jak přepínač může přeposílat

uložit a poslatprůchozí
kdy začne posílataž má celý rámecpo přečtení adresy
zdržení na skokcelá doba rámce (až 123 µs)~100 ns
zkontroluje FCSano — vadné zahodíne — pošle dál i vadný rámec
umí mezi rychlostmianone

Běžný kancelářský přepínač je „uložit a poslat“. To znamená, že každý skok přidá celou dobu rámce — a u plného rámce na stovce megabitů to je 123 µs na skok. Tři přepínače po cestě jsou 369 µs, než se vůbec začne počítat cokoli jiného.

Rámec, který už se posílá, se nepřeruší

Tohle je ta nejdůležitější věta v celé kapitole. Když váš krátký řídicí rámec přijde do přepínače ve chvíli, kdy se právě posílá cizí rámec o 1500 bajtech, počká. Ne proto, že by měl nižší prioritu — prostě proto, že rozeslaný rámec nejde vzít zpátky.

nejhorší čekání ≥ doba jednoho plného rámce123 µs při 100 Mb/s

A to platí, i když je síť jinak úplně nečinná a i když má váš provoz nejvyšší prioritu. Je to nesnížitelný jitter obyčejného Ethernetu, a je to přesně to číslo, se kterým se v kapitole 10 nedá nic udělat jinak než změnit pravidla.