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