No, možná místo strkání dalšího switche mezi to Cisco a rádio by stačilo na tom Ciscu pro daný port napsat "flowcontrol receive on" nebo slušněji "flowcontrol desired", pokud rádio podporuje korektně proces autonegace na Ethernet portu. Cisco má defaultně zakázán příjem pause rámců (802.3x) a většina Cisek je neumí vůbec generovat.
Možná příčina problému:
Mám koupenou lajnu 100 Mbps, rádio třeba dává 150 Mbps a teď mi přijde malý burst dat, který k rádiu jde po 1 Gpbs lajně a je větší, než přenosová kapacita rádia a delší, než co pojmou vstupní bafry v rádiu (rádio je většinou šmejd a má vstupní bafr na pár paketů). Blíží se plno, posílá pause rámec a Cisco nic, protože na to kašle a rádiu nezbude než to zahazovat. Vložíte tam switch z produkce čínského domácí zemědělství a máte opraveno, protože většina těch krabic má defaultně 802.3x zapnut (kolikrát natvrdo a nejde vypnout i když v nastavení na to volby jsou), neboť jejich výrobci jsou realisti a ví, že ty jejich krabice občas nestíhají, tak si natvrodo pomáhají pomocí flowcontrol a velkých vyrovnávacích bafrů na jednotlivé porty, což pak budí navenek a z dálky pocit, že vše teče suprově a na max.
To postihlo evidentně i Hapiho. To centrální shapovátko k němu posílalo data v blocích víc, než kolik sneslo rádio a měl výopadky. A ten vysílaný provoz netflow dat ve velkých burst blocích mu k tomu jen přihrával. Mylsím, že technik ani tak nesnižoval velikost shapovací fronty k němu (tím by paket loss nevyřešil, pakety by se zahazovaly místo na rádiu už na vstupu shaperu), jako spíše měnil parametry odesílání dat z té fronty. Ta bedna vyrábí na výstupu 100 Mbps v průměru, krátkodob to pošle víc a pak chívli čeká. Pokud rozpotřel to odesílání na kratší bloky a častěji (což těm bednám ne úplně vyhovouje z pohledu celkového výkonu), tak dá šanci tomu rádiu postupně to odvysílat. Zkrátka shapovaíc bedna nesmí vypustit naráz víc, než poberou ty bafry v posledním switchi před tím rádiem, kde nastává větší zůžení přenosu. Tím, že tam nacpu polotupý switch, tak obvkyle výrazně zvětším ten záchytný bafr a problém se ztrátou paketů v podstatě vyřeším. Správné řešení je kopat za to, aby to shapovátko to neposílalo víc, než co unese to rádio.
Protože toto řešení s velkým vyrovnávacícm bafrem a 802.3x má jednu drobnou slabinu - také tu bylo někde vlákno, kde se plakalo nad tím, že nedokážete vytížit jedním TCP spojením plně konektivitu - velké bafry a 802.3x je pro maximálnu TCP přenosu smrtící.
