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.
