Flowcontrol ano alebo nie?

[rado3105]

Ubnt odporuca zapinat flow control, ak na danom zariadeni neprebieha QOS....aky mate na to vy pohlad? pouzivate? zapinate defaultne?

http://community.ubnt.com/t5/airFiber/E ... d-p/559729

[Dalibor Toman]

Ubnt odporuca zapinat flow control, ak na danom zariadeni neprebieha QOS....aky mate na to vy pohlad? pouzivate? zapinate defaultne?

http://community.ubnt.com/t5/airFiber/E ... d-p/559729

zalezi cemu se rika QoS. Na nekterych zarizenich je QoS jedinym zpusobem jak vyrobit a ovlivnit frontu na portu a jak shapnout rychlost na portu. Takze mam zaply QoS ale ve skutecnosti je to jen shaper, ktery zadne packety neuprednostnuje. Pak RX flow control na portu zpusobi jen to, ze packet pocka ve fronte portu (priority nemaji vliv).

Zda pouzit nebo nepouzit Flow control, zavisi na tom, co mas v siti za zarizeni a co nabizi za moznosti. Nejlepsi ze vseho je samozrejme nemit zadne uzke misto, ktere by neco takoveho jako flow-control vyzadovalo.

Kdyz zapnes flow-control, tak vlastne hazis problem jednoho zarizeni na druhe.

V tom linku, co zminujes, ten tough switch ackoliv ma privlastek Pro, je zrejme switch bez bufferu (nebo spatne nastaveny - UBNT zarizeni krom AF24 neznam), takze nezvladne bursty na rychlosti te AF24 bufferovat pro 100mbps port.
Takze by ten switch musel dostavat flow control od zarizeni za 100M portem (pokud si budeme jeste hrat na to, ze AP nema buffery pred wirelessem) a sam posilat flow control na portu k AF24. Ta by mela mit bud dost bufferu (neverim) nebo zase predat flow control na druhou stranu tak az to propadne na toho Junipera, ktery by to snad mohl byt schopen bufferovat(Junipery neznam ale 2200 nejake moc nizke cislo ve jmene a informace o bufferech jsem nevygooglil, takze spis bych cekal, ze bude problem i tady). Jenze v te chvili Ti bude v bufferech stat veskery tok tou AF24 linkou na vzdalenou vez. Takze dalsi APcka, byt pripojena 1G portem nedostanou data. Sice se vylepsi spojeni na AP se 100M portem ale vse ostatni si pohorsi.
Tohle je IMHO duvod, proc cisco switche (29xx a pod) vubec nepodporuji TX flow control

Takze by ten typek by mel IMHO vyhodit ten tough switch a pouzit neco, co umozni zafrontovat par set packetu a nepotrebuje zadne flow-control. Pripadne flow control jen mezi 2ma zarizenimi (pomale AP a switch).

A dulezite je o problemu vedet. Tj mit switch, ktery pocita zahozene packety a umoznuje je vycitat v SNMP (OutDiscard).

[GRFS]

Flow Control je jen jakasi primitivni zachranna brzda v situaci, kdy buffer preteka.

QoS lze obecne resit na 2 nebo 3 vrstve OSI a vzdy je to trochu jine schema, nicmene v zasade jsou ty mechanismy podobne. Je to obecne receno o utilizaci vyuziti bufferu, kdy lze podle priority bitu v zahlavi ramce predem definovat, jak dulezita jsou konkretni data (VoIP, multimedia atp.) a jak maji byt zpracovany, protoze z toho se odviji pozadavky na prenos (latence, jitter atp) pro konkretni typ provozu. Zde vidim ono uskali. Flow Control jsou jen obycejne 64byte pauza ramce, kterymi se zarizeni snazi dat svemu sousedovi na 1 vrstve informaci, ze jeho buffer nestiha. Flow control ovsem nerozlisuje QoS a prioritu dat. Jakmile tedy dojde ke kongesci bufferu, reze to hlava nehlava.

V podstate se da tedy konstatovat, ze preplneni bufferu se da predchazet 2 zpusoby.

1) Dostatecne propustnou siti
2) Vhodnym nastavenim QoS a utilizaci provozu tak, aby nedoslo ke kongesci (preplneni) bufferu. Typicky se tak stava v nejslabsim/nejuzsim miste site.

V obou techto pripadech dtto Flow Control neni treba resit. Ve vsech ostatnich ano.