Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

— flow_control_a_buffery_na_switchich [2019/05/05 23:50] (aktuální)
0.0.0.0 vytvořeno
Řádek 1: Řádek 1:
 +====== Flow_control_a_buffery_na_switchích ======
  
 +https://​gettys.wordpress.com/​2013/​06/​20/​bufferbloat-in-switchesbridges/​
 +
 +Problém:
 +
 +Na páteřních linkách s ubnt klesá propustnost se zvětšujícím se počtem hopů
 +
 +Příčína:​
 +
 +Příčina je, že moderní UBNT agreguje až 50k dat a je odešle jako burst
 +na full 1Gbps. 1S10 nemá buffery na to to pobrat a zahodí občas packet. ​
 +
 +To se samozřejmě nedělo u UBNT řady XM, protože ta má jen 100 Mbps port,
 +který zabrání vytvoření burstu o rychlosti 1Gbps. Ale u řad XW, TI a AC
 +s GbE porty už se to děje.
 +
 +-----------------------------------------------
 +
 +Pro tábor flow-control-je-nutnost:​
 +
 +S zapnutým flow-control místo zahazování packetů prostě 1S10 pošle PAUSE
 +frame a řekne TP-Linku aby chvíli neposílal. Tím začne 1S10 vypadat pro
 +TP-Link jako spolehlivý port běžící na 150 Mbps.
 +
 +Ovšem problém se zahazováním se tím přesouvá na TP-Link. Ten má jen 512k
 +bufferů a tak dokáže nabufferovat cca 4ms při plné gigabitové rychlosti.
 +Na burst od UBNT to bohatě stačí, ale mohou nastat i horší situace, kdy
 +se buffery zaplní.
 +
 +V takovém případě TP-Link pošle PAUSE na VŠECHNY porty co mají flow
 +control, protože neví odkud co teče a efektivně zastaví veškeré toky do
 +něj. To může zpomalit toky nezávislé na tom, který způsobil zaplnění
 +bufferů.
 +
 +To ale moc nevadí, protože v tom okamžiku začnou bufferovat připojená
 +zařízení jako UBNT, i připojený router a ty by ideálně měly mít
 +nastavený sfq nebo fq_codel qdisc, aby začaly optimálně zahazovat
 +packety, aby jim buffery (a tedy latence) nerostly do příliš vysokých
 +čísel.
 +
 +-----------------------------------------------
 +
 +Pro tábor flow-control-is-evil:​
 +
 +Alternativa k použití flow control je inteligentní switch, který umí
 +shaping, nastavení shapingu pod limit 1S10, a buffery zvlášť pro každý
 +output port a rozumný qdisc, aspoň red, když už ne sfq, nebo fq_codel.
 +Ale to jsme v docela jiné cenové kategorii a nebude to dobře chodit
 +pokud 1S10 sníží modulaci a tudíž propustnost.
 +
 +-----------------------------------------------
 +
 +Pro tábor enterprise-technology:​
 +
 +Pokud je switch opravdu dobrý, tak může flow-control fungovat skvěle,
 +protože switch zjistí koho přesně má zakázat podle interní statistické
 +analýzy toků a neovlivňuje tak jiné toky.
 +
 +-----------------------------------------------
 +
 +musím se ještě opravit: TL-SG3216 má sice 512k bufferů, ale rozdělené na
 +4 separátní fronty a v základním nastavení se z nich používá jen jedna,
 +tedy v základním nastavení je na buffery 128k, což odpovídá cca 88
 +packetům a časově 1ms na 1GbE, což je zcela adekvátní velikost.
 +
 +Bohužel je ta fronta čisté FIFO, mezi frontami je možno zapnout buď
 +prioritizaci nebo weighted round robin. Žádný red ani sfq neumí.
 +
 +Chtělo by to zapřemýšlet,​ jestli by vhodné rozvržení front mezi vstupní
 +porty nevylepšilo některé vlastnosti přenosu v situaci, kdy se buffery
 +přeplňují.
 +
 +
 +-----------------------------------------------
 +A ještě jedno doplnění:
 +
 +RTL8736, který nejspíš je v TL-SG3216 umí vybírat fronty i podle ACL a
 +ACL se dá nastavit dle VLAN. Ověřil jsem, že i přes webové rozhraní to
 +jde na TL-SG3216 nastavit.
 +
 +Mezitím jsem studoval datasheety or Realteku a už začínám zhruba rozumět
 +tomu, kdy použije PAUSE frame pro flow control. Je to o dost lepší, než
 +u úplně stupidního switche. PAUSE se pošle vždy do JEDNOHO portu a to do
 +toho, ze kterého přišel packet, který už není možno zařadit do fronty,
 +protože ta fronta je plná. Packet zůstane v input bufferu do té doby,
 +než se ve frontě, kam patří, aspoň jedno místo uvolní, pak je port opět
 +otevřen. Ostatní porty jsou nepostiženy. To znamená, že oddělením front
 +dle portů a VLANů by mělo jít docílit docela pěkného chování.
Tisk/export