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

ABSOLUT
KYBERIA
permissions
you: r,
system: public
net: yes

neurons

stats|by_visit|by_K
source
tiamat
K|my_K|given_K
last
commanders
polls

total descendants::
total children::1
show[ 2 | 3] flat


preto openvpn lebo potrebujem volnost, ipsec je dost tazkopadny v tomto
napr uz som presiel tunnel z udp na tcp koli tomu ze cisco co ma routuje malo vyhulene cpu pri velkom udp trafficu a pri tcp je to v pohode (inac dost haluz ;) )
a dalsie veci koli performance chcem este tunovat (to je ten dalsi clanok co bude coskoro)




  • 00000101000635400006354201098481017994120180006301800092018002320180076301801106
    cez tcp je to zloba cista, mas tam meltdown efekt a zbytocne retransmisie. ipsec ti tiez vyhuli cpu? aj ked nepouzijes UDP ako transport, ale iba ESP ako protokol?

    meltdown efekt (pre ludi co nevedia) je problem, ked sa tuneluje tcp v tcp. V pripade stratovosti packetov dochadza k exponencialnemu zhorseniu kvality linky. Ak su timery nastavene inak, tak ked vrchnejsia vrstva ziada o retransmisiu packetu, kym to pride, poziada o nu aj spodna tcp vrstva. Tym padom o jednu retransmisiu viac (2 packety navyse, ak spravne ratam). V pripade, ze ten spodny timer je nastaveny este o cosi horsie, tak sa cela situacia bude uz len zhorsovat. Vytazenie linky sposobi dalsie znizenie kvality atd.

    Nepredpokladam, ze by to bol realny problem, ak sa ta linka nevyuziva naplno, ale akonahle sa zacne naplno tahat, tak k strate packetov urcite dojde (tak sa pride na to, ze je v sieti congestion, ak nie je zapnute ECN) a toto bude asi vazny problem....

    Zaujimalo by ma, ake je to este na dnesnych rychlych linkach relevantne, ale tcp by som v tcp velmi nerad tuneloval.

    Inac pekny navod, asi to spravim aj ja (ale cez IPSec), mas pravdu, chello nema co checkovat nielen kolko tam mam kompov, ale ci vobec browsim... Not their business.
    more children: (2)