Softwarové snížení packet loss z 40% na 0%

24.8.2005 13:55 | Přečteno: 4838× | poslední úprava: 25.8.2005 09:50

Když jsem se ptal na IRC, nebo po firmách co dělají profesionálně WiFi na to, jak snížit softwarově packet loss, tak mě všichni považovali za blázna. Ale mě se to podařilo. Sice mi radikálně vzrostly odezvy, ale i to se dá přežít mnohem lépe jako současný packet loss kolem 40% (u 15000 bytového pingu).

Upozornění: Nejde o reálné snížení packet loss nastavením síťové karty a jádra OS, jde pouze o způsob jak ten packet loss schovat tak, aby nedělal problémy programům, které se z něj normálně neumí vzpamatovat.(Update 25.8)

Kamarád si předělává WiFi síť tak, aby používal pouze jednu značku a tak se zbavoval nějakých síťových prvků. Tak jsem se dostal levně k AP Buffalo WLA-54 a 4 PCI síťovkám OvisLink AirLive WL5400PCI (dělal jsem tu HW záznam). Rozhodnul jsem se udělat si v naší vesničce malou síť.

Jen tak pokusně jsme v sobotu nějak umístili AP k sousedovi do podkroví pod okno. Já jsem si postavil počítač na stůl aby byla přímá viditelnost(jen 2 okna) a síť se rozběhla. Nečekal jsem zázraky. Protože zatím používám 2dB anténky dodávané s kartami a AP. Podařilo se nám nakonec spojit. Spojení kolísalo mezi 12Mbps a 6Mbps, což není žádný zázrak, ale stačí to. Co však mě víc trápilo byl packet loss, který se pohyboval při nastavení pingu na 15000bytů někde kolem 30-40%. Vlastně nebylo možné ani pořádně přenést soubor. Další den jsme trochu přemístili AP, aby mu to prošlo domem. V současnosti máme oba podobné ztráty.

Jelikož se mi nechce čekat až mi kamarád sežene levně nějakou anténu, tak jsem se pustil do ladění softwaru. Já vlastně ani nemusím moc zacházet s hw, nějak mě to nebaví. Vím jak fungují sítě díky studiu Cisco Networking Academy, tak jsem okamžitě vymyslel jak to zlepšit. Bohužel jsem studoval první semestr ze starší verze materiálů, kde ještě moc údajů o WiFi nebylo, ale to přežiju. Ono mě to studium vlastně nenaučilo praktické věci jako jak natáhnout kabel, znám jen principy a poučky. Ale poslední dobou jsem rád, že mě učili jak to obecně funguje, než jak to naklikat v kterém softwaru, nebo jak rychle natáhnout kabel.

Bohužel zatím ale bylo moje řešení jen v hlavě. Musel jsem najít sw, který by to zvládnul. Naštěstí řešení nebylo daleko. Před pár dny jsem si dělal do práce jednoduchý tunel přes OpenVPN, hned mě napadlo to využít.

A taky že jo. Na access pointu mi běží zatím OpenWrt linux s jabber serverem. Ten jabber jsem zatím přesunul do tmpfs (mimochodem neví někdo jak rozchodit na openwrt něco jako upx?), aby se uvolnilo nějaké místo a nainstaloval jsem tam OpenVPN. Prvně jsem překopíroval konfiguráky, které používám v práci a začal jsem s tím laborovat.

Zatím jsem nerozcházel serverové řešení. Udělal jsem jen p2p propoj mezi ap a mým pc a začal jsem to ladit. Chvilku jsem laboroval s velikostí MTU a podobných blostí. Nakonec jsem začal pročítat celou dokumentaci k OpenVPN.

Řešení se našlo brzy. Standartně se používají u OpenVPN na přenos dat UDP packety. Stačilo to tedy přepnout na TCP a najednou to běželo v pohodě s 0% packet loss. Sice se opravdu brutálně zvýšil ping, ale na přenášení souborů ten ping tolik nepotřebuji. Nevím jak moc jsou hry náchylné na packet loss, ale u menších přenosů jsou odezvy v pohodě.

Zde je současný konfigurák:

#nastavni na AP
proto tcp-client
remote 192.168.1.2
ifconfig 10.0.0.1 255.255.255.0

#nastavni na PC
# proto tcp-server  
#remote 192.168.1.1
#ifconfig 10.0.0.2 255.255.255.0

# spolecne nastaveni
dev tap
port 1200
status /etc/openvpn/smrknet/status
keepalive 10 30
verb 5
comp-lzo
persist-key
persist-tun
secret /etc/openvpn/smrknet/secret.key

Zatím jsem to testoval jen mezi AP a mnou. Jak přijde soused z brigády, tak to otestuji mezi námi. Do té doby musím rozchodit na serveru VPN v módu server. Nevím ale jestli mám používat šifrování. Přeci jenom má to AP jen 125MHz a 8MB RAM a 4MB flash. Je to dost omezené, nevím jak to bude zvládat. Doufám, že AP nebude provádět kompresi, ale bude pouze přesměrovávat už jednou zkomprimované balíky s packety.

Každopádně se těším na anténu, až bude normální packet loss 0%.

Nemá někdo z vás hlubší zkušenosti s OpenVPN? Jak to rozchodit bez šifrování v režimu server, nebo nějak aby to bylo dostatečně nenáročné?

       

Komentáře

[VícNežNic]

Zajímavé řešení

[bl4z4]

Tak tady mate peknou antenu za cenu parku a konektoru. http://www.simandl.cz - plechovka. Sam jsem vyrobil dve a funguji bez problemu. Zisk okolo 10 dBm. S openvpn zkusenosti nemam, snad nekdo dalsi .

[trekker.dk]

Někde jsem zaslechl, že doma dělaný antény chtěl radiotelekomunikační úřad zakázat. Detaily si nepamatuju, takže nevím, co je k tomu vedlo ani jestli se jim to povedlo prosadit.

[bl4z4]

GL zustala na 2.4 GHz pri starem, tzn. kanaly tak jak byly a antena nemusi byt doporucena vyrobcem, pouze limit 100mW vyzarovaci vykon, od toho maji slusna zarizeni regulaci vykonu. Jinak je prijemna zmena u 5GHz, ale abych moc nekecal tak tady odkazy. I4 info a nove Vseobecne podminky - pdf.

[Jiří Němec]

Až mi dorazí všesměrová anténa na AP, tak se asi do tohodle pustím. Díky za link, našel jsem jen jeden český článek a jeden slovenský: http://www.maco.sk/wireless/cantenna.html http://www.pcsvet.cz/art/article_print.php?id=4082.

Včera jsem se ptal v jedné firmě a tam mi říkali, že to je možný používat asi 14 dní. Ale i tak to nemá homologaci. Otázka je jestli to někdo bude měřit v vesničce s 60 obyvateli.

Jako profesionální řešení to použít nejde, ale v malé síťi 2-4 lidí kde se klade důraz na nízkou cenu mi to přijde jako ideální řešení.

[D-Evil]

Jak už někdo psal o kousek vejš, anténu v pásmu 2,4 GHz můžeš použít jakoukoliv, homologace netřeba, ta je nutná pouze u wi-fi karty/HW AP. Pouze musíš zhruba vědět, jakej má zisk, při kontrole ČTU se tě na to asi budou ptát. Většinou je to u plechovek tak těch 8-10 dB, s trychtýřem (třeba z alobalu podlepenýho papírem) tak 11-13 dB, podle velikosti. Takovou hodnotu berou (když jim řekneš 6, tak se ti vysmějou) a pak s ní počítaj, jestli nepřekračuješ normy na vyzařovací výkon.

[Zdeněk Štěpánek]

Zdravim

Tak to je goool. Tohle by zaslouzilo tesatt do kamen se slovy "TAKTO NE".

Pokud se ti to spojilo na 5.5Mbit (6M?bit neexistuje) a skakalo to na 11Mbit tak mas bud signal dobrej ale silny ruseni nebo co nejpravdepodobnejsi smejdskej hardware (coz tedy ovislink IMHO je) a nasazuje vyssi rychlost i kdyz na to nema signal. Proste a jednoduse to AP prepni na 1Mbit fixed a budes happy.

Zdenek

[Jiří Němec]

To byla snad první věc, kterou jsem zkoušel. Snížil jsem rychlost na 1Mbps a dopadlo to takto: 81% packet loss.

Muj odhad: ruší mě elektrický ohradník, nebo něco podobného v pravidelných intervalech. Čím rychleji se ten packet přenese, tím je menší šance že ho ten impulz pokazí.

[Jiří Němec]

Což mě přivádí na myšlenku pohrát si s něčím jako window size. Nebo v čem to wifi přenáší. Když se to dostatečně sníží, tak se poškodí méně dat.

[D-Evil]

Tohle by mě asi v životě nenapadlo, docela chytrý. Nicméně to má i pár nevýhod, v podstatě jsi to nakousnul, jde o hry.

Co se týká stříleček jako Quake, Unreal, nebo Counter Strike, to si s odezvou přes 100 ms asi moc nezahraješ, postavičky ti budou po obrazovce skákat jak gumídci.

Se strategiema je to obecně lepší (i když se najdou výjimky, třeba OpenTTD mělo ještě nedávno síťovej kód docela náročnej na odezvy), tam stačí tak 300 ms (Starcraft se dá hrát i s 500 ms, když se nastaví hra na Extra high latency).

Ještě mě napadla jedna věc, která by ti mohla pomoct. Zkus vypnout kompresi v tom tunelu, dost možná se to na odezvách projeví.

[Jiří Němec]

Nevím jak moc hry využívají linku, ale většina her je dělaná na rychlost modemu, takže by to mělo být v pohodě. Jde vlastně o to, že pokud přenáším malé packety, tak jsou odezvy uplně v pohodě. Pokud dojde ke ztrátě, tak se přenos musí zopakovat a pak je občas třeba i nad 1s, ale ostatní pingy tu mám 6ms. Takže to vypadá pro standartní ping: 5.110/56.566/1256.982/172.578 ms.

[D-Evil]

Tak s timhle pingem by neměl bejt problém, hry fungující přes UDP chrlej hodně malý pakety, takže do 100 ms se asi vejdeš v pohodě.

[podlesh]

Takže jinými slovy ten packet loss je tam pořád stejný, jenom schován protože se opakování vysílání řeší na úrovni toho TCP tunelu.

Odborně se tomu myslím říká "Potěmkinova vesnice".

Ale musím se obdivovat skutečně geniálnímu a neotřelému řešení.

[podlesh]

A je pravda, že to pro některé druhy provozu může být i výhodné. Možná by se na toto téma dala napsat pěkná diplomka (Na některých univerzitách i dizertačka )

[petr_p]

Chapu, ze pro nekoho to muze byt prekvapko, ale kdyby autor napsal, ze paketloss na sve VPN vyresil formou IP over TCP, tak nebudu ocekavat v clanku nejaky zazracny postup.

Navic TCP je na silne ztratovych linkach (od 10 procent vyse) velmi nevhodne, kvuli zpusobu zotaveni ze ztraty paketu. Spise bych doporucil zvysit retranslaci a redundaci na linkove vrstve (tzn. snizit efektivni rychlost WiFi spoje). Pripadne zakazat fragmentaci na IP vrstve, protoze pri ztrate IP fragmentu se prenasi cely paket znovu.

[kavol]

ping 15000 bajtů? jaký to má význam, když je MTU přibližně 1500 bajtů? (myslel jsem, že jde o překlep, ale 15000 tam není jen jednou ...)

počítám-li dobře a nezapomněl-li jsem základy sítí, k vykázání 40 % ztrátovosti u ping -s 15000 stačí reálná ztrátovost (v nejlepším případě) horší než přibližně 3,6 %

[Jiří Němec]

Testovat to takto mi poradil kamarád, který se stará o wifi síť ve svém okolí už delší dobu. Neptal jsem se proč, ale výsledky to má slušné. O velikosti MTA vím, ale nejsem si jistý jak to přesně funguje ve wifi. Mohu vás ale ubezpečit, že na druhého člověka když se ty ztráty složí, tak mám 30% i na klasickém 64b pingu.

[kavol]

Testovat to takto mi poradil kamarád, který se stará o wifi síť ve svém okolí už delší dobu. Neptal jsem se proč,

hm, to je zásadní chyba; pokud něco dělám, je dobré vědět, proč to dělám ... takových "zaručených" rad je ...

já se domnívám, že je to blbost - nebýt lenosti se zeptat, mohl jsem teď být poučen, že se mýlím

ale výsledky to má slušné.

to znamená co?

[Jiří Němec]

Pochopil jsem to tak, že tím otestuju jestli tím projde více dat za sebou a v pořádku. Normální packet je tak malý, že tím projde docela rychle a linka je pak většinu času volná. Nevím pořádně jak jinak to otestovat s tím, co je na tom AP nainstalováno.

Slušné výsledky - vidím, že je něco špatně.

Promiňte za pozdější reakci, ale vaši reakci jsem trošku přehlédnul, snažím se rozchodit to AP jako vpn server a zatím se mi moc nedaří. Mám problémy s ssl.

[kavol]

Pochopil jsem to tak, že tím otestuju jestli tím projde více dat za sebou a v pořádku. Normální packet je tak malý, že tím projde docela rychle a linka je pak většinu času volná.

hmm ... tak počítejme, za jak dlouho projde 15 kilobyte:

  1 Mbps ... 117,2 ms
  2 Mbps ...  58,6 ms
5,5 Mbps ...  21,3 ms
 11 Mbps ...  10,7 ms

(dovolil jsem si zjednodušení, reálné hodnoty jsou jiné, co jsem zkoušel na 100 Mbps ethernetu, mám rtt 3.1 ms, podle užitého vzorce by to mělo být 2*1,2 ms)

jestliže se pingá standardně jednou za sekundu, pak při těchto hodnotách rovněž platí "linka je většinu času volná" ... takže kýžený efekt se nám nějak rozplynul, ne?

co se týče "více dat za sebou", jelikož chyby jsou rozloženy víceméně náhodně (rytmus pingu těžko sesynchronisuješ s rytmem rušení, i pokud je pravidelné), více informací o jejich četnosti získáš z toho, jestli se trefují do častěji posílaných malých paketů, nežli z toho, že poměrně spolehlivě zruší pakety velké - aneb že někdo trefí vrata od stodoly je jasné, zajímavější je, zda (jak často) trefí i dveře, kterými zrovna prochází člověk

Nevím pořádně jak jinak to otestovat s tím, co je na tom AP nainstalováno.

man ping také něco málo napoví ...

Slušné výsledky - vidím, že je něco špatně.

aha ... to lze ovšem vyčíst i jednodušeji ... jinak jak jsem naznačil, z deseti pingů získám podrobnější informaci, vím kolik jich dojde, to je deset hodnot, než z jednoho rozděleného do deseti fragmentů (resp. asi jedenácti), vím jen jestli došel nebo ne, to jsou dvě hodnoty ...

jedině že by vysílání kontinuálního toku dat mělo z hlediska WiFi nějaký speciální význam, který mi uniká dík neznalosti, jak to fyzicky tím vzduchem chodí - v tom případě to ale stále lze nasimulovat pakety posílanými rychle za sebou

[Jiří Němec]

Děkuji za poučení. Pro příště snížím čas mezi odesílanými pingy. Snad tím trochu líp zjistím co mě ruší a v jakých je to intervalech.

[Ondřej Čečák]

sw snizeni packet loss pomoci nekdy i nekolikanasobneho overheadu a zajimaveho chovani a promennych a dlouhych latenci ... bomba :)

Kazdopadne se to take resilo v linux@linux.cz: link

[noname]

Doporučuji vyrobit lepší anténu. Na http://vzduchem.wz.cz/ jsme našli yagi kolem 15 db. Výrobní cena, kromě konektoru asi 30 Kč, s konektorem 100 Kč. Máme spojení Asus wl500g - Alfa AWAP201 - Ovislink 1120AP. Všechny AP mají výše uvedené antény. Jede to v režimu WDS (nepěkné, ruší to pásmo, ale študenti nemají peníze). Zde jsou výsledky (jede to přes WDS), vzdálenost stanic kolem 600 metrů, ve městě, v zarušeném prostředí:

Statistika ping pro 192.168.1.3:
Pakety: Odeslané = 10, Přijaté = 9, Ztracené = 1 (ztráta 10%),
Přibližná doba do přijetí odezvy v milisekundách:
    Minimum = 127ms, Maximum = 170ms, Průměr = 145ms
Ctrl+Break
Odpověď od 192.168.1.3: bajty=20000 čas=156ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=136ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=134ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=126ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=158ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=166ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=171ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=150ms TTL=255
Odpověď od 192.168.1.3: bajty=20000 čas=145ms TTL=255

Menší pakety mají odezvu do 5ms. PS: To sw řešení bych nevymyslel. Blahopřeji. PPS: Dobře propájejte konektory

[lukas.ramlich]

a takovýhle materiál se cpe na VUT-BR. To by se člověk po*.

Gratuluji ke snížení packetlossu na nulu pomocí geniálního nápadu. Doufám že příšte si přečteme, jakým geniálním způsobem se ti podařilo snížit své IQ na aktuální hodnotu.

[Jiří Němec]

Tak mi sem napište lepší řešení.

[lukas.ramlich]

Chtěl bys znát lepší řešení? Jedno bych měl - necpi se na vejšku a běž makat. Někdo určitě bude mít pochopení pro tvoje geniální nápady, "správců sítě" bez základních znalostí je dost, tam dobře zapadneš :)

[Ondřej Čečák]

Doufam, ze smajlik znamena tezkou ironoii na cely prispevek ...

[lukas.ramlich]

Pokud má někdo maturitní výsledek tento: "CJL: 4, MAT: 4, PRV: 4, POS(počítačové sítě): 2, praktická: 1.", pak stejně na vejšce vyhoří na matematice nebo fyzice, takže proč si tím zesložiťovat život.

[David Jaša]

Nj, ale samotná maturita už dneska nic neznamená - pokud teda člověk nemá podnikatelského ducha.

[Jiří Němec]

Neznáte mě, neznáte maturitní komisi. Nevím jestli znáte tu školu. Nevíte ani jak moc jsem se na co učil. Nevíte ani jestli už práci nemám. Tak mi neraďte co mám udělat s životem, když o mě nic nevíte. Jestli na nějakém předmětu vyhořím neřešte, to je jen můj problém.

Zatím jste mi sem nenapsal nic konstruktivního. Pouze jsem pochopil, že se vám to moje řešení nelíbí. Když už sám nedokážete vymyslet jiné řešení, tak mi sem napište co dělám špatně, ať se poučím.

Doufám, že vaše další reakce bude o řešení mých problémů s wifi a přestanete s touto off-topic diskuzí.

[lukas.ramlich]

Ale já přece vím, že už práci máš, sám to píšeš ve svém blogu. Školu taky znám, která to je píšeš ve svém blogu. Že ses učil tři dny taky vím, píšeš to ve svém blogu. Ale máš pravdu, že to je jedno, jen jsem řekl svůj názor, jak to skutečně dopadne je opravdu jen tvoje věc.

Nevím proč pořád hledáš řešení, když už ho tady několik lidí zmiňovalo. Ale to bys je nesměl ignorovat.

[Jiří Němec]

Já jsem čekal, že vy napíšete svoje řešení. Nevadí. Samozřejmě jsem většinu zde uváděných řešení, které teď mohu provést už vyzkoušel. Zatím z toho nejsou o moc lepší výsledky. Asi tu mám nějaké podivné rušení, na které tyto metody neplatí. Docela se těším, až mi přijde ta anténa a budu se moci zbavit toho vpn. Ale zatím je to nejlepší řešení, o kterém vím.

[Abraxis]

Zjistit, co zpusobuje ten loss a odstranit to nebo snizit rychlost linky nebo se s lossem spokojit. (nerikal jsi, ze chces "jednoduche" reseni)

[Ondřej Čečák]

Univerzalne se rika:

Resit pricinu, ne dusledek.

[Jiří Němec]

Po snížení rychlosti linky je to mnohem horší, tudy cesta nevede. Pravděpodobně mě ruší elektrický ohradník, nebo něco, co se vyskytuje často a krátkou dobu (ohradním posíla tuším jednou za sekundu krátký impulz kolem 9000V, ruší nám to trochu televizi). Chci to vyřešit pořádnou anténou, ale ta mi jentak nedorazí, tak se zatím spokojím s tímhle řešením.

Doufal jsem, že mi tu v komentářích někdo poradí. Jinak bych sem nepsal. Zatím tu žádné lepší řešení nebylo, jen petr_p navrhnul věc, kterou jsem zatím nezkoušel, protože pořádně nevím jak. S wifi jsem se seznámil teprve před pár dny a zatím pořádně nevím jak přesně to funguje.

[digri]

To najdes v nastaveni tech WiFin, problem je, ze ne kazde zarizeni to umoznuje.

[Jiří Němec]

V linuxu se dá nastavit několik hodnot navíc, jako třeba framefurst. Pořádně jsem ješte nepochopil hodnoty: RTS thr=2347 B Fragment thr=2346 B. Takhle to bylo nastaveno na tom AP i ve Windows.

Ve výpisu mám(zcenzurován WEP):

eth1      IEEE 802.11b/g  ESSID:"SmrkNet"  Nickname:"Mrakoplas"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:07:40:A0:5E:59
          Bit Rate:24 Mb/s   Tx-Power=31 dBm   Sensitivity=20/200
          Retry min limit:20   RTS thr:2347 B   Fragment thr:2346 B
          Link Quality=66/0  Signal level=-71 dBm  Noise level=-132 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

[Abraxis]

Pokud neni ohradnik tvuj (resp. rodicu), tak bych si docela hlasite stezoval - tohle preci neni normalni, musi se jednat o homologovane zarizeni a to nesmi takhle rusit. Homologace neni jen car papiru - jde prave o to, aby nevznikaly takoveto problemy. Kdyz se podivas do Svycarska (Rakouska/...), tak tam maji takovych ohradniku spousty a pokud by to takhle rusilo, tak si tam snad ani nezavolas z mobilu. Ale doporucuji se nejdrive ujistit - proste zkuste se domluvit, ze na pul hodky se ohradnik vypne, zmeris linku/televizi a pak hned uvidis, kde je zakopana krava

P.S. Mel jsem dojem, ze ty ohradniky maji stejnosmernych 50-100V, ale to je fakt mozna jen mylna informace.

[lukas.ramlich]

Vůbec bych na ty jeho teorie nereagoval. Rušení ohradníkem je naprostý nesmysl.

Pan blogger postupuje stejně, jako kdyby se pokoušel spojit na 100 km a pak dumal proč to nejde a došel k výsledku, že to ruší auto jezdící po silnicích.

Kdyby to byl nějaký chlapec ze základní školy, který si doma dělá pokusy, tak bych se snažil mu jeho chyby podrobně vysvětlit. Ale tohle je úspěšný maturant technické průmyslovky s oborem počítače, který se zabydluje na technické univerzitě a nás ve svém bloggerském příspěvku poučuje, jak odstranit softwarově packet loss a vůbec mu to nepřijde divné. Nevěřím vlastním očím!

[Jiří Němec]

Co jsem slyšel, tak většinou mají ohradníky tak 7000-10000 V. Nevím kolik mají ty ohradníky na koně, ty mají většinou míň. Každopádně nám to trochu ruší televizi (blbá anténa a hlavě předzesilovač).

Homologace - taky to může být nějaký pozůstatek z JZD. Nevím jak se tenkrát prováděly testy jestli to ruší tyto frekvence.

Co mě ale doopravdy ruší nevím. Je to jen teorie založená na tom rušení televize. Jak říkam, nemám nic potvrzené. Kdoví odkud je to rušení. Zatím nemám potřebnou techniku, abych to proměřil.

[Abraxis]

No, pokud to rusilo televizi v dobach JZD, tak urcite i dnes... Ale na to, jak opakuji, zadnou techniku nepotrebujes. Z ceho vychazi tve presvedceni, ze televizi rusi tenhle ohradnik - jen z toho, ze to nekdo jen tak rekl? Jak rikam - zarid vypnuti ohradniku na par minut, zmer WiFi (a televizi) a HNED uvidis... Zadna technika ti tohle nezmeri...

[Jiří Němec]

Že mi to ruší televizi vím určitě. Každý rok to začne v podobnou chvíli, když sousedi vyženou kravy na jednu pastvinu.

Není to tak hrozné, pouze se jistých intervalech na Nově objevuje čára. Starší televize, která s tím měla opravdové problémy nám loni odešla. Ale že to ruší TV ještě neznamená, že to ruší i wifi.

[Abraxis]

Clovece, proboha, proc delas veci, kterym nerozumis (coz by tak nevadilo), ale proc potom o nich pises takove siiilene bludy. Pominu ted zdroj ruseni (to je HW a to muze byt cimkoliv - od blbe zahnuteho kabelu k antene po ruseni z 220 site), ale uvedom si, ze kdyz udelas VPN po TCP, tak z principu funkce TCP toto NEMUZE MIT PACKET LOSS!!! (takze tvoje hodnota 0% o nicem nevypovida) - a to z toho duvodu, ze veskery packet loss se "ukryl" do TCP a ho jenom nevidis. Pomoci pingu pres VPN pres TCP bys nameril 0% loss, i kdyby realny loss byl 99%!!! Jinymi slovy - proste ted nenameris VUBEC nic (pokud se nebudes divat na statistiky toho TCP/VPN spoje) a nemuzes ani zjistit, zda je linka lepsi nebo ne, takze sis vubec nepomohl, jen muzes machrovat, ze mas 0% loss na pingu....

[digri]

Nechapu, proc tu vsichni tak nadavate? Jste asi zase sezrali vsechnu moudrost sveta. Pokud mu slo o to, zbavit se PL na nespojovanych protokolech bez fyzickeho zasahu do vlastniho nekvalitniho spoje, tak toho dosahl. A pouzil k tomu celkem jednoduchy napad, o ktery se chtel podelit. Cist jste to nemuseli .

Pokud vim, tak nepsal nic o tom, ze uz se nebude snazit zlepsit kvalitu samotneho spoje.

[kavol]

Nechapu, proc tu vsichni tak nadavate?

proč? třeba proto, že dělá něco, o čem nicmoc neví, čemuž se bohužel člověk občas nevyhne, ale ani se to nesnaží dozvědět (!) - pokud chci diagnostikovat spoj, nevím jak na to a nechám si poradit, tak jako součást té rady chci také vědět, co tím vlastně zjistím, moje první otázka by byla proč zrovna tahle velikost, na co to má vliv či co se projeví ... on se prostě nezeptal, neví, ale už hodnotí výsledky metody (že jsou "slušné"? to jako že nemluví sprostě?) ... třeba se s tím, že pingat většími pakety než je MTU je zavádějící, mýlím a budu za nevzdělance nakonec já, ale aspoň jsem o tom ochoten otevřít diskusi a neberu to jako fakt, že mi to někdo nadiktoval ...

[Jiří Němec]

Přiznávám, že o ICMP packetech toho nevím tolik, kolik bych chtěl. Hlavní pro mě bylo, že mi to rychle ukázalo na problém. Jak to funguje tuším a docela mi to tak zatím stačí. Mám teď jiné problémy, než řešit ping. Stejně jak znám toho kamaráda, co mi to poradil, tak on taky určitě neví jak to funguje, takže by mi to určite nevysvětlil. Tenhle člověk sice ví jak navrhnout anténu a jak ji kamokoliv dotáhnout, ale o principu sítí toho až tak moc neví.

Na druhou stranu to řešení s tím OpenVPN doufám chápu dostatečně, abych to mohl použít. I když poprvé jsem s vpn začal laborovat asi před týdnem a s wifi až někdy v sobotu. Největší problémy mi teď dělá SSL.

[Abraxis]

Proc mu vsichni nadavame? Jednoduche - protoze jeho clanek (OK, zapis v blogu) vzbuzuje mylnou domenku, ze pomoci takovehoto "spinaveho triku" lze odstranit packet loss.

[Jiří Němec]

Přesně o to schování packet lossu mi šlo. Vím, že moje vyjadřovací schopnosti nejsou nejlepší, tak v těch "bludech" asi tahle myšlenka zanikla, ale opravdu jsem to tak myslel.

Packet loss v takových hodnotách je dost hrozný a dost programů s tím má problémy. Víc jsem vyřešit nepotřebovat. Nevím přesně jak funguje AP na prvních 2 vrstvách, ale pokud to VPN rozchodím na AP, tak se postará o ztráty na obou spojích a ztráty se nebudou zdvojovat.

[Abraxis]

To je ale naprosto spatny pristup, schovavat takhle ten p.l. Ktery program a proc ma s tim problem? Pochop - tim, co jsi udelal, tak ten p.l. sice schovas, ale lag je tam stejnej, jako kdyz bys ho nemel schovanej (dokonce jeste mozna vetsi) a hlavne ti program nebo kernel nemuzou delat optimalizace prenosu na zaklade p.l., protoze o tom, ze se neco ztraci, nic nevi...