classic.ISPforum.cz

Ahoj,
řeším se známým který má ode mě net problém s rychlostí na jedno spojení.

topologie je asi takováhle:

CRS-> 1S10 (150M) -> CCR -> ericsson (450M) -> shaping x86 -> gateway x86 -> internet

když dám btest z CRS na gateway na jedno spojení tak není problém vytáhnou max. co da ta 1S10, btest s jedním spojením na 81.19.2.146 už dá ale max jen 15-20M

Btest z gatewaye na 81.19.2.146 ale dá na jedno spojení 220M.

napadá Vás někoho čím by to mohlo být?

za posledni dobu uz nekolikaty prakticky stejny dotaz. TCP nedosahne ocekavane rychlosti ze 2 duvodu:
1) prilis velka zpozdeni mezi koncovymi body (diky nejake defaultni velikosti TCP window a potvrzovani se to proste vic nerozjede)
2) ztratovost po trase. Takze pokud jsou v ceste prvky, ktere zodpovedne hlasi vsechny nezadouci stavy u packetu (chyby, a hlavne zahozene packety) staci projit jejich statistiky na prislusnych rozhranich. Pokud se tem prvkum verit neda nebo pozadovane informace neposkytuji, pak zbyva jen uz nekolikrat zminovane odchyceni packetu z rychlostiho testu a analyze TCP spojeni (opkovane segmenty, nedorucene packety, graf rychlosti k odhaleni burstu atd). Samozrejme je mozne problem resit metodou vymeny switchu atd na slepo. Ale jednak musim tusit, kde se to chova jak nema a hlavne musim mit menit za co (za neco co je overene a funguje). Navic ten problem nemusi byt zpusoben nezadoucim chovanim jen v jednom swoitchi atd.

Kdybych si mel tipnou, kde zacit hledat tak po vylouceni toho vetsiho zpozdenei bych zacal v tom miste, kde dochazi k nejvyssi zmene rychlosti smerem dolu. Cili ta 1s10 a CCR pred ni. Nevim jestli ten Orcawe umi reportovat zahozene packety, pokud ne da se to delegovat na prvek pred nim pomoci FlowControl.
PS: nevim co je presne mysleno tim shapingem na x86 - pokud to neni HTBcko na Linuxu ale MT, tak bych prvne proveril, jak maji ty shapery dlouhe fronty. Jestli defaultni, tak je to jen par packetu a to nestaci.