Lag spikes

[Návštěvník Lizardor]

Zdravím,

 

už nějaký ten pátek mám problém s lag spikema při odezvě 20-35ms. Jelikož to hraju FPS hry tak s těmi lag spikema to je prostě nehratelné. Vůbec netuším čím to může být a děje se to většinou na německých serverech. Restart routeru ani výměna kabelu nepomohla (jsem připojen přímo na router ethernetem). Kontaktoval jsem i podporu těch serverů na kterých se to převážně děje. A ty mě samozřejmě odkázali na ISP (můžu dodat měření pomocí WinMTR). Děje se to převážně ve večerní hodiny. UPC používám již několik let a na původní adrese jsem žádný  problém neměl, děje se to až po přestěhování na novou adresu (tarif je stejný)

[pkoci]

A jak se vyjádřil Vodafone?

[tomus]

A nějaké ztráty paketů jsi  naměřil ?

Máš stále stejný typ/model modemu ?

[Návštěvník Lizardor]

Nějakou ztrátu mi WinMTR hodil. (můžu hodit log, akorát nevím jestli ho házet takhle veřejně).

Jinak modem mám po přestěhování nový, jelikož ten původní byl už starej. Ale problém je že se to děje jen někdy, není to pořád. Co tak pozoruju tak  od 20:00 - 24:00 většinou.

[tomus]

Tak může to být nějaké přetížení linky někde po cestě, nebo nějaký problém se signálem mezi Vodafone a tvým modemem.

[Slamb]

@Lizardor a kde přesně se ta odezva kazí? bylo by dobrý sem hodit ten výpis, ať je vidět, co a kde se děje 🤔

[zajdee]

@Lizardor jaky byl ten puvodni modem a jaky je ten novy?

Pokud ten stary nebyl compal a ten novy je compal (cerny nebo bily, je to jedno), tak to dost mozna muze byt tim modemem. Jeho chipset je hrozny krap, ktery mimo jine zpusobuje vysoky jitter (kolisajici latence) a casto i ztraty paketu (hlavne v rezimu pripojky "IPv4-only" a aktivnim modu "bridge").

[Návštěvník Lizardor]

příkladám teda log z WinMTR.

 

@zajdee

Hledal jsem kde bych našel co byl ten starej modem co to bylo za typ ale bohužel na fakture je jen ED3.0 a tenhle novej typ je Compal CH7465VF

test.TXT

[tomus]

Taky mě napadl ten modem, ale pokud to dělá jen večer, tak bude problém jinde, 

V tom vypísu vidím už18% ztrátu paketů hned na routeru..

[zajdee]

Tam zadna ztrata neni. Pokud je loss na nekterem z hopu, ale nepropise se do zbytku cesty, tak je to jen ICMP policing (routery se chrani pred velkym mnozstvim ICMP paketu a na cast z nich neodpovidaji).

Od hopu "ae29-100-ucr1.pra.cw.net" je to beze ztraty, stejne tak cilovy server je beze ztraty.

Compal ma krome mnohych dalsich chyb i tu vlastnost, ze ICMP radi do jine tridy nez UDP a TCP, takze traceroute s ICMP nemusi uplne verohodne odrazet skutecny stav linky a zvyseny jitter (ten se muze projevit jen nekdy, podle toho, jak je zrovna chipset Compalu vytizeny).

 

Osobne bych to resil s VF jako reklamaci sluzby - muze byt treba problem s kvalitou signalu (Compal je na to citlivy) nebo proste jen problem s Compalem v case, kdy je v siti vetsi provoz.

Pro gaming bych osobne doporucil spis prejit na VF station v bridge mode a za tim nejaky skutecne schopny router...

IP adresu serveru z WinMTR bohužel nepoznám, ale vyzkoušel jsem si mtr na předposlední hop. Co mě na tom WinMTR výpisu překvapuje (ale vlastně ne, je to skrz Compal) je sloupec "Wrst", tedy nejhorší výsledek z celého měření. MTR ode mě z optiky CETINu se službou od T-Mobile vypadá takhle ("Wrst" je 20 milisekund, jen o kousek horší, než "Average"; linuxový MTR navíc ukazuje i velmi malou odchylku, tj. StDev [Standard deviation]). Loss 0. 2 % připisuju ICMP policingu routerů na cestě.

# mtr -c600 -w -b po2.agr1-dedi-m1.bb.as24961.net
Start: 2022-01-29T23:01:23+0100
HOST:                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  3.|-- 2001:af0:f::1db                                           91.5%   600    7.1   7.0   6.2   7.6   0.2
  4.|-- 2001:af0:f::1da                                           47.5%   600    7.5   7.3   6.8   7.8   0.2
  5.|-- 2003:0:1309:4030::2                                        0.0%   600   15.2  14.9  14.1  15.5   0.2
  6.|-- 2003:0:1309:4030::1                                       25.0%   600   15.5 735.7  14.6 5941. 1326.4
  7.|-- ???                                                       100.0   600    0.0   0.0   0.0   0.0   0.0
  8.|-- 2003:0:f00::eb                                             0.2%   600   17.6  17.5  16.8  18.0   0.2
  9.|-- po6.core2-dus3.bb.as24961.net (2001:4ba0:ffe9:17::1)       0.2%   600   19.5  19.3  18.3  19.9   0.2
 10.|-- po2.agr1-dedi-m1.bb.as24961.net (2001:4ba0:ffe9:19::2)     0.2%   600   19.3  19.3  18.6  20.7   0.2

Z přípojky VF/DS-Lite (+ černý Compal v režimu Router):

# mtr -c300 -w -4  -b po2.agr1-dedi-m1.bb.as24961.net
Start: Sat Jan 29 23:15:53 2022
HOST:                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway (192.168.0.1)                               0.7%   300   13.1   9.4   2.2 213.6  15.1
  2.|-- cz-prg01a-rt1.net.vodafone.cz (84.116.220.17)       0.3%   300   17.5  25.2  13.0 419.8  33.7
  3.|-- cz-prg01a-ra4-ae23.net.vodafone.cz (84.116.223.26)  0.3%   300   24.9  26.7  14.1 337.0  30.7
  4.|-- ???                                                100.0   300    0.0   0.0   0.0   0.0   0.0
  5.|-- te2-2.sitr00i.vodafone.cz (217.77.160.45)          86.3%   300   17.6  24.5  14.4  50.7   8.6
  6.|-- ae8-100-ucr1.czs.cw.net (195.2.12.41)               0.3%   300   23.7  22.4  13.8  87.3  10.0
  7.|-- ae10-ucr1.pra.cw.net (195.2.8.74)                   0.3%   300   19.6  23.0  14.8  77.1   7.5
  8.|-- ae15.cr3-prg1.ip4.gtt.net (46.33.79.241)            0.0%   300   21.2  25.6  13.8 399.0  28.2
  9.|-- ae16.cr3-dus1.ip4.gtt.net (89.149.186.61)           0.3%   300   33.3  38.6  24.2 504.5  35.5
 10.|-- 76.74.9.170                                         0.3%   300   28.5  34.0  24.5 416.4  26.7
 11.|-- po6.core2-dus3.bb.as24961.net (62.141.47.86)        0.3%   300   28.6  34.0  25.6 333.0  20.0
 12.|-- po2.agr1-dedi-m1.bb.as24961.net (62.141.47.157)     0.0%   300   31.6  38.2  26.1 557.2  42.5

Z přípojky VF/IPv4-only (+ bílý Compal v režimu Bridge):

# mtr -c300 -w -4  -b po2.agr1-dedi-m1.bb.as24961.net
Start: 2022-01-29T23:15:55+0100
HOST:                                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway (192.168.1.1)                                  0.0%   300    0.7   0.7   0.7   1.2   0.1
  2.|-- ???                                                    100.0   300    0.0   0.0   0.0   0.0   0.0
  3.|-- ip-86-49-55-193.net.upcbroadband.cz (86.49.55.193)      0.0%   300    8.6  16.1   7.1 177.8  23.2
  4.|-- cz-prg01a-ra4-vla2156.net.vodafone.cz (84.116.221.225)  0.0%   300  158.0  15.6   7.7 158.0  20.5
  5.|-- strlG01-vla2121.net.vodafone.cz (84.116.223.121)       94.0%   300    8.3   9.3   7.6  17.7   2.2
  6.|-- te2-2.sitr00i.vodafone.cz (217.77.160.45)              85.0%   300    8.1  15.4   7.9 125.6  21.6
  7.|-- ae8-100-ucr1.czs.cw.net (195.2.12.41)                   0.0%   300    8.3  17.0   7.7 159.2  23.3
  8.|-- ae10-ucr1.pra.cw.net (195.2.8.74)                       0.0%   300    9.8  17.4   7.9 167.1  21.7
  9.|-- ae15.cr3-prg1.ip4.gtt.net (46.33.79.241)                0.0%   300    8.6  16.5   7.7 210.0  23.9
 10.|-- ae16.cr3-dus1.ip4.gtt.net (89.149.186.61)               0.0%   300   23.9  27.9  18.1 213.1  25.2
 11.|-- 76.74.9.170                                             0.0%   300   19.8  26.9  17.9 186.1  25.3
 12.|-- po6.core2-dus3.bb.as24961.net (62.141.47.86)            0.0%   300   19.3  27.0  18.1 205.3  25.7
 13.|-- po2.agr1-dedi-m1.bb.as24961.net (62.141.47.157)         0.0%   300   18.4  19.9  17.6  36.4   2.5

Ještě jedna otázka: nemáte náhodou přípojku v režimu DS-Lite? Od léta 2017 jsou všechny nově zřizované přípojky pro domácnosti v režimu DS-Lite, dokud si zákazník neřekne o změnu na IPv4-only.

Zkuste http://www.test-ipv6.cz/ (raději z více zařízení) a pokud se objeví, že je IPv6 dostupná, tak je to přípojka v režimu DS-Lite. Proč je DS-Lite problém? Protože DS-Lite/NAT brána u operátora (která zajišťuje ukončení IPv4 tunelů v DS-Lite) se snadno vytíží (v Německu vytížení DS-Lite/NAT brány operátora způsobovalo dost pozdvižení) a večer může způsobovat popisované chování. Řešením by mohlo být přepnutí služby do režimu "IPv4-only".