Lupa.cz  »  Stalo se: na obzoru je AžDSL  »  Názory  »  Vlákno

Vlákno názorů k článku Stalo se: na obzoru je AžDSL od Honza - pekna spekulace, ale ten zaver, kde je zmineno...

  • Článek je starý, nové názory již nelze přidávat.

  • 18. 8. 2008 12:45

    Honza (neregistrovaný)
    pekna spekulace, ale ten zaver, kde je zmineno ze 512kbps na uploadu sotva uzivi 8192kbps download je pekna hloupost. *mbit downlad "vyzije" i s uploadem 64kbps cili 8kB/s a je to az az. Si to vyzkousejte podle netlimitru pri rychlosti stahovani cca 850kB/s to uploaduje cca 1-2kB/s... Cili pro 16384kB/s je 768kbps az az. Problem je pokud ten upload skutecne potrebujete (upload fotek do fotosberny) pak ta rychlost je dost udesna...

  • 18. 8. 2008 14:20

    anonymní
    Pan je specialista ze ?

    Protoze to kolik uploadu je treba k downloady velice mnoho zalezi na protokolu ktery je pouzit. Existuji protokoly, ktere potrebuji vice, nektere potrebuji mene.

    I jen ciste tcp komunikace vyzaduje potvrzeni kazdeho paketu => pokud se budou prenaset pakety 1500B velke, tak na kazdy z nich se zpet musi prenest alespon hlavicka s ACK coz je nejakych 40B. => 1:37 je +- ten kriticky pomer.

    Jenze takhle velke pakety se prenaseji spis vyjimecne, probiha spoustu jine komunikace, kde se pouzivaji mensi pakety, rekneme ze celkovy prumer se muze pohybovat nekde kolem 1000B/paket a tam uz je pomer 1:25.

    Pokud nad to pouziju nejaky nevhodny protokol (napr http na prenos souboru) tak se to jen zhorsi, pak uz dojde k limitovani. Nehlede na to, ze k limitovani downloadu uploadem dojde samozrejme drive nez je na uploadu dosazeno onoho maxima + na DSL samozrejme nikdo nic negarantuje => maximum upladu muze byt samozrejme uplne nekde jinde (realne v pripade te 768 bych to videl nekde kolem 1/2M).

    Tudiz jsem si na 90% jist, ze na lince s takovymi parametry nelze na maximalni rychlost dosahnout ani v pripade optimalnich HW podminek.

  • 18. 8. 2008 14:31

    alblaho (neregistrovaný)
    HTTP je na přenos souborů stejně dobré jako FTP, prostě se to prožene TCP spojením a to je vždycky stejné, ne?

    Navíc ACK se nemusí posílat pro každý paket extra, stačí poslat čas od času s významem "až do packetu N všechno OK". TCP to takhle dělá.

    Čímž nechci hájit asymetrii, jen říkám, že v některých případech s nějakýma 20:1 vystačit jde. Ale osobně považuji za hranici 8:1 protože občas po netu zálohuju.

  • 18. 8. 2008 17:09

    anonymní
    Navíc ACK se nemusí posílat pro každý paket extra, stačí poslat čas od času s významem "až do packetu N všechno OK". TCP to takhle dělá.

    Vím o tom, že se při odesílání paketu nečeká na potvrzení, ale posílají se rovnou další (říká se tomu okno). Ale že by se potvrzovaly pakety hromadně, to je pro mně novinka.

  • 18. 8. 2008 18:51

    RaStr (neregistrovaný)
    V TCP se samozrejme potvrzuje kazdy prijaty paket. To okno slouzi pro kompenzaci latence. Delky paketu jsou nasleduji, TCP DATA - 1448B, IP packet - 1500B, potvrzeni - 52B, pri linkove rychlosti 16Mbps se dostavam na max. 1333 paketu za sekundu (pocitam 8 bitu na byte) k tomu je potreba cca 555Mbps upload na potvrzovani, takze tech uvadenych 768 by mohlo stacit. Vetsi problem ale dle mych zjisteni byva s latenci, zrejme kvuli agregaci ma ADSL nenulovou ztratovost a pri latenci 50ms a MTU 1500B pri ztratovosti pouhych 0.1% je maximalni dosazitelna rychlost na TCP cca 5.2Mbps ! A to je 50ms celkem nizka latence, samotne ADSL ma kolem 30ms, dalsich 20ms se celkem bezne "nasbira" po ceste, v pripade serveru napr. v USA to je klidne i vice, ztratovost muze byt ale i vyssi nez zminene 0.1%, zejmena pokud na strane klienta pouzijete WiFi (a nic Vam nebude platne ani WiFi 802.11n o rychlosti treba 108Mbps, naopak 32mbps spoj s nizsi ztratovosti bude fungovat lepe). Narazil jsem na tento problem u nasich zakazniku v Belgii, kteri jsou pripojeni pres kabelovku rychlosti 25mbps, ze serveru v Belgii, kde je celkova latence 30ms jim to bezi na cca 20mbps, ovsem ze serveru umistenych v Praze jen cca 6.5mbps (latence cca zminenych 50 ms), pritom v lince na server to neni, spoj server - server (CR-BE) jede na cca 100mbps, coz je maximalni rychlost spoje v serveru v .be, ovsem na lince server-server je ztratovost cca 0.001 promile a latence "jen" 30ms! Zakaznik vsak pouzival notebook pripojeny k routeru pres WiFi LAN a ztratovost paketu se u nej pri beznem PINGu pohybovala kolem tech 0.1%, ovsem po pripojeni k jeho routeru UTP kabelem vzrostla dosahovana rychlost z Cech na cca dvojnasobek! Takze pokud nedojde ke zvetseni podporovaneho MTU alespon na urovne tzv. Jumbo Ethernet paketu 8kB muzeme na efektivni rychlosti o desitkach megabitu na ADSL a podobnych technologiich klidne zapomenout!

  • 18. 8. 2008 19:32

    anonymní
    Hlavne je potreba se zamyslet nad tim, co bude nasledovat, vzhledem k tomu ze ATM sluzby se operatorum znacne prorazuji, prechazi se z E1 a SDH infrastruktury na ethernet. Budoucnost je v paketových sítí, Jak O2, tak ostatni operatori upgraduji sve site na nove DWDM, kde je hlavni rozhrani ethernet a vsechny sluzby se budou delat nad nim. To je take duvod prechodu PPPoA na PPPoE. Budouci hlasove sluzby budou tudiz na VoIP. O2 jiz umi sve ADSLko QoSovat a zacina na nem predavat i hlasove sluzby. DSLAM pro symetricke i nesymetricke Linky je totiz stejny. I koncove modemy, pouze se u nich meni firmvare. Budem si muset zvyknout na to, ze budeme mit doma klidne 50MB linku, ale touto rychlosti vam pobezi tak Maximalne WEB. Za sluzby jako VoIP, QoS, a rozumnou latenci si budem muse priplatit. On vubec ten budouci provoz na Internetu bude v budoucnu znacne regulovan na urovni protokolů. Klidně zapomeňte na to ze si koupite pripojku na internet a budete na ni zadarmo provozovat dalsi sluzby s pridanou hodnoto. Za vsechno se bude platit a nebude to trvat tak dlouho. Muj odhad je tak 5 let, ale treba jsem moc velkej pesimista

  • 18. 8. 2008 20:01

    anonymní
    Sranda je, ze ATM bylo mimo uz v dobe, kdy ho nasi operatori slavne zavadeli a to i na mistech/k ucelum naprosto nevhodnych, jako je treba prave IP konektivita. Pamatuju casy, kdy ti takzvani "velci" ISP pripojovali temer vyhradne pres ATM. ATM ma sice svy kouzlo, ale nejak se to neujalo a levnejsi je resit problemy hrubou silou (i obecne, proste kdyz nepomuze palice, tak vemte vetsi palici).

    Ono je to jako se vsim, ISDN se zavadelo kdyz ho jinde rusili ... no a ted se tu tlaci DSL, kdyz jinde uz tahaj optiku az domu.

  • 18. 8. 2008 22:52

    krakonoš (neregistrovaný)
    U Vodoprdu se za to určitě platit bude a ne málo. Pokud jde o alternativní ISP... Již dnes je kdejaká wifina kvalitnější, než ADSL (skutečná rychlost je mimo špičku stejná, ve špičce jen o málo nižší, než deklarovaná, full duplex běžný a ceny o dost nižší, díky tomu že není nutno platit výpalné za dráty). Kvalitnější ISP nabízejí i VoIP jako bonus jen za cenu hovorného a s plně sekundovou tarifikací. Včera mi přišla za VoIP faktura. Za 16 měsíců provozu s 35% podílem mezistátních hovorů (mobily Slovensko) jsem zaplatil 934 Kč vč. DPH. A nic nenasvědčuje tomu, že by to v budoucnu mělo být jinak. Na Slovensko už volám druhý měsíc přes Skype, takže zadarmo. Totéž do Austrálie, Kanady a Nový Zéland. Můj ISP skype podporuje a doporučuje, přesto že provozuje vlastní VoIP ústřednu.

  • 18. 8. 2008 19:56

    anonymní
    "potreba cca 555Mbps"

    Jasne, ale to sme porat u cisteho tcp spojeni. Takovy pripojeni se pouziva spis vyjimecne.

    Napr u ftp mi navic bezi jeste servisni konexe, http taky jeste prenasi dalsi informace navic => potrebna prenosova rychlost na uploadu stoupa.

    Pro pana "Navíc ACK se nemusí posílat pro každý paket extra":
    Upresneni predchoziho postu, krom toho ze ACK se MUSI posilat na kazdy paket (posila se paket s cislem sekvence a nastavenym priznakem) muze, ale nemusi takovy paket obsahovat jeste dalsi data, napriklad muze obsahovat informace vyzadovane protokolem na vyssi vrstve. Pak je takova odpoved samozrejme vetsi.

    TCP okno, jak bylo receno, slouzi k necemu uplne jinemu. Odesilatel nemusi cekat na potvrzeni kazdeho paketu, zacne vysilat a pakety jsou potvrzovany prubezne se zpozdenim pripadne i v jinem poradi. Teprve kdyz pocet nepotvrzenych paketu/doba od odeslani nejstarsiho/.... prekroci stanovenou mez, vysilani se pozastavi a okno se zaroven zmensi.

  • 18. 8. 2008 22:11

    MIN (neregistrovaný)
    Opravdu me bavite:)

    http://www.firewall.cx/tcp-quick-overview.php

    Windowing je prave na to, aby se nemusel posilat ACK pro kazdy paket zvlast. Window se zvetsuje, pokud vzdy prijdou vsechny pakety v poradku, pripadne se zmensuje, pokud se nejaky paket ztrati. Takto je alespon zhruba vyresena i ferovost pristupu a zabrana zahlceni v TCP.

  • 19. 8. 2008 11:46

    anonymní
    Kdybych z toho na VŠ neměl zkoušku z 1, možná bych vám věřil. Windowing NENÍ od toho, aby se nemusel posílat ACK pro každý packet zvlášť (to totiž musí i nadále), windowing umožňuje POUZE a JEDINĚ to, že vysílací strana před odesláním následujícího paketu _nečeká_ na potvrzení doručení toho předešlého. To je vše.

  • 20. 8. 2008 14:17

    ufff (neregistrovaný)
    A vy zase pekne bavite me. Pro priste bych doporucil se odvolavat spise na specifikaci, nez na tu vasi pochybnou jednicku na VS -- mimochodem, na ktere studujete?

    RFC793 - Transmission Control Protocol:

    3.3. Sequence Numbers

    A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received.

  • 28. 8. 2008 20:37

    Ubu (neregistrovaný)
    No - stačí si to přečíst...

    Paket s ACK příznakem a s příslušným ACK-číslem X potvrzuje všechna dosud přijatá data až po oktet (bajt) s pořadovým (SEQ) číslem (X-1). To tedy znamená, že není třeba potvrzovat každý paket. Odesílající tedy může odeslat bez potvrzení tolik dat, kolik mu dovolí velikost okna sdělená klientem a pak teprve musí čekat na potvrzení, přičemž to potvrzení může být realizováno jediným paketem, který potvrdí všechna dosavadní data a může se jet dál.

    Netvrdím, že to tak je vždycky, přijímajícímu nic nebrání, aby potvrzoval každý paket (pardon, správně datagram) zvlášť, ale pravdou je, že potvrzovacích paketů MŮŽE být docela málo, záleží na velikosti okna, kterou příjemce inzeroval. Jiná věc je, že i s velikostí okna se během komunikace hýbe podle toho, kolik paketů se ztrácí.

  • 18. 8. 2008 16:48

    Milos Brejcha
    krome toho, co to asi tak udela kdyz se na ten 512kbit upstream povesi treba 10 pc se snahou fungovat na netu soucasne :)

  • 18. 8. 2008 23:29

    Honza (neregistrovaný)
    Vazeny pane,
    za specialistu na protokol TCP/IP bych se urcite nepovazoval. Spise bych rekl, ze jsem praktik a na nasledujicich 3 screenshotech je jasne videt ze i bez velkeho uploadu jde dosahnout velkych rychlosti na downloadu:
    http provoz:
    http://c.imagehost.org/0580/http.png
    ftp provoz:
    http://c.imagehost.org/0840/ftp.png
    a torrent:
    http://c.imagehost.org/0985/torrent.png

    Vase teorie je velmi pekna, ale jak vidite tak v realu ADSL problem s downloadem kvuli uploadu nema. Pokud zacnete stahovat vyse uvedenym tempem, tak ping je stale pomerne stabilni (10-30ms). Problem nastane pri uploadu vetsim nez 20kB/s pak ping opravdu "vyleti" na stovky ms.
    P.S. Mam ADSL od O2 tarif 8192/512.

  • 19. 8. 2008 9:48

    Gas-O (neregistrovaný)
    A nenapadlo te, ze to nemuzes merit v torrentovem stahovaci, ale primo na sitovce ? Skus pouzit nejaky program, co meri kompletni reziji site na interfacu a pak posli screen, tohle, co jsi poslal je naprosta hloupost, protoze upload, co potvrzuje prichozi pakety se ti tezko zobrazi ve stahovaci ...

  • 19. 8. 2008 13:31

    Honza (neregistrovaný)
    Mate pravdu neprohlednul jsem to poradne - beru zpet, nicmene jen z casti. Zkousel jsem pustit torrent a pri cca 200 spojenich a rychlosti stahovani asi 1,2MB/s byla skutecna rezie na sitovce asi 50kB/s (proste jsem na to koukal jak to naskakuje). Nicmene uz ted pro 8Mbit mame upload 512kbps u te varianty 16M to bude 768kbps. Otazkou je jestli 768 kbps bude rychlost provozni (tj. cista data), pak ale predpokladam ze synchronizacni rychlost bude nekde kolem 1Mbitu nebo spojovaci, pak by to skutecne bylo na hranici. Na druhou stranu muj test byl na 200 spojenich coz produkuje obrovskej vedlejsi provoz v praxi asi malokdo jede na 200 connection...
    Nez me nekdo napadne tak bych jen podotknul ze napr. Volny na fakture mam 4096/384kbps ale na modemu mam synchronizacni rychlost 4640/384kbps.

Dále u nás najdete

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).