25.07.2005-0:34:07 :: Remember, remember, the velvet November


node:	25.07.2005-0:34:07
template:	4
parent:	thus spoke juraj in 'defaultroute thru tunnel on linux'
owner:	maniac
viewed by:
created:	25.07.2005 - 00:34:07

cwbe coordinatez:
101
63540
63542
1098481
1799412
1800063
1800092
1800232
1800763
1801106
1801168

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

no teoria je to pekna a znie aj logicky.
zial v praxi je to picovina a aj napriek teoriam (aj dalsim dovodom preco by malo byt udp lepsie) je tcp naozaj rychlejsie.

ad stratovost pri vyhulenej linke - nie, nieje, nema byt preco, nikto mi nezahadzuje packety, obcas sa nejaky strati, ale je to asi menej ako 1%. za normalnych okolnosti ked je zahulena linka tak sa akurat caka na ack a zase caka sa este dost dlho na to aby som mal take odozvy ze by sa to pokladalo za strateny packet.
bezim na to mikrovlnke ktorej kapacita je nieco medzi 1,7 a 2 mbps a 1 mbps chelle.

000001010006354000063542010984810179941201800063018000920180023201800763018011060180116801801272

no, caka sa ak je velkost tvojej queue taka, ze stiha vyprazdnovat. ak nie, tak sa zakonite packety stracat musia. to iste queue na druhej strane. keby sa nestracali, mas externy meltdown.

proste queue ma urcitu konstantnu velkost (napr. 10MB). ak mas 1Mbps linku a posielas 2Mbps, tak sa queue zaplna, az kym nezaplni tych 10MB a potom sa packety musia stracat. Ak by si mal prilis velku queue, chodili by ti packety, ktore by si uz davno retransmitoval (a su v queue vzadu) a koneksn by sa ti vyhulila zase naplno bordelom.

Samozrejme, tcp je dost rozumne a v pripade, ze nema dost ack (alebo sa prekroci window size), tak spomali posielanie. Co je jediny dovod, preco sa ti ten meltdown efekt neprejavuje. Skus tam nieco streamovat cez udp (voip, videolan, dalsi tunel :-) alebo nieco take) a do toho stahovat cez tcp a uvidis meltdown v plnej krase...
alebo staci 300 tcp konektov ;).

to, ze je tcp rychlejsie ako udp je zjavne nejaka stupidita v openvpn (predpokladam, ze ma sifru v cbc mode a ma horsie riesene retransmisie ako tcp samotne).

00000101000635400006354201098481017994120180006301800092018002320180076301801106018011680180127201801452

to ze je to rychlejsie v tcp je koli tomu ze cisco a vyhulene cpu pri routovani udp (niekde som to tam spominal)

no, "posielat 2mbps po 1mbps linke" sa nejak ani moc teoreticky pri tcp neda, vzdy sa caka na ACKy, a v tom prvom prispevku si prave spominal ze sa jedna o efekt kde sa enkapsuluje tcp v tcp a nie uz udp stramy ako spominas tu

0000010100063540000635420109848101799412018000630180009201800232018007630180110601801168018012720180145201802161

no, ved caka na ack, to je jasne. ale v praxi mas asi malokedy jednu koneksn.

staci ti jedno tcp spojenie a udp zahlcujuce linku a to tcp ti spravi okamzite meltdown. to udp tam je len ako priklad, kedy sa ti moze stat, ze mas zahltenu linku a stracaju sa ti packety a ako vysvetlenie, preco sa ti to nestava, ked stahujes dva subory cez ftp :)

riesil si to cisco, ze preco ma vyhulene cpu? vsak to nie je normalne, nemas na nom nastaveny nejaky stavovy firewall ("connection" tracking)?

000001010006354000063542010984810179941201800063018000920180023201800763018011060180116801801272018014520180216101802203

nie, nic take tam nieje, vsetko som daval prec az na plain konfig a stale ho to udp hulilo.
je to stary shit, ale aj tak nechapem preco je taky rozdiel medzi tcp a udp hm