Do diskuse momentálně není možné vkládat příspěvky. Plná funkčnost bude obnovena v nejbližších dnech. Děkujeme za pochopení.
Úvod > Diskuse > Obecná diskuse > Proč mi při max uploadu klesne download ????

Proč mi při max uploadu klesne download ????

TheIF (4.8.2005 09:33:21)

Mám NEXTRU 1FUN 1024/256 přes ČT moden ZyXEL 630C Když něco uploaduji, ať torrenty nebo na web tak když rychlost uploadu neomezím tak to sice uploaduje 25+KB/s ale na stejnou hodnotu spadne i download :-( a když jsem rychlost uploadu omezil na 21KB/s tak klidně přitom downloaduji 110KB/s To je normální stav u ADSL ???????

Anonym (4.8.2005 10:03:23)

Je to vlastnost TCP/IP protokolu,když se vytíží upload,tak se nestihnou včas odeslat potvrzovací pakety pro download a tím server,který vám posílá data na download sníží rychlost a vám spadne rychlost na downloadu.

y2k (4.8.2005 12:34:22)

BoolShit !!! ADSL v podání ČR je, bylo a pravděpodobně i bude pouze poloduplexní !! Což v paxi znamená, že upload se dělí o čas s downloadem. Nikdy se nestane, že by pakety tekly v jeden čas oběma směry zároveň. To samozřejmě v důsledku znamená značné zdržení při vytížení konexe.

Nargon (4.8.2005 12:47:29)

Adsl je technologicky fullduplex, protoze pro upload pouziva jine frekvence nez pro download. Takze muze pouzivat Download a upload na maximum soucasne. Ale to zpomaleni je opravdu zpusobeno vlastnosti TCP/IP protokolu.

y2k (4.8.2005 13:34:53)

Technologie přenosu je jedna věc, ale omezení a nastavení jednotlivých směrovačů a serverů na bázi Ethernetu je věc druhá. Zkus si na domácím ethernetu uměla nastavit rychlost 512/128 a porovnat vytížení kapacity přenosu. Rychlosti do posledního bajtu dodržíš takřka bezezbytku. Nepatrně se zvýší odezva (to již má na svědomí protokol TCP/IP), ale rozhodně to nebude to samé, jako známe všichni z našich přípojek. Běžně na domácím ethernetu je odezva max 3 ms a to už je strop na starých plečkách. Při rychlostním omezení se odezva zvětší tak na cca 20ms, což je adekvátní transportu protokolu TCP/IP.

Honza (4.8.2005 13:48:00)

Jezis to prece neni mozny. Proc sem pisou lidi ktery nemaji ani TUSENI jak to vlastne funguje... Napadlo te, kde si vlastne to "umele omezeni" simulujes? Nargon a Anonym maji pravdu. Pokud vytizis pasmo jednim smerem, neni v nem misto ani na potvrzovani paketu druhym smerem. A proto odesilaci server omezi rychlost posilani. Jinak to se netyka UDP, kde vrstva zadnym zpusobem doruceni paketu UDP nezajistuje a nekontroluje. Nicmene i zde je treba pakety kontrolovat a tak to dela samotna aplikace ktera je prijima (vetsinou, tedy DC ano, hry treba ne). Takze i zde je nutnost ony potvrzovaci UDP pakety aplikace dostat zpet k odesilateli a to proste pri plnem vytizeni uplinku nejde, resp. jde spatne...

y2k (4.8.2005 13:59:30)

A víš Ty něco o prioritě paketů ?? Jestli ano, tak víš, které pakety se vždy prioritizují ? Jestli ano, víš jak velký je potvrzovací paket ? A kde omezení simuluješ nerozhoduje, záleží čím a jak toto simuluješ. Při správné funkci QoS a fulduplexní lince Ti garantuju, že zdržení těchto potvrzovacíxh paketů bude tak malé, že jej prakticky ani nepocítíš a linka poběží v obou směrech na minimálně 95% svých deklarovaných rychlostí ! Howg !

Anonym (4.8.2005 14:05:46)

Proč jsi ten qos nenastavíš sám?ISP pouze poskytuje konektivitu a je mu jedno jakým způsobem si tam posíláš data (on taky každý má jinou představu o qos).Jak si zaplníš tvoji šířku pásma a jakým datovým provozem je tvoje věc a ty si určuješ zda vytížíš upload na maximum uživatelskými daty nebo tam necháš nějaké místo i na servisní pakety.

nick (4.8.2005 17:01:24)

jde o to, ze ADSL je v CR realizovano pomoci PPTP tunnelu. Potvrzovaci pakety (ACKs) se pri odesilani pribaluji k paketum ostatnim, ktere opousteji tvuj modem, do jendoho baliku. Tento balik ma nekolik KB a je proto narocnejsi ho odeslat. Kvuli tomu taky stoupa doba odezvy na ADSL (pac aj icmp/udp pakety se pribaluji do PPTP baliku). Proto logicky: uploadujes->odesilas hodne dat->PPTP baliky jsou velke->jejich odeslani zabere vice casu->odezva se zvetsuje. Modem nedela zadne QoS v tom smyslu, ze by ACKs posilal zvlast (v malych balicich) a prednostne. nick

Anonym (4.8.2005 20:57:15)

Absolutní nesmysl. Takovou prasárnu by ťelemat neudělal.

nick (4.8.2005 21:27:40)

tohle je klasicke PPTP, jinak taky receno jeden ze standardu VPN... takhle bezi aDSL uz od sveho zacatku v cechach. No jen si vzpomen, jaky ty pripojeni nastavujes na svem modemu... nick

nick (4.8.2005 21:32:10)

jinak tady to mas hezky aj vysvetlene: http://computer.howstuffworks.com/vpn13.htm ;) nick

Honza (4.8.2005 22:19:58)

Ty si emil... :P Co si nejdriv alespon neco precist nez tu zacnes fantazirovat?

y2k (5.8.2005 16:42:01)

A co takhle okusit trochu té praxe, než jen nesprávně papouškovat nějaké výňatky od podobně chorobně myslného člověka jako jsi Ty, které si vyčetl někde na síťi ?

Honza (5.8.2005 21:30:25)

Praxe je bohuzel jedna z veci ktera ti zjevne chybi. Dalsi jsou schopnost cist a schopnost uvazovat. Meles pate pres devate, nic ti nerikaji rozdilne sitove vrstvy a ani nemas predstavu jak a co k cemu vlastne slouzi. Kupříkladu Radius server slouží k ověřování identity, nikoliv k přímému řízení datového toku. Navíc proč by měl ISP kdekoliv u něj uměle vytvařet špunty v podobě asynchronního přenosu? Z fora jsem pochopil že už jsi uznal fakt, že až k prvnímu serveru ISP je linka po celé délce od tvého PC plně duplexní...

y2k (5.8.2005 22:25:46)

Ano, v posledním bodě se spolu shodneme. Poslední míle je FullDuplex.

Honza (5.8.2005 23:54:38)

Tak super. A ted se jiste shodneme i na tom, ze technologicky, jelikoz posledni mile je realizovana pres obyc. dvojlinku, asi bude nejslabsim clankem reseni ze? Proc by tedy nekdo umele vytvarel po ceste nejake poloduplexni useky? Nehlede na to, ze v pripade ze pokud rychlost techto neexistujcich "halfduplex" useku bude dostatecne rychla, nemas jakekoliv spomaleni na konci linky (modemu) poznat... :P Kde je podle tebe cast linky, ktera je provozovana v poloduplexnim rezimu?

Honza (5.8.2005 23:58:02)

A jeste dotaz: Jak to, ze kdyz mas treba downlink a uplink 100kB/s a 25kB/s a omezis pri plnem vytizeni uplinku tento na 23kB/s, tak dosahnes maximalniho vytizeni v obou smerech? Tedy realnych 100kB/s down a 23kB/s ven? Myslis ze ty dva prenesene kilobyty navic by ve smeru od DSLAMu do internetu hraly roli?

nick (6.8.2005 00:43:06)

moje rec, prace jsem chtel argumentovat tim samym. stahni si netlimiter. omez si global UL i DL na 90% rychlosti linky a uvidis, ze kdyz ted zapnes stahovani i odesilani tak oboje se presne na tech 90% procent bude drzet (myslim 90% realne rychlosti linky, pac iOL 1024 nejede ani omylem 128kBps, ze?:)). Pokud to nekdy klesne (na vterinu) bude to zpusobeno ztratou paketu nekde po ceste. Proc 90%? Zbylych 10% bohate staci na odesilani ACKs... ;)

Lolek (4.8.2005 22:04:57)

no ty si ale LAMA!!!! adsl pouziva dve samostatna pasma pro UP i DOWN, a anonym a Nargon mají pravdu. Nekdy se podivej na rozdeleni pasem pro adsl, tusim ze je to tady na dsl, a je tam pro lamky za adsl pouziva jedno pasmo pro up a druhe pro down. A jestli si dobre vzpominam, tak pred casem se to tady resilo, a ty si tady FURT STEJNE BLIL! BTW omlouvam se ze pisu bez hacku a carek, ptz. sem mimo cr a nemam ceskou klavesnici

y2k (4.8.2005 23:25:26)

Ehm, to, že má ADSL své vyhrazené pásmo pro Up a Down, ještě neznamená, že musí data téct v jednu chvíly oběma směry zároveň. Trošku jsi LUMO :-) pozapoměl, že z ústředny to již nevede po měděném páru a že tento následný přenos má své zákonitosti dle nastavení na rádiusech a serverech hlavních poskytovatelů. Takže jsem laskavě přestaň plést pásma DSL. Jestli jsi pozorně četl, tak jsem psal doslova "ADSL v podání ČR je, bylo a pravděpodobně i bude pouze poloduplexní ". Né ADSL všeobecně, či přenosová norma ADSL !

swan (5.8.2005 09:52:53)

Nenapadlo te ze se mohou pakety bufferovat nez prejdou na tu udajnou poloduplexni linku ?

y2k (5.8.2005 16:39:28)

Ověřovacé součty (chceš li pakety) se opravdu buferovat moc nedají. Pak by ověření uržitého bloku ztratilo jaksi smysl.

Honza (5.8.2005 21:35:25)

Lol, Hele, kolik Ti je a co delas? Ja jen jestli ma cenu se snazit presvedcit 16ti leteho fracka co neni schopen si nic sam precist nebo vyzkouset...

y2k (5.8.2005 22:24:44)

Jestli sis nevšiml, tak já Ti nenadával a nesnižoval Tě. Jinak 30

Honza (5.8.2005 23:50:52)

To je blbost. Ve 30ti uz ma clovek dost rozumu na to, aby kdyz mu x lidi tvrdi ze vec se ma jinak nez si mysli on, aby se nad tim faktem zamyslel a ev. si ho z duveryhodnych zdroju nastudoval. Ve 30ti tezko nekdo bude dokola bazirovat na blbostech ktere nema podlozene a kterym nerozumi...

Nargon (6.8.2005 00:20:30)

Tady si reakci neodpustim. Staryho psa novym kouskum nenaucis.

TomM (6.8.2005 14:11:27)

a mě by zajímalo co na to pan IOLák, ten se tady jenom tiše směje a radši by mohl uvést věci na pravou míru, tedy tak jak to tvrdí všichny kromě y2k.

Anonym (4.8.2005 19:49:17)

Větší blbost jsem fakt nečet prý vlastnost TCP/IP - cha cha cha

swan (4.8.2005 22:51:08)

Mozna to zni jako nesmysl, ale je to tak. Po prijeti urciteho mnozstvi dat je nutno poslat potvrzeni. Myslim ze to na urovni paketu.

nick (5.8.2005 07:22:21)

proc ti, co si umej sami zapnout pc se hned povazuji za nejvetsi machry? nevim, asi typicka ceska vlastnost. nez tu zacnes neco vykrokovat, tak si radsi precti toto: http://en.wikipedia.org/wiki/Transmission_Control_Protocol O ACKs se tam mluvi snad v kazdem odstavci. BTW: jak chces prenaset data, aniz bys vedel, ze je druha strana dostala v poradku? Si myslis, ze kdyz stahujes 10MB, tak ten soubor dorazi hned napoprve cely a v poradku? Blbost. Ty ho sice vidis, ze je OK, ale jemu stazeni predchazi velke mnozstvi usili TCP/IP. Nekolik paketu VZDY dorazi spatne, proto se posilaji znovu, ale to ty uz nevidis, to uz obsluhuje protokol sam. nick

Anonym (5.8.2005 07:35:19)

Další chytrák se ozval, v článku není nic o tom, že je to vlastnost TCP/IP

nick (5.8.2005 11:23:47)

vynatek z textu: ----------------------------------------- The TCP module at the far end sends back an acknowledgement for bytes which have been successfully received; a timer at the sending TCP will cause a timeout if an acknowledgement is not received within a reasonable round-trip time (or RTT), and the (presumably lost) data will then be re-transmitted. ----------------------------------------- staci? nick

Anonym (5.8.2005 20:35:28)

To je jasné, že když potvrzení nedorazí zpět tak se vyžádá zopakování zaslání dat a klesá rychlost, ale my tady řešíme, že ADSL se někomu chová jako half-duplex!!! A svádět to na TCP/IP je nesmysl (TCP spojení je Full duplex - můžeš jak vysílat tak přijímat).

Anonym (5.8.2005 21:13:57)

ty vubec nemas poneti vo cem kecas lol

Honza (5.8.2005 21:24:17)

Resime to, proc pri neomezeni rychlosti uploadu padne i rychlost downloadu. Tedy alespon na toto se ptal autor threadu. Jediny duvod tohoto faktu je, ze ACK pakety z jeho pocitace nemaji diky vytizenemu uploadu dostatek prostoru dostat se na pocitac ze ktereho se data tahaji (bud se tam nedostanou vubec nebo dorazi pozde) a odesilajici pocitac tak sam snizi rychlost odesilani dat, protoze logicky usoudi, ze dochazi NEKDE k zahlceni linky. Stejny mechanismus slouzi tedy k adaptaci rychlosti odesilani tak, aby nedochazelo k prehlceni prenosove linky. Nebo si myslis, ze kdyz mas klasicky stary analogovy modem, ze ti server porad posila data treba 100mbit/s a ty si doma z toho co nahodou projde skladas vysledny obsah? :P

Anonym (5.8.2005 22:03:28)

me o tom nemusis poucovat moje reakce byla ne anonymovy kecy o halfduplexnosti adsl a o tom ze tcp/ip (krome toho ze mluvi o spojeni tam kde se jedna o protokol) je dycky fullduplexni coz je hovadina za kerou by se prdel myho psa stydela

Joo (5.8.2005 22:31:18)

Opravdu ta diskuse nemá chybu, poslední dobou se pročítáním dost bavím... :)))

Honza (5.8.2005 21:17:45)

Mohu Te anonyme ujistit, ze takto se chova kazda i synchronni linka kdyz je jeden smer vytizen blizko maxima kapacity... Dale DSL je proste "od prirody" full duplex nebot frekvenci pasma pro uplink a downlink se NEPREKRYVAJI a muze tedy soucasne dochazet k prenosu v obou smerech. Schvalne si zkus omezit stahovani tesne "pod" strop tve linky a zaroven uploaduj opet tesne pod maximalni kapacitou linky. Uvidis ze oba smery pojedou skutecne blizko toho fyzickeho maxima. Tim si sam potvrdis ze se jedna o full duplex. Dal bych si dovolil poznamenat "full duplex" a TCP ma spolu spolecneho asi jako "obousmerna silnice" a "auto". Tzn neplati, ze AUTO je automaticky provozovano na obousmerne silnici... Ano, hloupy primer...

Karel (5.8.2005 21:48:44)

Nevim jak vy ale ja sem to ted zkousel a primaximalnim uploadu mi jede na maximum i download mam ČT sprint uploadoval jsem na ftp rychlosti 25,5KB/s a downloadoval doubor ryhlosti 110KB/s ale rapidne se pritom zhorsil ping 250-310ms na seznam

Lukas (5.8.2005 21:53:20)

Rovněž mi to chodí tak jak má můžu odesílat a stahovat na maximum (třeba když sosám v DC++, tak nemusím připojení limitovat), když limituju, tak jen proto, abych nebyl brzo postižen FUPkou

Anonym (5.8.2005 22:01:52)

25,5 je jeste malo

swan (5.8.2005 23:28:12)

Neni presna hranice 32kB/s, ale ta rezerva 6.5kB/s je fakt jeste velka. Me jede download v pohode i pri rezerve uploadu 2kB/s.