classic.ISPforum.cz

ahoj, řeším už delší dobu zapelklitý problém, mám na hlavní páteři alcomu MP360 kde je nastaven na ethernetu 1Gb vše funguje dobře až na to že někde v poseldní míli za několika wifinama je už rychlos jen 30-35Mb v TCP na speedtestu. Pokud tu alcomu přepnu na režim fast ethernet tak rychlost vzroste na té last mile na 40-50Mb. Po cestě mi to nikde žádné error packety na ethernetech nepíše, tak nevím v čem je zakopaný pes, je možné že 1Gb má větší háklivost na větší latenci? protože pokud postupuji z last spoje blíže do core tak rychlost neustále stoupá dalo by se říci znatleně tedy pokud poselní spoj jel 30-35Mb tak další lbíže jede 35-44Mb potom dlaší 44-58Mb další 58-77Mb a poslední už 100Mb a více.

je to normální jev a nebo je někde chyba, případně tedy nevím kde ji hledat.

Zeptám se, možná to ale nebude ono když to neháže errory na ethernetu. Ale otestovat to můžeš taky. U giga portů se musí zařízení dohodnout kdo bude master a kdo slave. Pokud se nedohodnou může to být zdroj problémů. Alcoma jdne na ethernetu přepnout to režimu slave natvrdo. Otestuj to.

flow control máš zapnutý ?

Na 100 Mbit ethernet nemáš problém lebo máš 100Mbit ethernet ale rádio ta brzdiť nebude , lebo má vyššiu kapacitu ako ethernet .
Kdežto keď to pichneš do gigabitu , tak ethernet má stále rezervu ale rádio ide na max (365mbit) . Niečo musí povedať switchu aby pribrzdil lebo je tam nejaké úzke hrdlo a ten gigabit to neprenesie , no a o to by sa mal postarať práve flow control .

flow kontrol mám zapnutý a když ho vypnu tak je to stejné
alcoma je s každé strany na gigu jako slave

pokud se vylouci bezne problemy s chybami na eth jako FCS (poskozene packety) pak je mozne, ze
1) zahazuje ta ALCOMA protoze obcas nejaky burts zaplni jeji eth frontu a radio nestiha odesilat packety vzduchem. Counter ALCOMA zatim IMHO nema zadny, ale pokud zarizeni (zrejme switch), ktere zasobuje daty AlCOMU umi flowcontrol tak staci na ALCOME i zarizeni pred ni zapnout. Pokud je switchi pred ALCOMOU mozne sledovat pocet prichozich rxPAuse ramcu tak je podle toho, zda pocet roste hned videt, zda ma radio obcas problem nebo ne. Pokud ma switch dost bufferu na ulozeni cekajicich packetu je vyhrano a problem pravdepodobne vyresen
2) ma problem (i) trasa dal za ALCOMOu. Proste stejny problem jako v minulem bode ale na dalsich trasach. Ty mohou pri packetech, ktere prichazeji zbrzdene 100mbps rozhranim fungovat OK ale pokud packety budou chodit 365mbps rychlosti uz nemusi stihat.

Tiche ztraceni packetu (kdyz nikde neni videt ten chybovy counter) se da prokazat tak, ze nekde na konci spustim tcpdump a pokusim se trasou prohnat TCP test. Pak se nad nachytanymi packety ve wiresharku nebo necem inteligentnejsim podivam jestli dochazi k zadostem o znovuodeslani TCP segmentu a vyhodnotim v jakem mnozstvi se to deje (tj jestli to ma vliv na ryclost). Vyhodnoceni je rycle protoze wireshark podobne problemy zvyraznuje.
Pripadne se daji chytat packety v nejakem bode a pak si nechat vykreslit okamzite rychlosti behem nejake rozumne kratke periody (zlomky sekundy) - z toho je videt jestli jsou na trase vyznamne burty nebo nejsou.

To retezeni burtstu se mi nezda... Podle me teda musi vzdy nestihat jen ten posledni spoj - ty spoje dale uz maji preci bursty "vyzehlene" diky "neschopnosti" toho posledniho spoje prenest tolik dat...
Tudiz by nemelo (pridanim vice spoju) klesat propustnost na TCP, pokud by to bylo tema burstama.

Berte to jen jako laicky pohled na vec

už to tu bylo napsaný jak to řešit... tohle je stejnej problém.

viewtopic.php?f=5&t=10362&hilit=tcp_problem.png&start=255#p115132

viewtopic.php?f=5&t=10362&hilit=tcp_problem.png&start=255#p115137

takže oči otevřené chlapci a neukvapovat se v závěrech. Nejlepší je vzít papír a tužku a kreslit. Ject RBčko po RBčku v síti a testovat proti hlavní bráně. Hlavní brána vám poskytne plnej průtok na jedno TCP i když jede na max (pokud nemáte vyloženě plečku na bráně). Mít na paměti že 400MHz procáky daji max 40Mbit na přijmu když jsou ve formě a 680MHz dají něco nad 50Mbit. Potom si to pěkně nakreslit včetně všech kabeláží kudy to teče a popsat rychlostmi. Pak dojdete na bod kde to hnije. Taky je dobrý koukat na UDP test a třeba ho omezit na 10, 20, 30Mbit a sledovat kolonku "lost packets" která hodně napoví. UDPčko nezajimá že data přišly špatně, zajimáho že dorazili nicméně to že došly špatně se napočítá a je to v tý kolonce vidět. Dal bych ruku do ohně že tam vždy nějaký packety vadný byli jenom jsem si nedokázal vysvětlit proč. Jestli tedy ztrátoval switch, tak se to tim dalo poznat.

jelikož přepínáš alcomu na fast a jede to lépe... budeš mít totálně stejný problém takže zbejvá jenom najít kde. Zaměř se na sekci testu s omezeným UDP a lost packet.

jo ale řekni mi jak je možné že ve fast to tedy jede jinak jak v gigu, proč?

já to tam všechno psal viewtopic.php?f=5&t=10362&hilit=tcp_problem.png&start=270#p115342