Podivné "akční" nabídky

[Návštěvník]

jeste bych k tomu dodal ze to urcite neni protokolem TCP protoze u jinych linek (optika,duplexni bezdraty apod) se tento problem nevyskytuje nebo se vyskytuje v zanetbatelne mire.

[tomus]

Je to problem TCP, ale u kabelu je to z nejakeho duvodu vice citelne, tad uz si ale nevpominam proc.

[Návštěvník]

no nevim stale se mi to nezda: kdyz uploaduji na ftp (1spojeni) tak je ping 250 a to urcite nebude problem TCP,protoze to nedela snad ani u wifi,a to je simplexni prenos

[Návštěvník]

ppk ma pravdu v tom,ze pri uploadu klesa TEZCE download, a navic leze ping na nekolik stovek ms,pak nejede voip apod.

 

Upload probíhá nějak takto: Aplikace pere data do socketu "co to dá", operační systém (resp jeho TCP/IP stack) ji zablokuje když dojdou buffery. Odesílání packetů funguje algoritmem "TCP slow start", tj TCP postupně zvyšuje rychlost, a zpomalí v okamžiku když se data začnou cestou ztrácet, což pozná podle toho že z druhé strany přestanou chodit potvrzení. V tom případě se docela razantně dupne na brzdu. Lepší TCP stacky začnou mírně brzdit už v okamžiku kdy round-trip (zpoždění mezi odesláním TCP segmentu a jeho potvrzením) začne lézt nahoru, protože to znamená že cestou se packety někde strkají do fifo fronty, jejíž velikost se zvětšuje. To je lepší řešení, protože nedojde ke ztrátě odesílaných dat, a zejména zpomalení bude plynulé.

 

Síť karnevalu má pár nepříjemných vlastností. Hlavní příčinou je velmi malá kapacita kabelu pro upload mezi kabelovým modemem a CMTS. Počítač data napere do modemu velmi rychle, a ten je musí do kabelu pomalu "odkapávat". Proto se mu velmi rychle naplní fronta na odchozím interfacu. No a protože ICMP používá stejnou frontu, uživatel to uvidí jako růst pingů. Normálně to PC včas uvidí a přibrzdí, ale v případě Karnevalu zřejmě pomalost uploadu v kombinaci s malými buffery v kabelovém modemu způsobí, že fronta přeteče a modem musí některé packety zahodit. Přirozeně na ně nedojde potvrzení, TCP zjistí packet loss, a přestane odesílat packety. Teprve po pár vteřinách začne zase opatrně zrychlovat, fronta v modemu zase přeteče, a tak stále dokola.

 

Příčinou je tedy pomalost uploadu na kabelové lince, v kombinaci s malou kapacitou paměti v kabelovém modemu. Řešením je shapovat upload přímo na počítači, a nenechat to na ubohém kabelovém modemu, protože jde asi o levný shit který to pořádně neumí. Na Linuxu viz "advanced routing and traffic control", na Windowsech asi "net limiter". Nastavit shapování o fous níž než je kapacita uploadu, a modem nebude muset nic strkat do fronty.

 

ale ze karneval lze je kravina,protoze nikde neni napsane ze je rychlost garantovana u dl i ul v tu samou dobu.

 

A nikde není napsáno, že je garantovaná i v pracovní dny.

[Návštěvník dmnc]

ppk ma pravdu v tom,ze pri uploadu klesa TEZCE download, a navic leze ping na nekolik stovek ms,pak nejede voip apod.

 

Upload probíhá nějak takto: Aplikace pere data do socketu "co to dá", operační systém (resp jeho TCP/IP stack) ji zablokuje když dojdou buffery. Odesílání packetů funguje algoritmem "TCP slow start", tj TCP postupně zvyšuje rychlost, a zpomalí v okamžiku když se data začnou cestou ztrácet, což pozná podle toho že z druhé strany přestanou chodit potvrzení. V tom případě se docela razantně dupne na brzdu. Lepší TCP stacky začnou mírně brzdit už v okamžiku kdy round-trip (zpoždění mezi odesláním TCP segmentu a jeho potvrzením) začne lézt nahoru, protože to znamená že cestou se packety někde strkají do fifo fronty, jejíž velikost se zvětšuje. To je lepší řešení, protože nedojde ke ztrátě odesílaných dat, a zejména zpomalení bude plynulé.

 

Síť karnevalu má pár nepříjemných vlastností. Hlavní příčinou je velmi malá kapacita kabelu pro upload mezi kabelovým modemem a CMTS. Počítač data napere do modemu velmi rychle, a ten je musí do kabelu pomalu "odkapávat". Proto se mu velmi rychle naplní fronta na odchozím interfacu. No a protože ICMP používá stejnou frontu, uživatel to uvidí jako růst pingů. Normálně to PC včas uvidí a přibrzdí, ale v případě Karnevalu zřejmě pomalost uploadu v kombinaci s malými buffery v kabelovém modemu způsobí, že fronta přeteče a modem musí některé packety zahodit. Přirozeně na ně nedojde potvrzení, TCP zjistí packet loss, a přestane odesílat packety. Teprve po pár vteřinách začne zase opatrně zrychlovat, fronta v modemu zase přeteče, a tak stále dokola.

 

Příčinou je tedy pomalost uploadu na kabelové lince, v kombinaci s malou kapacitou paměti v kabelovém modemu. Řešením je shapovat upload přímo na počítači, a nenechat to na ubohém kabelovém modemu, protože jde asi o levný shit který to pořádně neumí. Na Linuxu viz "advanced routing and traffic control", na Windowsech asi "net limiter". Nastavit shapování o fous níž než je kapacita uploadu, a modem nebude muset nic strkat do fronty.

 

ale ze karneval lze je kravina,protoze nikde neni napsane ze je rychlost garantovana u dl i ul v tu samou dobu.

 

A nikde není napsáno, že je garantovaná i v pracovní dny.

 

Velice pěkně napsané!

 

Zajímalo by mě, zda by bylo "prakticky" možné nahradit dosavadní paměť v kabelovém modemu za vyšší.

[tomus]

Trochu jine vysvetleni toho problemu je zde v anglictine :

http://cable-dsl.home.att.net/#Asymmetry

a jeste zde: http://homepage.ntlworld.com/robin.d.h. ... ownup.html

[Návštěvník]

Tak pri uploadu ve Windows bud ten Net Limiter, nebo uplodaovat (pouze na FTP) Total Commanderem na pozadi - da se nastavit rychlost prenosu - a funguje to dobre.

Jinak u DC uz se to myslim nejak nastavit vetsinou da a u her by se to tak hltit nemelo, ne?

[Návštěvník]

To jestli by pomohlo přidání paměti do modemu záleží na tom v čem je skutečně problém. Pokud blbne upload na nezatížené lince a rychlost stále skáče nahoru a dolu, je problémem packet loss v modemu, a přidání paměti by pomohlo.

 

Pokud je ale upload i download stabilní a pouze se rychlost downloadu sníží zhruba na rychlost uploadu, je to způsobeno tím o čem píše druhý link, co postnul Tomus. TCP na obou strnách "vidí" (a reguluje podle toho svůj upload speed) jen round-trip time, tedy součet zpoždění v obou směrech. Pozná že je vysoký ping, linka je někde ucpaná, ale už neví jestli down nebo up- proto začnou "pro jistotu" brzdit obě strany.

 

Ten první link od Tomuse by platil kdyby bylo zahlceno agregované pásmo pro upload- v tom případě by uživatel při pingu na gateway viděl sice docela nízké pingy, ale velkou ztrátovost, nezávisle na tom jak zatěžuje up nebo down. To myslím není případ o kterém se bavíme.

 

Každopádně shapovat si sám upload pár procent pod to, jak je nastaven modem, je vždy dobrý nápad. První dva problémy to vyřeší (na uploadu se bude stále držet minimální zpoždění), třetí samozřejmě ne, protože s agregací linky nic nehne.

[Návštěvník]

Turbo250

Proč ne? Větší rychlost (upload skoro o 30%) plus o 20,- nižší cena.

No ty jsi mi ale ftipalek

[Návštěvník]

Turbo250

Proč ne? Větší rychlost (upload skoro o 30%) plus o 20,- nižší cena.

No ty jsi mi ale ftipalek

 

Co je na tom "vtipneho"? Legrace je ze podle dnesni tiskove zpravy bude Volny dokonce nabizet 512k/128k za 399,- takze jsem zvedevy ktery vul si koupi 250k/50k za petikilo od Kolotocaru... :)