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.
Telefon: +420277270707
☎ O2: +420277270772
☎ T-Mobile: +420277270773
☎ Vodafone: +420277270777
Dostupnost: Po–Pá: 8:00–18:00
E-mail: info@dsl.cz
