classic.ISPforum.cz

Chcel by som sa opytat v com moze byt problem , ak je pred spojom na rocket M5 Gigabit switch priepustnost merana btestom je okolo 50mbps , ak sa ale tento swtich vymeni za 100vkovy priepustnost je 93mbps . Vadny switch to urcite nieje , vyskusane viacero giga switchov . Skor to vypada na nejaku zahadu 1Gigabit vs 100mega , ale co to sposobuje ? Kolega mal prednedavnom podobny problem , tak som si to nasimuloval na stole a fakt sa taketo haluze deju . On mal sice spoj na airfibroch a pomohla jedine vymena switchu pred spojom na AF za gigbibovy SG1016 , hociaky iny gigabit switch sposoboval zlu priepustnost .




Btest

ten rocket ma jen 100ckovy port? (neznam nepouzivam)
Mereno na TCP nebo na UDP?

Je mozne ze ten prvni switch ma vic bufferu na frontu pro port. Takze pokud ma na portu 1gbps zustane to na druhem switchi a ten tech packetu zahodi vic. Kdyz je druhy switch jen 100vkovy tak prvni switch dokaze nezahodit tolik packetu takze TCPko bezi lepe.

Tenhle problem by mel jit najit v error counterech (discards, drops, pripadne nejake buffer overflow apod). Pokud vsechna zarizeni po ceste je zpristupnuji a poctive je aktualizuji. Sazmozrejme se predpoklada, ze jinak je vse OK (duplex na obou stranach kabelu , zadne CRC atd)

Ano ten rocket ma len 100kovy port . Merane na TCP , na UDP tento problem nebol ani pri raketach ani u kolegu na AF , problem sa prejavuje len na TCP . Ten SG1016 ma fak bohate statistiky Je tam len badpaket a tie su na nule . Dalo by sa to odchytit , napr wireshark atd ?

wireshark lze pouzit. Ale bylo by potreba chytit packety pred a za podezrelym mistem a porovnat. V obou pripadech by mel wireshark signalizovat nejake problemy s TCP. Opakovane/duplikovane segmenty, chybejici segmenty. Cili je mozne overit, ze nejaka data se posilala Nkrat a pred problemovym mistem prokazatelne packet/segment byl a za nim uz ne.

Dal lze ve wiresharku vygenerovat graf rychlosti v bytech - pri dostatecnem casovem rozliseni je videt o kolik to pred problemovym mistem prekracuje 100mbps (jen je treba dat pozor na znaceni os - je tam/byl nejaky problem s meritkem)

Pred ten cisco SG100 som dal rb450G v bridge , ziadna zmena v priepustnosti . Potom som na potre v RB na ktorom je pripojene to cisco zapol flow control , priepustnost isla hore , ale na port chodi s toho switchu docela dost RX pause . Neposiela ten switch pause stale aj ked protistrana flowcontrol nema zapnute ? Toto tam napocitalo za minutu btestu .

Skusil som to zo 100mbps switchom a ten ziadne pause neposiela .

takze to cisco se problem s bufferem snazi prehodit na zarizeni pred sebou tim ze zada o pausu. Pokud prvni switch nereaguje, cisco dostava dal packety a zaplni odchozi frontu na 100mb interfacu. Zacne dropovat. Pokud prvni switch reaguje na rxPause, pak mozna zahazuje on a nebo zarizeni prd nim (pokud i prvni switch zazada o pauzu).

Podla vas ma ten SG1016 bufer 512k na port ? Pre cely switch by to bolo asi malo . http://www.tp-link.us/products/details/ ... 016DE#spec

Cisco SG100 má na celý switch 512 KiB RAMky (stejně jako ten TPlink). Takže radostně posílá poause rámce, když dostane trochu datovou nakládačku a musí dělat konverzi rychlosti. Navíc má to Cisco statický anti HOL, takže si těch 512 KiB vyděl počtem portů, tolik je reálný bafr na jeden port...

Urcite ma ten tplink SG1016 websmart 512k na vsetky porty ? Zda sa mi to dost malo , kedze niektore lacnejsie tplinky maju buffer 2MB na switch . Preto mi je divne ze by mal tento 512k na 16 portov . Ak by mal 512k na port, tak by to davalo zmysel , ale 512k na cely switch je asi zufalo malo .

To bych neřešil, to je jen o tom, jaké čipy se podařilo výrobci tam slepit k sobě a jak moc to oškubat...
Ber to tak, že záleží na tom, jak tne switch bude používán a jak umí tu pamět použít. Pokud třeba máš opravdu provoz, že používáš hlvaně jen jeden port 100 Mbps a k tomu 1 Gbps uplink, tak swithc s míň paměti, pokud je sdílená a umí ji skoro celou přiřadit jen na ten jedne ucpávaný prot, tak ve svém testu dosáhneš lepšího výsledku, jak se switchem s pamětí větší, ale napevno podělenou na porty. S tím switchem zase bude lepší vásledek v jiném přenosovém scénáři.
Jinak předpokládám, že ti hlavně tečou ve směru od RB1100AHx2 do toho rocketa (přípdně do dalších na dalších portech), tak už na tom RB1100AHx2 ořízni shapingem na 100 Mbps to, co teče směrem na toho Rocketa a využij RAM v tom routeru. V tom switchi ty bafry pak už jen slouží k vyrovnávání drobných fluktuací a nemá důvod dropovat/pauzovat nadřazený prvek.

Zaujimave zistenie, nemanazovatelny switch s podporou IEEE 802.3x sa dozaduje flow control pause stale , proste pozaduje pause aj ked protistrana nema povolene flow control .

Testovane u kolegovcov na nejaky xeon server MK <-----> menezovatelny TPlink switch <-----> cisco switch SG100 <------> NanostationM5 <------> NanostationM5 <------> PC

1.Menezovatelny switch ma defaultne vypnute flow control , cize test bez zapnuteho flow control na nom , test na speedtest.net vysledok download 30mbps

2.Menezovatelny Tplink zo zapnutim flow control na porte na ktorom je pripojeny SG100 , test na speedtest.net vysledok download 80-90mbps

Cize zaver je asi taky ze kazdy nemanazovatelny switch pozaduje mat od protistrany zapnuty flowcontrol , vyskusane viacere nemanazovatelne switche a vsetky sa spravali stejne . Napada ma ale situacia ak by bol pred SG100 napr nanobeam , ako sa dohodne SG100 s nim ? Nech pozeram ako pozeram nevidim kde by sa dal flowcontrol na nanobeam zapnut . Cize moze sa stat ze ten SG100 zacne posielat pause do nanobeamu , ale nanobeam nevie co stym , stejne ako test v bode 1 . Vysledok bude pravdepodobne stejny - degradacia downloadu .