Technology Review - Raziskovalci z univerz MIT, Harvard, Caltech, TÜM (München) in Porto so predstavili novo implementacijo protokola TCP, ki omogoča za velikostni razred hitrejše prenose podatkov po brezžičnih omrežjih, kjer se paketki izgubljajo. Trenutni protokol TCP, ki se dandanes največ uporablja pri povezavi v omrežja, je bil zasnovan za žična omrežja, kjer se paketki prenašajo brez izgub. Izgube so v teh primerih posledica zasičenosti infrastrukture, zato jih protokol rešuje tako, da pošilja paketek redkeje. V brezžičnih omrežij so izgube po navadi posledica fizikalnih omejitev, zato bi jih morali premagovati z zvišanjem intenzitete oddajanja in ne obratno. To je glavni razlog, da se hitrost prenosa po brezžičnih omrežij drastično zniža, takoj ko se pojavi znaten odstotek izgubljenih paketkov.
Kot so pokazali v članku, lahko problem zelo elegantno obidemo. Namesto pošiljanja celotnih paketkov se odločimo za pošiljanje sistemov linearnih enačb, v katere prevedemo paketke. Prednost tega sistema je večja redundanca, saj lahko prejemnik tudi ob izgubi kakšnega paketka izračuna manjkajoče podatke, ne da bi moral zahtevati ponovni prenos. Hkrati je algoritem računsko nezahteven, tako da ne bo povzročal dodatnih stroškov ali terjal nove zmogljivejše strojne opreme. Imenuje se TCP-NC (network coding).
Zamisel so preizkusili v več okoljih in vsakokrat se je obnesla dobro. V omrežju na MIT-u, kjer je v povprečju izgubljenih dva odstotka paketkov, se je hitrost prenosa dvignila z enega na 16 megabitov na sekundo. V okoljih, kjer so izgube še večje (npr. na vlaku), so uspeli hitrost povečati z 0,5 na 13,5 megabita na sekundo. Kjer izgub ni, tudi nov protokol ne prinaša nobenih prednosti, a v resničnem življenju so idealni scenariji redki.
Tehnologija je uporabna, ker omogoča drastično povečanje hitrosti prenosa brez uporabe dodatnih oddajnikov, povečanja intenzitete oddajanja ali zasedbe širšega dela spektra. Ker je brezžični internetni promet v porastu, so to zelo pozitivne lastnosti. Novo tehnologijo so že licencirali nekaterih proizvajalcem, tako da jo v komercialnih izdelkih po optimističnih napovedih pričakujemo prihodnje leto.
Nothing new is gonna happen. Vse te zadeve so na malce boljšem nivoju že vgrajene v sam wifi čip - retransmitt.
Linku pada hitrost ker je presežen prag tolerance za errorje. Občasni errorji niso problem
Trenutni protokol TCP, ki se dandanes največ uporablja pri povezavi v omrežja, je bil zasnovan za žična omrežja, kjer se paketki prenašajo brez izgub
Bullshit.
Kaj pa packet collision ?
Izgube so v teh primerih posledica zasičenosti infrastrukture, zato jih protokol rešuje tako, da pošilja paketek redkeje.
Zasičenost nima veze z izgubami paketkov.
V brezžičnih omrežij so izgube po navadi posledica fizikalnih omejitev, zato bi jih morali premagovati z zvišanjem intenzitete oddajanja in ne obratno
Višanje 'intenzitete' oddajanja - beden izraz, ne moreš izvajati preko nekih meja. 100mW ali pa tam do 1W, ni nekih bistvenih razlik.
V omrežju na MIT-u, kjer je v povprečju izgubljenih dva odstotka paketkov, se je hitrost prenosa dvignila z enega na 16 megabitov na sekundo
Shitty infrastructure.
Tehnologija je uporabna, ker omogoča drastično povečanje hitrosti prenosa brez uporabe dodatnih oddajnikov, povečanja intenzitete oddajanja ali zasedbe širšega dela spektra
Ja pa kaj še.
Če ti link izgublja podatke ti jih bo izgubljal neglede na vse trike ki jih uporabljaš. Če je nestabilen pač je, the end, porihtaj to in bo problem solved.
SplitCookie> Prevoziš RDEČO ! jype> Ja? A to je kaj posebnega?
Ramon dekers> Ječa je lahko naravno okolje potem ko se adaptiraš.
jype> CPP ne spoštujem _NIKOLI_
Oh, a ta patent na svojo nadarjenost si ze lastis? Vedno znova nabijaü negativne kritike o tej novici in vedno znova trditve v tej novici potrjujes. Odloci se, ali bos proti ali pa bos za. Oboje zal ne mores biti, ne da bi v oceh drugih bil wannabe.
Its only copying if samsung does it. And unless we patent this in 5 years,
this is the shittest tech ever ... and we'll sue you.
Regards, Apple
Če ti link izgublja podatke ti jih bo izgubljal neglede na vse trike ki jih uporabljaš. Če je nestabilen pač je, the end, porihtaj to in bo problem solved.
V novici pa piše:
Prednost tega sistema je večja redundanca, saj lahko prejemnik tudi ob izgubi kakšnega paketka izračuna manjkajoče podatke, ne da bi moral zahtevati ponovni prenos.
>Če ti link izgublja podatke ti jih bo izgubljal neglede na vse trike ki jih uporabljaš. >Če je nestabilen pač je, the end, porihtaj to in bo problem solved.
Ravno nestabilnost linka so rešili s tem, ko so uporabili enačbe za opis paketkov. Če se kakšen paket izgubi, prejemnik iz ostalih paketkov končen podatek preprosto (v smislu male potrate resursov) izračuna. Izguba paketov ni nujno posledica slabe infrastrukture. Kaj pa recimo, če si na vlaku - ki se recimo giblje zelo hitro? Tako hitro, da tudi menja oddajnike zelo hitro (bazne postaje v primeru GSM/UMTS/3G/4G/LTE/...)? S to rešitvijo se problem do neke mere reši.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
Trenutni protokol TCP, ki se dandanes največ uporablja pri povezavi v omrežja, je bil zasnovan za žična omrežja, kjer se paketki prenašajo brez izgub
Bullshit.
Kaj pa packet collision ?
Bo kar držalo. Na fizični liniji do napak praktično ne prihaja in če se paketek izgubi se smatra, da je to posledica zabitosti kakšnega routerja nekje na prenosni poti, oz. pri prejemniku. Packet collision se ti zgodi na ethernetu in takrat ti ga mrežna kartica enostavno pošlje ponovno, brez posredovanja TCP-ja. Plus da je tudi samih collision-ov, odkar imamo switche, neprimerno manj.
Izgube so v teh primerih posledica zasičenosti infrastrukture, zato jih protokol rešuje tako, da pošilja paketek redkeje.
Zasičenost nima veze z izgubami paketkov.
Če ti link izgublja podatke ti jih bo izgubljal neglede na vse trike ki jih uporabljaš. Če je nestabilen pač je, the end, porihtaj to in bo problem solved.
Kako da ne? Če ti neka naprava ne more sprocesirati vseh paketkov, ki ji prihajajo na vhod, jih pač dropa. Nima to nobene veze z nestabilnostjo. Link ima omejeno kapaciteto in ko se gor obesi več uporabnikov, kot je zmožen spumpati, se pač uporabniki s congestion control mehanizmom v tcp-ju omejijo, da optimalno izkoristijo dan link.
Mi pa ni jasna ta rešitev tu. TCP je end to end, tako da če ga ne podpira mašina na drugi strani, s katero govoriš, ga tudi ti ne moreš uporabljati. In če ni rcf-ja, ampak neka ideja o licenciranju, kako se bo potem to prijelo? Plus da glede na opis stvar bolj deluje kot modifikacija ethernet layerja in ne tcp-ja.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
verjetno tako kot je bilo napisano...samo za wifi.ce si s kablom do routerja povezan pa lepo normalen tcp.in ce je tole res tako simple resitev, ki ne obremenjuje procesorja bo mogoce to v prihodnosti clo sam firmware update pa akcija.
Okej, tole na hitro zveni kot forward error correction, oz. FEC. Tehnika znana iz '40 oz. '50 let prejšnjeg stoletja, aktivno v uporabi tudi danes. Kaj je torej tukaj tako novega?
Izumljajo toplo vodo? Ali je samo potgavščina, da vidijo koliko kvazi znanstvenih revij (in spletnih strani) bo povzelo "veliko novo odkritje"?
>verjetno tako kot je bilo napisano...samo za wifi.ce si s kablom do routerja povezan pa lepo normalen tcp.
Kako samo za wifi? TCP tvojo wifi napravo poveže direkt na server, na katerega greš, recimo google. In vmes imaš n različnih povezav, mešanica wireless (do tvojega wlan routerja, ter optike, bakra,... naprej. In če ciljni server ne govori tcp-np ga pač ne boš mogel uporabiti. Ali so mogoče samo butasto poimenovali svojo rešitev tcp-nc, čeprav nima veze s tcp-jem?
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Oh, a ta patent na svojo nadarjenost si ze lastis? Vedno znova nabijaü negativne kritike o tej novici in vedno znova trditve v tej novici potrjujes. Odloci se, ali bos proti ali pa bos za. Oboje zal ne mores biti, ne da bi v oceh drugih bil wannabe.
Hvala. Očitno sem zadel v terno, ker nimaš nič drugega kot osebna izživljanja za povedat.
Če ti link izgublja podatke ti jih bo izgubljal neglede na vse trike ki jih uporabljaš. Če je nestabilen pač je, the end, porihtaj to in bo problem solved.
V novici pa piše:
Prednost tega sistema je večja redundanca, saj lahko prejemnik tudi ob izgubi kakšnega paketka izračuna manjkajoče podatke, ne da bi moral zahtevati ponovni prenos.
Torej so ravno to porihtali.
Retransmitt ni nek hud 'strošek' za omrežje. Prednost tega sistema je izključno popravljanje tistega 2% izgubljenih paketkov. Ko ti err. rate pride do 10%+ vsi ti algoritmi preprosto odpovedo. In nek podoben način je tudi 'kompresija'
V realnosti so vsi ti triki zelo neuporabni.
In nižanje hitrosti omrežja ima tudi efekt povečanja sprejemne občutljivosti.
Bo kar držalo. Na fizični liniji do napak praktično ne prihaja in če se paketek izgubi se smatra, da je to posledica zabitosti kakšnega routerja nekje na prenosni poti, oz. pri prejemniku.
Aha. Ja. Napak na fizičnih linijah (VDSL+ADSL) je toliko da glava peče, samo tega se ne opazi, ker se to porihta že na samih napravah.
Packet collision se ti zgodi na ethernetu in takrat ti ga mrežna kartica enostavno pošlje ponovno, brez posredovanja TCP-ja. Plus da je tudi samih collision-ov, odkar imamo switche, neprimerno manj.
Exactly. In natanko to počne tudi vsak wifi mlinček. Te zadeve so bile 'rešene' že dolgo dolgo nazaj.
Kako da ne? Če ti neka naprava ne more sprocesirati vseh paketkov, ki ji prihajajo na vhod, jih pač dropa. Nima to nobene veze z nestabilnostjo. Link ima omejeno kapaciteto in ko se gor obesi več uporabnikov, kot je zmožen spumpati, se pač uporabniki s congestion control mehanizmom v tcp-ju omejijo, da optimalno izkoristijo dan link.
Dve ločeni zadevi - pri zasičenosti ne bo droppal paketkov, temveč samo ne bo dal dovoljenja napravam za transmitt. Pri nestabilnem linku - wifi ki pada - ne boš z nobenim algoritmom in podobnimi triki odpravil nestabilnost in nekvaliteto linije. Ne moreš pa da se ubiješ.
Okej, tole na hitro zveni kot forward error correction, oz. FEC. Tehnika znana iz '40 oz. '50 let prejšnjeg stoletja, aktivno v uporabi tudi danes. Kaj je torej tukaj tako novega?
Izumljajo toplo vodo? Ali je samo potgavščina, da vidijo koliko kvazi znanstvenih revij (in spletnih strani) bo povzelo "veliko novo odkritje"?
Natanko to - topla voda.
Vsa strojna oprema kjer se šteje da se paketki dejansko izgubljajo - to že zna korektirati.
SplitCookie> Prevoziš RDEČO ! jype> Ja? A to je kaj posebnega?
Ramon dekers> Ječa je lahko naravno okolje potem ko se adaptiraš.
jype> CPP ne spoštujem _NIKOLI_
Bo kar držalo. Na fizični liniji do napak praktično ne prihaja in če se paketek izgubi se smatra, da je to posledica zabitosti kakšnega routerja nekje na prenosni poti, oz. pri prejemniku.
Aha. Ja. Napak na fizičnih linijah (VDSL+ADSL) je toliko da glava peče, samo tega se ne opazi, ker se to porihta že na samih napravah.
Z drugimi besedami - jih ni. Paketek pride čez. Za razliko od WIFI-a, kjer se gladko lahko izgubi in WIFI sprejemnik sploh ne bo vedel, da je bil zanj in ga ne bo ponovno zahteval.
Packet collision se ti zgodi na ethernetu in takrat ti ga mrežna kartica enostavno pošlje ponovno, brez posredovanja TCP-ja. Plus da je tudi samih collision-ov, odkar imamo switche, neprimerno manj.
Exactly. In natanko to počne tudi vsak wifi mlinček. Te zadeve so bile 'rešene' že dolgo dolgo nazaj.
Če počne natančno to, zakaj potem temu rečejo TCP?
Kako da ne? Če ti neka naprava ne more sprocesirati vseh paketkov, ki ji prihajajo na vhod, jih pač dropa. Nima to nobene veze z nestabilnostjo. Link ima omejeno kapaciteto in ko se gor obesi več uporabnikov, kot je zmožen spumpati, se pač uporabniki s congestion control mehanizmom v tcp-ju omejijo, da optimalno izkoristijo dan link.
Dve ločeni zadevi - pri zasičenosti ne bo droppal paketkov, temveč samo ne bo dal dovoljenja napravam za transmitt. Pri nestabilnem linku - wifi ki pada - ne boš z nobenim algoritmom in podobnimi triki odpravil nestabilnost in nekvaliteto linije. Ne moreš pa da se ubiješ.
Seveda jih bo dropal. Prejemnik ne daje nobenega dovoljenja, on samo potrjuje prejem. Pošiljatelj potem na podlagi odsotnosti ack-ja zazna težavo na liniji (ki si jo vedno razlaga kot congestion), zniža hitrost oddajanja in ponovno pošlje paketke, za katere še nima ack-ja.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Z drugimi besedami - jih ni. Paketek pride čez. Za razliko od WIFI-a, kjer se gladko lahko izgubi in WIFI sprejemnik sploh ne bo vedel, da je bil zanj in ga ne bo ponovno zahteval.
Ye rajt.
Če misliš da so wifi zasnovali trapci, potem ja. Drugače ne.
Tako router kot prejemnik nadzirata pretok in računata kaj in kako je s paketki. Že vsak pa tudi uporablja tehnologijo merjenja odbojev za preverjanje kvalitete oddajanja.
Na kratko: Vesta kdaj se paketek izgubi
Če počne natančno to, zakaj potem temu rečejo TCP?
Da veš čemu se to tako reče moraš poznati tudi UDP.
Seveda jih bo dropal. Prejemnik ne daje nobenega dovoljenja, on samo potrjuje prejem. Pošiljatelj potem na podlagi odsotnosti ack-ja zazna težavo na liniji (ki si jo vedno razlaga kot congestion), zniža hitrost oddajanja in ponovno pošlje paketke, za katere še nima ack-ja.
Nope. Wifi deluje bolj po stilu token-ring. Če se paketki večih naprav oddajajo simultano - to samo pomeni da bodo paketi vseh naprav - neuporabni, MiMo je nekako okoli tega, še vedno je pa point - simultano oddajanje rezultira v tem da pretoka podatkov ne bo.
SplitCookie> Prevoziš RDEČO ! jype> Ja? A to je kaj posebnega?
Ramon dekers> Ječa je lahko naravno okolje potem ko se adaptiraš.
jype> CPP ne spoštujem _NIKOLI_
>Da veš čemu se to tako reče moraš poznati tudi UDP.
Očitno ne razumeš kaj hočem reči - če stvar ne dela drugega kot FEC na data link nivoju, potem je butasto stvar poimenovati TCP-NC, ker nima nobene veze s TCP. A članek pravi, da gre za novo implementacijo TCP-ja...
>Na kratko: Vesta kdaj se paketek izgubi
Ja? Zakaj potem ne rešujeta tega sama, namesto da čakata na TCP retransmit timeout? In čisto laično - kako to vesta? Recimo da se sprehajaš po hiši in ravno z enim odbojem sesuješ signal na strani prejemnika. Oddajnik pač ne more vedeti, da je pri sprejemniku njegov oddani signal popačen do te mere, da ga ne uspe dekodirati in posledično ne ve niti, kdo ga je poslal?
>Če misliš da so wifi zasnovali trapci, potem ja. Drugače ne.
Glede na lepe WEP spomine si drugega skoraj ne morem misliti :)
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Oddajnik pač ne more vedeti, da je pri sprejemniku njegov oddani signal popačen do te mere, da ga ne uspe dekodirati in posledično ne ve niti, kdo ga je poslal?
Oddajnik vsake kvatre pošilja beacone - če jih ne pride ob pravem času dovolj - povezava pade.
Pošilja jih neglede na to ali je kateri user gor ali ne.
Za wifi sploh ni kritično ali je uporabnik gor ali ne, router zadrži paketke.
SplitCookie> Prevoziš RDEČO ! jype> Ja? A to je kaj posebnega?
Ramon dekers> Ječa je lahko naravno okolje potem ko se adaptiraš.
jype> CPP ne spoštujem _NIKOLI_
Zakaj se potem dogaja, da TCP niža hitrost oddajanja, ker misli, da gre za congestion? Očitno wlan naprave niso sila uspešne pri tem svojem error detection-u in retransmitu (znotraj data link layerja) in s tem zjebejo tcp flow control (za katerega afaik še niso pogruntali, kako bi efektivno ločevali med zabitostjo in napakami na liniji)
>Za wifi sploh ni kritično ali je uporabnik gor ali ne, router zadrži paketke.
Ne vem, kaj hočeš s tem povedati? Kakšne paketke zadrži in zakaj bi to delal? Router oz. AP ima da sprejema paketke in jih pošilja naprej naslednjemu routerju.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Vidva se kar kregajta, kaj je bilo prej kokoš ali jajce - jaz se bom pa tačas mastil s pečenimi jajci.
Kar hočem s tem povedati - če stvar res dela tako solidno, kot trdijo, jo bom z veseljem uporabljal, ko bo na voljo, pa mi je čisto vseeno kako je s tem o čemur se vidva prerekata.
Jaz samo hočem razumeti, kako stvar deluje. Ne vem, kje ti vidiš prerekanje, ker jaz vidim zgolj debato (kar nekako spada na forum). Ne vem pa, kaj hočeš povedati - da ni važno kako deluje, samo da dela?
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Zakaj se potem dogaja, da TCP niža hitrost oddajanja, ker misli, da gre za congestion? Očitno wlan naprave niso sila uspešne pri tem svojem error detection-u in retransmitu (znotraj data link layerja) in s tem zjebejo tcp flow control (za katerega afaik še niso pogruntali, kako bi efektivno ločevali med zabitostjo in napakami na liniji)
TCP nič ne niža hitrost oddajanja. Hitrost linka sploh nima veze s TCP-jem. Hitrost linka določa sam SnR, občutljivost sprejemnika in prostost kanalov.
Ne vem, kaj hočeš s tem povedati? Kakšne paketke zadrži in zakaj bi to delal? Router oz. AP ima da sprejema paketke in jih pošilja naprej naslednjemu routerju.
Router lahko zadrži paketke pred pošiljanjem: Zakaj bi to delal: Power saving Flow control Multiple users Retransmitt on error
Pa tega je še
SplitCookie> Prevoziš RDEČO ! jype> Ja? A to je kaj posebnega?
Ramon dekers> Ječa je lahko naravno okolje potem ko se adaptiraš.
jype> CPP ne spoštujem _NIKOLI_
TCP pač ne ve, da ima na drugi strani napravo na WIFI. In če za poslane paketke v določenem času ne dobi potrdila, da so bili prejeti, to smatra kot zabito transportno pot in posledično zniža hitrost oddajanja. Kar je smiselno, če dejansko gre za zabito linijo, ker samo s tem da jo zabiješ do onemoglosti škodiš tako sebi kot ostalim.
Zdaj če imaš ti izgube na WIFI delu boš hotel, prosto po članku, zvišati hitrost pošiljanja. Kar je ravno nasprotno od tega, kar hočeš narediti, ko zabiješ pasovno širino linije (znižati hitrost). In ker ti TCP za izgubljene paketke vedno smatra, da so posledica zabite linije, ti bo pač znižal hitrost oddajanja tudi v primeru, da imaš izgube na WIFI delu zaradi slabega signala.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Link, ki si ga podal govori o tem, da končni uporabnik na drugi strani ne more tako hitro obdelovat prejetih podatkov. Ne govori o nobenem prenosu preko kateregakoli medija. TCP v osnovi nima kaj brigat po katerem mediju se bodo podatki prenašali, temu so namenjene nižje plasti TcP/IP modela
No, seveda, to je ideja. Ker ne more tako hitro obdelovati prejetih podatkov (pa ni nujno da gre za končnega uporabnika na drugi strani, lahko je tudi kakšen router vmes) zniža hitrost prenosa. In ker, butast kot je (oz. ker se ne zaveda nižjih plasti), tudi napake na WIFI-ju dojema kot zafilan link (izgubljen paket za TCP lahko pomeni zgolj in samo congestion) zniža hitrost prenosa tudi v teh primerih, kar pa ni preveč kul.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Ne. Ne niža hitrosti prenosa. Reče da je buffer full in naj ne pošilja več
SplitCookie> Prevoziš RDEČO ! jype> Ja? A to je kaj posebnega?
Ramon dekers> Ječa je lahko naravno okolje potem ko se adaptiraš.
jype> CPP ne spoštujem _NIKOLI_
@Poldi112: poglej si malo shemo plasti tcp/ip(ali ISO/OSI) modela in kaj je naloga vsake od teh plasti.
Raje mi povej, kje se motim? Ali pa mogoče praviš, da je dobro, da TCP ne zna ločiti med congestion in wifi izgubami in posledično pri wifi težavah VEDNO narobe reagira.
No, pa mi povej s čim točno reče, da je buffer full in naj neha pošiljati?
Wait komande, zapiranje ali resetiranje linkov ipd. Poln buffer se lahko samo flushne in to je to.
Še drugače - a si slučajno videl kdaj da ti Gbit ali pa 10/100MBit povezava poljubno spreminja hitrost ? Ne.
SplitCookie> Prevoziš RDEČO ! jype> Ja? A to je kaj posebnega?
Ramon dekers> Ječa je lahko naravno okolje potem ko se adaptiraš.
jype> CPP ne spoštujem _NIKOLI_
No, pa mi povej s čim točno reče, da je buffer full in naj neha pošiljati?
Z vrednostjo Window Size v TCP zaglavju.
When the receiving host's buffer fills, the next acknowledgment contains a 0 in the window size, to stop transfer and allow the data in the buffer to be processed.
