Ztratovitost linky a softwareove reseni
lkv
mam takovy dotaz , mam jeden spoj wifi ktery ma vetsi packet loss , i presto
ta lika bez problemu udela 700kBps . Chci se zeptat jestli by
bylo mozne na takoveto lince udelat tunel ,neco jako OpenVPN, ktery by za
cenu snizeni rychlosti treba na 500kBps snizil packet loss.
Pripadne ktery software by jste doporucili, nebo jestli mate nekdo prakticke
zkusenosti.
Dekuji Lukas Kvasnica
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Jak na lokalizaci? Czech Howto! http://www.penguin.cz/czech-howto/
Martin Kraus
> Zdravim,
>
> mam takovy dotaz , mam jeden spoj wifi ktery ma vetsi packet loss , i
> presto ta lika bez problemu udela 700kBps . Chci se zeptat jestli by
> bylo mozne na takoveto lince udelat tunel ,neco jako OpenVPN, ktery by za
> cenu snizeni rychlosti treba na 500kBps snizil packet loss.
> Pripadne ktery software by jste doporucili, nebo jestli mate nekdo
> prakticke zkusenosti.
jedina prakticka zkusenost je lip to naladit. ztratovost je nejspis otazka ztraty
wifi ramcu a ty se ztraci kvuli ruseni, v tom vam zadny tunel nepomuze.
mk
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Konference o PDA a Linuxu: http://penguin.cz/cgi-bin/mailman/listinfo/pda-l
Dalibor Straka
>
> mam takovy dotaz , mam jeden spoj wifi ktery ma vetsi packet loss , i presto
> ta lika bez problemu udela 700kBps . Chci se zeptat jestli by
> bylo mozne na takoveto lince udelat tunel ,neco jako OpenVPN, ktery by za
> cenu snizeni rychlosti treba na 500kBps snizil packet loss.
> Pripadne ktery software by jste doporucili, nebo jestli mate nekdo prakticke
> zkusenosti.
Nekterym kartam jde nastavit maximalni pocet retransmisi nezli oznaci
paket za ztraceny a TCP jej musi poslat znova. Dobra hodnota je 20.
napr. iwconfig wlan0 retry 20
Stejne jako kolega Vam radim: Kvalitni wifi konektory, kvalitni kabel,
smerova antena, dobre nastaveny vykon a spravny kanal.
-- Dalibor Straka
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Prohledejte ftp.linux.cz: http://ftp.linux.cz/pub/
Ctirad Fertr
> mam takovy dotaz , mam jeden spoj wifi ktery ma vetsi packet loss , i
> presto ta lika bez problemu udela 700kBps . Chci se zeptat jestli by
> bylo mozne na takoveto lince udelat tunel ,neco jako OpenVPN, ktery by za
> cenu snizeni rychlosti treba na 500kBps snizil packet loss.
Tunel nikoliv. Potřebujete QoS. Zkuste se podívat třeba na skripty zde:
http://hop.rozhled.cz/czfree/qosbase/
Ctirad
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Archivy news a prohledavani najdete na http://groups.google.com/
Martin Kraus
> Dne sobota 09 července 2005 23:12 lkv napsal(a):
> > mam takovy dotaz , mam jeden spoj wifi ktery ma vetsi packet loss , i
> > presto ta lika bez problemu udela 700kBps . Chci se zeptat jestli by
> > bylo mozne na takoveto lince udelat tunel ,neco jako OpenVPN, ktery by za
> > cenu snizeni rychlosti treba na 500kBps snizil packet loss.
>
> Tunel nikoliv. Potřebujete QoS. Zkuste se podívat třeba na skripty zde:
> http://hop.rozhled.cz/czfree/qosbase/
QoS? jak to pomuze pri spatne naladenem spoji? jedine muzete pres ten spoj
posilam min dat, to ovsem ztratovost na fyzicke vrstve nevyresi.
ztraty na 2.4 tak do 5%, pak uz je to o nicem.
mk
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Prectete si Linux Documentation Project: http://www.linux.cz/linuxdoc/
Vaclav Stepan
zpomalilo, pokud linka neni dost rychla, a zaroven potrebujete zabranit
tomu, aby se cokoliv ztracelo primo na te lince.
Muzete zkusit upravit nastaveni karty, aby vice krat zkusila ramec
poslat, nez ho zahodi, muzete zkusit snizit rychlost (pokud tam vazne
mate 700 kBps a ne kbps, mate docela prostor).
Muzete pres QoS stahovat tok linkou tak dlouho, az packet loss dost
klesne (viz http://www.lartc.org/).
K tem tunelum - potrebujete neco, co uz s tim, ze pakety nedojdou
pocita a hodla se o to starat. Takze
CIPE: Ne
OpenVPN: Mozna, pouzijete-li tunelling over UDP
VTUN: Ne
Melo by fungovat, ale neni to dokonale:
ICMP tunel: http://www.cs.uit.no/~daniels/PingTunnel/
Ale to je relativne pomale.
ROCKS: Nestara se primo o PL, ale o disconnection. Mozna pujde pouzit.
Dalsi (nevim jestli by fungovaly):
ITUN: Viz SourceForge
WTCP: Google, ale nedari se mi najit hotovou implementaci, jen clanky.
Ale kdyby to fungovalo, byly by to ono. Jeste jsou nejake IETF drafty
ohledne podobnych uprav TCP, ale nevim, jestli nekdy nejaky prosel.
NSTX: nevim jestli se stara o retransmise
Takze bych zkusil nouzove PingTunnel a OpenVPN v UDP modu.
A dejte vedet, jestli neco z toho zabralo.
Vaclav Stepan
lkv napsal(a):
> Zdravim,
>
> mam takovy dotaz , mam jeden spoj wifi ktery ma vetsi packet loss , i
> presto ta linka bez problemu udela 700kBps . Chci se zeptat jestli by
> bylo mozne na takoveto lince udelat tunel ,neco jako OpenVPN, ktery by
> za cenu snizeni rychlosti treba na 500kBps snizil packet loss.
> Pripadne ktery software by jste doporucili, nebo jestli mate nekdo
> prakticke zkusenosti.
>
> Dekuji Lukas Kvasnica
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
lkv
nez ten spoj nejak resit.
Lukas Kvasnica
TIP: Prohledejte nejprve archiv konference
Ctirad Fertr
> QoS? jak to pomuze pri spatne naladenem spoji? jedine muzete pres ten spoj
> posilam min dat, to ovsem ztratovost na fyzicke vrstve nevyresi.
Na wifi ano. Tam se zyvyšuje ztrátovost i pingy úměrně zvyšování objemu
přenášených dat.
Ctirad
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Pred odeslanim mailu zkontrolujte, jestli necitujete prilis mnoho textu
Pavel Kankovsky
> mam takovy dotaz , mam jeden spoj wifi ktery ma vetsi packet loss , i
> presto ta lika bez problemu udela 700kBps . Chci se zeptat jestli by
> bylo mozne na takoveto lince udelat tunel ,neco jako OpenVPN, ktery by
> za cenu snizeni rychlosti treba na 500kBps snizil packet loss.
Pokud jsou ty ztraty dostatecne rovnomerne rozlozene, tak by ciste
hypoteticky slo udelat to, ze vezmu n paketu, nejakym samoopravnym kodem
z nich udelam n+k, ktere poslu, a na prijimaci strane se pripadne ztracene
pakety rekonstruuji z redundantni informace.
V praxi by to asi bylo ponekud komplikovanejsi, protoze rekonstruovane
pakety budou mit podstatne vetsi zpozdeni nez originalni.
Nemam tuseni, jestli se to nekdo pokusil realizovat v praxi.
PS: Jak jste zmeril tech 700 kB/s?
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
lkv
druhe strane asi 10MB soubor
lkv
TIP: Konference o free softwaru: freesoft na list...@freesoft.cz
Martin Kraus
> Dne neděle 10 července 2005 12:05 Martin Kraus napsal(a):
> > QoS? jak to pomuze pri spatne naladenem spoji? jedine muzete pres ten spoj
> > posilam min dat, to ovsem ztratovost na fyzicke vrstve nevyresi.
>
> Na wifi ano. Tam se zyvyšuje ztrátovost i pingy úměrně zvyšování objemu
> přenášených dat.
no to jo, ale nevyresi to softwarove packet loss. treba udp to rozhodi uplne,
pokud samotna palikace nesimuluje nejakym zpusobem tcp. jedine, co qos udela
je, ze zpomali tok, takze tcp ma sanci znovu ty pakety procpat, protoze proste
clovek vi, ze ma pomalejsi lajnu, tak od toho nic neocekava.
s vetsim tokem se zvysujou odezvy a treba icmp pak vytimeoutuje, ale pokud ma
problem s rusenim, coz predpokladam ze ma, tak je lepsi ten spoj naladit nez
to zpomalovat.
samozrejme, pokud je na nejakym miste, ktere je zapraskane milionem wifin, tak ma
asi smulu. rozhodne bych se ale spis snazil naladit spoj, nez se spokojit se
zpomalenim linky.
mk
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Konference o Perlu: perl na list...@muni.cz
Martin Kraus
> Tech 700kBps , proste jsem stahoval wget z weboveho serveru ktery je na
> druhe strane asi 10MB soubor
takze mate cca 5+mbit? to jedete na 2.4ghz? a ztraty jste zjistil jak? icmp
nebo nejake informace primo o wifi ramcich? a ty ztraty jsou pri zatizeni,
nebo i normalne?
pri vyssi rychlosti se dramaticky zvysuji odezvy, takze vam muze timeoutovat
icmp, pak by pomohlo tu linku zpomalit. pokud se ztraci ramce, tak je nejlepsi
se snazit to co nejlepe naladit.
mk
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
Vaclav Stepan
> Tak OpenVPN nijak vyrazne nesnizi packet loss, tak asi nezbyde nic jineho
> nez ten spoj nejak resit.
> Lukas Kvasnica
> >ICMP tunel: http://www.cs.uit.no/~daniels/PingTunnel/
PingTunnel funguje - zkousi resend tak dlouho, az projde.
K rozumnemu pouziti byste to jeste musel sprahnout s necim,
co tim jednim tunelovanym portem protahne vsechen traffic
(cokoliv over TCP tunel) - tech je dost.
Kazdopadne vyladit linku je lepsi, protoze ICMP tunel je osklive
pomaly :-)
Vaclav Stepan
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Pred polozenim dotazu si nejprve prectete dokumentaci k programu
Vasek Stodulka
> Ona je potiz, ze zaroven potrebujete zahazovat pakety, aby TCP
> zpomalilo, pokud linka neni dost rychla, a zaroven potrebujete zabranit
> tomu, aby se cokoliv ztracelo primo na te lince.
Zahazovani packetu pro "nestihajici" linku (pri TCP protokolu) je
docela rozsireny omyl, ve skutecnosti se pakety jenom pozdrzi. Jakmile se
pakety zahazuji kdyz linka nestiha, pak bud neco neni dobre, nebo to spravce
routeru explicitne takto z nejakeho duvodu chce. TCP si samo ridi rychlost
jinak.
--
Vašek Stodůlka
tel.: +420 608 200 860
Rastislav Dvořák
ziskom. ak mate 24 dB skuste si pozicat napr 26 dB antenu a vyskusat ju
ci sa zlepsi stabilita linky alebo chodte do takeho wifi obchodu ktory
je ochotny vam predat antenu tak ze ju pripadne mozete vratit.
ak pouzivate wifi klienta skuste vyskusat iny typ alebo ak pouzivate
wifi kartu priamo v pocitaci skuste vymenit za inu s inym cipsetom. mne
sa osvecili cipsety Prism pre wifi karty a realtek cipsety pre wifi
klientov.
----------------------------------------------------------------------
skontrolované antivírusom Kaspersky Personal 5 Pro
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Hledate software? Zkuste http://freshmeat.net/
Matus UHLAR - fantomas
>> Ona je potiz, ze zaroven potrebujete zahazovat pakety, aby TCP
>> zpomalilo, pokud linka neni dost rychla, a zaroven potrebujete zabranit
>> tomu, aby se cokoliv ztracelo primo na te lince.
Vasek Stodulka <xva...@gmail.com> wrote:
> Zahazovani packetu pro "nestihajici" linku (pri TCP protokolu) je
> docela rozsireny omyl, ve skutecnosti se pakety jenom pozdrzi.
Iba po velkost buffera routera na tej linke, a v zavislosti od toho, ako
velmi linka nestiha.
> Jakmile se pakety zahazuji kdyz linka nestiha, pak bud neco neni dobre,
> nebo to spravce routeru explicitne takto z nejakeho duvodu chce. TCP si
> samo ridi rychlost jinak.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
AntiTrust2 (gmail)
> Tech 700kBps , proste jsem stahoval wget z weboveho serveru ktery je na
> druhe strane asi 10MB soubor
>
> lkv
IMHO by som skusil aj ping -f (teda v ramci LANu) + iptraf
resp. ping -f -s rozne-velkosti
BTW: Ja to robievam v screene - nezabudnut ten ping zrusit!
--
--
AT
--
AKA antitrust2-AT-gmail.com
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Ctete FAQ - http://www.phil.muni.cz/~letty/linuxfaq/
Vasek Stodulka
> > On Sun, 10 Jul 2005 12:02:38 GMT, Vaclav Stepan <w...@linux.fjfi.cvut.cz> wrote:
> >> Ona je potiz, ze zaroven potrebujete zahazovat pakety, aby TCP
> >> zpomalilo, pokud linka neni dost rychla, a zaroven potrebujete zabranit
> >> tomu, aby se cokoliv ztracelo primo na te lince.
>
> Vasek Stodulka <xva...@gmail.com> wrote:
> > Zahazovani packetu pro "nestihajici" linku (pri TCP protokolu) je
> > docela rozsireny omyl, ve skutecnosti se pakety jenom pozdrzi.
>
> Iba po velkost buffera routera na tej linke, a v zavislosti od toho, ako
> velmi linka nestiha.
Ano, to je sice pravda, ale AFAIK k teto situaci v normalnim provozu
skoro nikdy nedochazi. Spojeni od zacatku zvysuje svou rychlost az k maximu
prutoku pres uzke misto, ktere ma zpravidla dostatecne dimenzovane buffery
na to, aby zvladlo svuj provz. Pokud nekdo umele preplni buffery zarizeni
tim, ze mu z te rychlejsi strany "nasype" spoustu dat (DoS, DDoS), pak se
pakety zahodi, ale v normalnim provozu kazde spojeni zacina pomalu a pak
postupne zrychluje, takze spousta dat najednou by prijit nemela.
Vaclav Stepan
>> Iba po velkost buffera routera na tej linke, a v zavislosti od toho, ako
>> velmi linka nestiha.
> Ano, to je sice pravda, ale AFAIK k teto situaci v normalnim provozu
> skoro nikdy nedochazi. Spojeni od zacatku zvysuje svou rychlost az k maximu
> prutoku pres uzke misto, ktere ma zpravidla dostatecne dimenzovane buffery
> na to, aby zvladlo svuj provz. Pokud nekdo umele preplni buffery zarizeni
> tim, ze mu z te rychlejsi strany "nasype" spoustu dat (DoS, DDoS), pak se
> pakety zahodi, ale v normalnim provozu kazde spojeni zacina pomalu a pak
> postupne zrychluje, takze spousta dat najednou by prijit nemela.
Uvaha byla --- linkou tece 700 kBps, packet loss se mirne snizi s tokem,
takze stahnu tok na polovinu. Kdyz nahodim shaper, tak TCP spojeni
zabrzdi, a stane se tak proto, ze se nejdriv naplni buffery a pak se
pakety zacnou zahazovat. Takze tady to v podstate explicitne je zamerem
spravce.
Cekal bych ale, ze k temuz dojde i pri v podstate normalnich situacich,
kdy se kapacita linky skokove zmeni --- zmena routovaci trasy (prechod
na zalozni linku, data z vice linek po jedne etc.), kratkodobe ruseni
provozem na blizkem kanalu, etc..
Jestli se mylim, budu velmi rad, pokud byste to mel cas sireji vysvetlit.
Vaclav Stepan
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Konference o UNIXu obecne: munix-l na list...@muni.cz
Vasek Stodulka
> Uvaha byla --- linkou tece 700 kBps, packet loss se mirne snizi s tokem,
> takze stahnu tok na polovinu. Kdyz nahodim shaper, tak TCP spojeni
> zabrzdi, a stane se tak proto, ze se nejdriv naplni buffery a pak se
> pakety zacnou zahazovat. Takze tady to v podstate explicitne je zamerem
> spravce.
Tak to skutecne driv fungovalo, nez se TCP stack zacal programovat
podle RFC 2001 (leden 1997, http://ftp.fi.muni.cz/pub/rfc/rfc2001.txt),
ktere prinasi a prezentuje algoritmy "slow start" a "congestion avoidance".
Drive si koncove strany mezi sebou dohodly nejakou rychlost spojeni a
nebraly v potaz to, ze by mezi nimi mohla byt tenka linka. Pak routery
ridily rychlost skutecne tim, ze packety, ktere nedokazaly zpracovat,
jednoduse zahodily. Takovym chovanim samozrejme dochazi ke spouste
retransmisi (cimz se znovu zahlcuje sit) a navic to cele degraduje maximalni
propustnost, kdyz si musim o spoustu packetu rikat znovu po timeoutu.
Myslenky RFC 2001 jsou (mozna az vulgarne zjednoduseno) asi takove:
Rychlost jako takova je rizena jednoduchym pricipem, a to poctem ramcu,
ktere muze vysilajici vyslat do site bez toho, aby dostal ACK - pocet techto
ramcu se nazyva velikost congestion window. Principialne je potreba, aby
pocet odeslanych ramcu korespondoval s poctem prijatych ACK - nemuzu
odesilat 20 ramcu za sekundu, kdyz vim, ze mi nechodi vice nez 10 ACK za
sekundu. Tento pomer se teda snazim balancovat a rychlost efektivne ridim
poctem odeslanych ramcu a prijatych ACK, nikoli poctem zahozenych ramcu
a retransmisi.
Ve specialnich (a opravdu ojedinelych) pripadech se pouziva RED
(Random Early Drop), ktere zase zjednodusene funguje tak, ze nahodne
zahazuju packety s pravdepodobnosti podle toho, jak moc se mi datovy
prutok blizi maximalni povolene hranici - takze i takto se rychlost da
ridit, ale v praxi se to moc nepouziva.
> Cekal bych ale, ze k temuz dojde i pri v podstate normalnich situacich,
> kdy se kapacita linky skokove zmeni --- zmena routovaci trasy (prechod
> na zalozni linku, data z vice linek po jedne etc.), kratkodobe ruseni
> provozem na blizkem kanalu, etc..
Ano, v takovych pripadech se packety skutecne zahodi a je veci TCP
(nebo dalsich protokolu), aby se v tom udelal poradek a provedly se
potrebne retransmise.