Flow control

mirrlc

Zdravím mám dotaz. Zapínáte Flow control i u zákazníků nebo pouze na AP a spojích ?

kozlicek

mirrlc vsude

ekrajnak

Nikde.

pgb

Taky nikde + intenzivně pracujeme se shaperem

felix

Nikde.

vecino

Moje zkušenost je, že někde pomůže a někde ne. Pokud nejsou problémy, tak nechat vypnuté. Pokud se nepletu, tak třeba UBNT CPE (5AC) mají také flow control zapnutý by default.

iTomB

Tam kde je potreba.

gemb

Jedine kde som ho kedy zápinal bolo na spojoch Ray, nikde inde.

ekrajnak

gemb Aky ma zmysel zapnut flow control na radiu? Skor na zariadeni pred nim, nie? (EDIT: treba zapnut obe strany, samozrejme). Mam skusenost s 24G Ray3, 1Gbps. Raz doslo k znizeniu modulacie kvoli vytoceniu anteny. Bezal tam mix 200M multicastu (strict priority) + uzivatelske data. Ziaden Flow Control netrebalo, radio saturovalo a pekne robilo QoS podla DSCP.

Priznam sa, nikdy som si nestudoval Flow Control do podrobna. Princip je jasny, ale co ak ide o viacero VLAN na porte, co ak ide o viacero tried trafficu? Toto mi stale vrtalo v hlave. A ajhľa, dnes otvorim wikipediu a tam:

Issues
One original motivation for the pause frame was to handle network interface controllers (NICs) that did not have enough buffering to handle full-speed reception. This problem is not as common with advances in bus speeds and memory sizes. A more likely scenario is network congestion within a switch. For example, a flow can come into a switch on a higher speed link than the one it goes out, or several flows can come in over two or more links that total more than an output link's bandwidth. These will eventually exhaust any amount of buffering in the switch. However, blocking the sending link will cause all flows over that link to be delayed, even those that are not causing any congestion. This situation is a case of head-of-line blocking (HOL), and can happen more often in core network switches due to the large numbers of flows generally being aggregated. Many switches use a technique called virtual output queues to eliminate the HOL blocking internally, so will never send pause frames.

A este sa tam spomina takato mudrost:

The first flow control mechanism, the pause frame, was defined by the IEEE 802.3x standard. The follow-on priority-based flow control, as defined in the IEEE 802.1Qbb standard, provides a link-level flow control mechanism that can be controlled independently for each class of service (CoS), as defined by IEEE P802.1p and is applicable to data center bridging (DCB) networks, and to allow for prioritization of voice over IP (VoIP), video over IP, and database synchronization traffic over default data traffic and bulk file transfers.

Neverim ze nejake lacne zariadenia ako UBNT ci Ray maju implementovane 802.1Qbb.

Takze asi by som to zhrnul takto: ak ide skutocne o problem s malymi bufframi a potrebujete riesit QoS priority, treba sa obhliadnut po inom zariadeni. Inak mi moze byt uuuplne jedno ci mi pakety dropuje plny buffer alebo zariadenie pred tym podla pause frame. Ledazeby to zariadenie pred tym nezacalo hned dropovat, ale vyuzilo este svoj buffer k oneskoreniu ... ale to je taka prasacina, ze uz radsej koncim prispevok. 😃

gemb

ekrajnak ja som to pozapinal aj v radiach aj na ethernetoch do ktorych to bolo pripojene...

ekrajnak

gemb jo, beriem spat, zle som to pochopil. Samozrejme treba zapinat obe strany.

pedro4444

presne na ray to ma zmysel a este na airfiber inde som ten vyznam nepostrehol....

honzam

Ještě na Summitech

pixall

Klasicky flowcontrol a QoS vobec nejdu dokopy. Zapnuty flowcontrol je zabijak napriklad na IPTV alebo na akekolvek data citlive na jitter a loss. Nikto si nezela, aby mu pri plnej linke vznikali pauzy v celom trafficu a aby sa zahadzovalo bez rozumu to, co sa prave do linky nevoslo.

Korektne riesenie je vypnut flowcontrol, a oshapovat traffic tak, aby vzniklo uzke hrdlo tam, kde to chcem ja, a kde to viem aj nalezite QoSovat a teda rozhodnut, co sa bude zahadzovat.
Takze ked mam 360 Mbit/s synchro radio pripojene do Cisco switcha, tak prislusny port Cisca oshapujem na 350 Mbit/s, a zaroven to na tomto mieste oQoSujem tak, aby IPTV malo vysoku prioritu a internet nizku. Ked sa naplni 350 Mbit/s limit na switchi, budu sa na switchi dropovat v prvom rade internetove pakety, IPTV prejde bez straty. Kedze mam maximalne 350 Mbit/s trafficu a za tym je 360 Mbit/s radio, teoreticky nikdy nedojde k naplneniu jeho buffrov. (V praxi k tomu dojde pri poklese priepustnosti radia, takze ma zmysel zapnut QoS aj v radiu, aby si s tym v takych pripadoch poradil.)

V praxi si potom optimalnu rychlost shapovania treba vyladit podla typu radia. Pre radia s velkymi bufframi sa moze kludne do radia pustit aj o 10-20% viac ako je jeho priepustnost, a je to OK. Radia s malymi bufframi treba shapovat nizsie nez je ich realna priepustnost. Chce to trochu testov s plne vytazenou linkou (najlepsie realny traffic) a trochu sa s tym pohrat a najst optimalnu hodnotu.