Vše co má ETH nebo SFP atd.. má FC. Resp. by měla mít, to že nejde zapnout je věc jiná. Je to věc kterou řeší hardware sám. Nezáleží na tom jestli to je switch nebo sítová karta nebo sítový chip v CPU. Všechno to má možnost FC. Je to ethernetový protokol. L2 vrstva. Vše co jede na ethernetu má možnost FC. Nezáleží na tom do čeho je ethernet zapojenej. Pamatovat si že FC je něco co posílá HW sám a neopustí L1 což znamená že platí pouze pro jeden ethernetový kabel. FC neproklouzne po celí L2 síti. Je pouze v rámci L1. Hned jak ho protistrana zachytí tak ho zahodí. Mikrotik to ukazuje hezky, s čítačem rx pause, rx control se zvedá ve stejným počtu i čítač rx drop.
Každý interface mívá nějaký buffer. Příchozí data se nedají ovlivnit takže příjdou ať chceme nebo ne. Dorazí do RX bufferu sítovky/switche. Pokud si je CPU nevyzvedne třeba protože je přetížený a nemá čas a nebo třeba jiný port ve switchy je nestihne odeslat protože je např. pomalejší než ten příchozí (příchozí port 1Gbit -> odchozí port 100Mbit) tak dojde k tomu že se RX buffer celej zaplní. Všechno další co se do bufferu nevejde se zahodí. Co by s tím dělal, že. Když se zapne FC tak se ještě navíc odešle pause rámec protistraně aby pozastavila odesílání dat. Tím nedojde k zahození ale jenom k pozastavení než se zase buffer uvolní. Protistrana ho musí mít zapnutej samozřejmě taky protože jinak pauzu ignoruje a pokračuje v odesílání.
To že musí prvek před tím pozastavit odesílání může bejt problém protože i on může čelit stejnýmu problému jelikož i jemu nějaký data z jiných iface přichází. Už jenom ten tok dat co zastavil odněkud teče takže i jemu může dojít buffer a bude muset začít dropovat i on sám případně odesílat svoje FC tomu před sebou a tak dále a tak dále až to může takhle zaškubávat celou trasou.
Takže ti musí bejt už jasný že tohle není záležitost toho jestli je kde zapnout FC. Lze to zapnout všude pokud to výrobce dovolí a je jedno jestli to je CPU s ETH uvnitř a nebo chip switch. Všechno by to mělo umět. Rozdíl je jenom v tom jak velký buffer je a čim je větší, tím víc dokáže pohltit příchozí toky i bez FC.
Jo a pozor na to, to že tam zrakem člověka teče 50Mbit neznamená že tam teče 50Mbit ale teče tam vždy plná rychlost portu. Říkáš si blbost? No jenomže 1Gbit port má přece jenom jednu komunikační rychlost takže vše vždy přijde 1Gbit rychlostí i když tedy s mezerami který ale prostě se vzorkováním 1 sekundy nevidíme. Proč to sem motám?
Když si vemeš jak funguje TCP protokol a že v něm existuje nějaký tcp window size a může bejt třeba 16kB velký a klidně i větší což znamená že zdroj dat odeslal na ráz 16kB dat rychlostí 1Gbit (což mimochodem UDP btest neudělá, ten stoupá pěkně pomalu a hledá strop, TCP btest to ale udělá) tak ten RX buffer dostane okamžitě masáž. A ještě si vem, že to je jenom jedno spojení ale na sítových prvcích jich bejvá fůra takže se to hezky sčítá a najednou chudinka ubnt tought switch nemá dostatečný buffer na to aby zbrzdil data před tím než je pošle 10x pomaleji do LHG který jede na 100Mbit. Vem si to, 10x pomaleji. Pomalu si to řekni a představ si to. To je jako zbrzdit auto jedoucí 100km/h na 10m na rychlost 10km/h kterou jede kolona.
Tohle všechno jenom podtrhuje používat defakto dražší hardware především u switchů který mají větší a lépe zpracovaný buffery a nebo u takových switchů zajistit aby alespoň všechno v nich mělo stejnou rychlost. Prakticky od určitý úrovně datových toků a počtu spojení přes ně, nelze používat desktopové/levné switche atd. Jo, oni na stole v pohodě udělají mezi čtyřmi počítači 4Gbit ale pak mají problém se 100Mbit když tam tečou data pro 100 počítačů/zákazníků.
Každý totiž sem tam chce nějaký to TCP s oknem dejme tomu kolem 8kB a víc a najednou tam takových věcí letí 50 a 50x8kB je v tom daným časovým úseků víc než buffer zvládne. Takže nastupuje FC což u desktop/neřiditelných switchů nejde zapnout a končíš. Bez FC s malým bufferem nastane to, že při testu UDP frčí protože se pouští postupně bez TCP oken ale TCP vystřelí, zjistí že se dropuje tak automaticky zpomalí a ubere velikost okna a rázem máme nesmyslně malou rychlost která s rostoucí latencí případně delší vzdáleností bude ještě víc klesat.
Pak je tu ještě možnost jak psal "cerva". Softwarový buffer. To je pouze TX buffer a v případě příkladu v prvním postu nemá na to vůbec žádný vliv protože už ethernetem nepříjdou data dost rychle na to aby to mělo výrazný vliv na propustnost. Prakticky se to dá ladit jenom tam kde jdou data přes CPU.
Podle toho příkladu může bejt na vině klidně i to pomalí ALFO. RB3011 je dost výkonná na to aby data rvala do pojítka horem dolem. Osobně bych začal s tím že bych zapnul FC na RB3011, klidně jenom na portu k alfo. V pojítku bych ho zapnul taky a to na obou stranách pojítka a v ubnt switchy zapnout taky a opět klidně jenom ze strany k alfo. Alfo by samo o sobě mělo mít velký buffer. Mělo by většinu věcí kompenzovat ale musí to vědět že to někde nestíhá což mu řekne FC od ubnt switche kterej uričtě nestihne nabufferovat před zpomalením na 100Mbit.
Ono je to znát i tam kde vyměníš 100Mbit switch za 1Gbit switch kde už antény měly 1Gbit dávno ale jely na 100Mbit kvůli switchy a ačkoliv tam teklo tak 50Mbit tak najednou je to pružnější, rychlejší. Všechno se rychle odbaví do CPUček boardů kde tomu pomůžou softwarový buffery. Typnu si že kdyby tam bylo dejme tomu CRS112 v softwarovým bridge tak to všechno uhladí a pojede to.
Každej nechce kupovat super switche takže FC řeší u malích ISPíků většinu problémů a nezpůsobí žádný škody.
Fakt bych měl už za tohle dostat ban.
