AF 24 - Packets with Errors

[Dalibor Toman]

no, flow control ne flow control, U alcomy nebo 200Mbit orcave žádný flow control nepotřebuji a chyby nevznikají.

BTW: to ze ALCOMA nema zadny counter pro dropy/discardy neznamena, ze se na ni zadny packety neztraceji...

O to jde. Samozřejmě máš pravdu že flow control je "dobrý" ale jak kdy. Ono ti to sice nazasere radio nějakým peakem ale za to ti to může zablokovat celou flow control trasu předtim takže nezadropuje pojítko ale něco jinýho kde přeteče buffer.

mikrobursty se musi IMHO resit dostatecne dlouhym bufferem na zarizeni ke kteremu je ta ALCOMA pripojena, ne tim, ze se kaskadovite posilaji rxPause ramce celym retezcem (krome toho napr bezne Cisco switche ani flow control v transmit modu neumi). Osobne radeji vidim poztracene packety na switchi, kde je muzu kreslit do grafu nez to nechat na radiu, ze ktereho tu informaci neziskam (a pak zit v bludu, ze se nic neztraci)...
A tu frontu je mozne plnit diky flow control nebo nastavenim nejakeho shaperu, ktery bursty vyhladi.

Zamozřejmě by to chtělo podívat se, co je RX FCS Error. Podle HP je to paket s nekorektním kontrolním součtem který většinou vzniká když jedna strana je linknutá na full a druhá na half. Pak to řeže pakety a nesedí součty. V jiný souvisloti by se tedy poškozený pakety typu FCS error ukazovat neměly.

poskozeni packetu (coz je pricina nesediciho kontrolniho souctu) muze nastat samozrejme i z dalsich duvodu (kabel, konektory, ruseni, vadna sitovka,...)

[farmar]

Ahoj páni,
prepol som to do half duplex plus zapnuty flow control a ide to dobre.
Dokonca aj nadržaný CSkar , ktorý ak nema na CSku v grafe rovnu čiaru, tak potvrdil, že ide to skvelo.

Ponaučenie: momentálne kupujem ďalší spoj, ale bude to SIKLU dúfam, že tam to bude bez problémov

Vďaka.

[GRFS]

Ono je jedno co to je za radio, pokud vyloucime bugy ve firmware u konkretniho produktu, pripadne HW problem.

Dulezite je si vzdy zkontrolovat nastaveni obou stran LAN portu, ktere proti sobe negociuji. Jedno zda jsou v auto rezimu, nebo obe strany fixne nastavene. Musi mit ale shodne nastaveni, jinak spolu nemluvi vubec, nebo blbe

Osobne bych preferoval full duplex, nebot pri halfu jde logicky propustnost dolu. Pokud zarizeni u GE portu linkuje na half a na full vubec, nebo spatne, pricemz porty jsou nastavene spravne, muze to ukazovat taky na problem s nekvalitou kabelaze, pripadne PoE injektoru. Je treba nenechat se zmast proklamaci vyrobce, ze PoE umi Gigabit. V rezimu half duplex dtto nelze vyuzit maximalni propustnost AFka, coz je udavanych 700Mb obousmerne. A to by mi teda vadilo, za ty prachy

U lepsich krabicek se daji v auto rezimu ovlivnit rychlosti a typ duplexu, ktere propaguje LAN port partnerovi pri vyjednavani(negociaci). Da se tak napriklad nastavit, aby spolu nemluvili v half-duplexu, nybrz jen na full duplexu. Ale to asi neni priklad AF24

Nektera zarizeni dokonce na gigabitu half-duplex vubec nepropaguji a umi linkovat jen na full-duplex. Takze s tim vsim je treba pocitat.

[GRFS]

O to jde. Samozřejmě máš pravdu že flow control je "dobrý" ale jak kdy. Ono ti to sice nazasere radio nějakým peakem ale za to ti to může zablokovat celou flow control trasu předtim takže nezadropuje pojítko ale něco jinýho kde přeteče buffer.

mikrobursty se musi IMHO resit dostatecne dlouhym bufferem na zarizeni ke kteremu je ta ALCOMA pripojena, ne tim, ze se kaskadovite posilaji rxPause ramce celym retezcem (krome toho napr bezne Cisco switche ani flow control v transmit modu neumi). Osobne radeji vidim poztracene packety na switchi, kde je muzu kreslit do grafu nez to nechat na radiu, ze ktereho tu informaci neziskam (a pak zit v bludu, ze se nic neztraci)...
A tu frontu je mozne plnit diky flow control nebo nastavenim nejakeho shaperu, ktery bursty vyhladi.

+1, plne souhlasim za predpokladu, ze buffer v radiu je dostatecne "dlouhy", aby mikrobursty zvladal. To je teorie, lec praxe je trochu jina, nebot za vsim je treba hledat penize. Je proto treba vnimat, ze s "delkou" bufferu roste i latence a to radio je taky timpadem o par korun drazsi. Vyrobci radii jsou tedy mezi 2 mlynskymi kameny, nebot vsechny uvedene parametry, jsou pro konkretni aplikace kriticke.

Nelze tedy cekat, ze radio s GE rozhranim, ktere ma ve vzduchu propustnost, rekneme 200Mb, bude schopno resit 100% pripadu s mikrobursty prichazejicimi po LAN interfejsu s propustnosti 1000Mb/s. Proto je tam flow control. Na strane sitovych prvku musi byt samozrejme aktivni shaper tak, aby k podobnym pretokum dochazelo minimalne a pak se neni treba bat toho, ze se budou pauza ramce prelejvat celym retezcem. To vetsinou nastava prave v pripadech, kdy jsou sitove prvky za radiem "nepolibene"

Ono se to nejvice tyka dynamicke zateze, tj. typicky internetoveho provozu. Z testu, ktere jsem historicky delal na ruznych technologiich a konfiguracich mi vyslo, ze s aktivnim flow control lze resit zahazovani ramcu v retezci typicky v pripadech, kdy je kapacita nejslabsiho clanku v retezci, typicky radio, vyuzivana cca nad 70% jeho maxima. S vypnutym FC jiz radio zahazovalo, protoze mikrobursty nebylo schopno zvladnout svym bufferem. Se zapnutym FC a spravne nastavenymi sitovymi prvky bylo mozne vyuzit kapacitu radia cca k 90%, bez ztraty jedineho ramce. V celem retezci podotykam.

Nicmene existuji i extremni pripady nepomeru velikosti bufferu, kdy radio neni bezeztrat schopno prenaset bez aktivniho flow control ani 50% sve nominalni kapacity. Je to vzdy otom, na cem konkretni vyrobce setril a k jakym aplikacim puvodne to radio vyrabel.

Jinak problematika flow control je jeste trosicku slozitejsi, protoze existuji pripady, kdy je primo nezadouci tuhle funnkci pouzivat. Napriklad pri vyuzivani Sync Ethernet funkcionality a prenosu synchronizace po eth rozhrani. Ale to je na dlouhy psani ...