xbeda

Co se tyka uploadu z VF za Nemecke servery, tak ucpany nebude, VF je primarne download sit (je to videt i ve statistikach NIX.CZ). Pomalejsi upload u vzdalenejsich serveru muze narazet na limity "TCP congestion control". Na serverech se casto pouziva algoritmus BBR, ten vsak pozitivne oblivnuje pouze download. Windows pouzivaji standartne CUBIC algoritmus, ktery nema tak vysokou propustnost pri zvysene letenci mezi klientem a serverem. Pokud chce nekdo vyzkouset, zde je navod jak algoritmus zmenit i ve Win11 https://dev.moe/en/3021 Pak by bylo zajimave pretestovat upload do zahranici.

Info co se tyka latence - VF optika na siti Cetinu, je to sice z pomalejsiho tarifu, ale vysledky budou podobne. Oblast stredni Cechy. $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=4.572 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=4.423 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=4.649 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.423/4.548/4.649/0.094 ms $ ping6 2001:4860:4860::8888 PING 2001:4860:4860::8888 (2001:4860:4860::8888): 56 data bytes 64 bytes from dns.google: icmp_seq=0 ttl=117 time=4.194 ms 64 bytes from dns.google: icmp_seq=1 ttl=117 time=3.627 ms 64 bytes from dns.google: icmp_seq=2 ttl=117 time=3.958 ms --- 2001:4860:4860::8888 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.627/3.926/4.194/0.233 ms $ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=4.590 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=4.735 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=4.628 ms --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.590/4.651/4.735/0.061 ms $ ping6 2606:4700:4700::1111 PING 2606:4700:4700::1111 (2606:4700:4700::1111): 56 data bytes 64 bytes from one.one.one.one: icmp_seq=0 ttl=57 time=4.133 ms 64 bytes from one.one.one.one: icmp_seq=1 ttl=57 time=4.086 ms 64 bytes from one.one.one.one: icmp_seq=2 ttl=57 time=4.198 ms --- 2606:4700:4700::1111 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.086/4.139/4.198/0.046 ms $ ping www.akamai.com PING e259222.dscx.akamaiedge.net (2.21.33.98): 56 data bytes 64 bytes from 2.21.33.98: icmp_seq=0 ttl=58 time=4.547 ms 64 bytes from 2.21.33.98: icmp_seq=1 ttl=58 time=5.089 ms 64 bytes from 2.21.33.98: icmp_seq=2 ttl=58 time=4.509 ms --- e259222.dscx.akamaiedge.net ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.509/4.715/5.089/0.265 ms $ ping6 www.akamai.com PING e259222.dscx.akamaiedge.net (2a02:26f0:4700::172c:d7ab): 56 data bytes 64 bytes from g2a02-26f0-4700-0000-0000-0000-172c-d7ab.deploy.static.akamaitechnologies.com: icmp_seq=0 ttl=58 time=3.920 ms 64 bytes from g2a02-26f0-4700-0000-0000-0000-172c-d7ab.deploy.static.akamaitechnologies.com: icmp_seq=1 ttl=58 time=4.012 ms 64 bytes from g2a02-26f0-4700-0000-0000-0000-172c-d7ab.deploy.static.akamaitechnologies.com: icmp_seq=2 ttl=58 time=4.023 ms --- e259222.dscx.akamaiedge.net ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.920/3.985/4.023/0.046 ms

Pokud je nektera stranka nedostupna z konkretni IP, tak doporucuji zapnout a vypnout rezim letadlo, tim dojde k preregistrovani mobilu a obvykle navenek ziska jinou IP adresou. Dale aktivovat pod APN internet protokol IPv4+IPv6 pokud neni jiz nastaven. Muze to pomoci na strankach pokud bezi po IPv6. Po pravde jsem se s takovym chovanim doposud nesetkal, muzeme videt priklady takovych stranek?

Jiz je to OK, alespon pro me, vypada to ze fosshub.com chybu opravil.

Ad preferovaná IPv4 konektivita - mě to přijde v pořádku, po upgrade https://www.test-ipv6.cz okamžitě ukazuje 10/10.

Rozhodne 5G beha lepe, ale to neznamena ze na 4G se neda dosahnout slusne rychlosti. Zasadni zlepseni ve vsak v latenci, ktera je u 5G mnohem lepsi.

Mel jsem podobny problem s WhatsApp, kdy se mi zpozdovalo odesilani zprav o desitky sekund. Pricinou byla "zasekla" IPv6, kdy mel telefon IPv6 adresu ale nefungovala. Restart to vyresil, bylo krasne videt na https://www.test-ipv6.cz kdy pred restarem 0/10 po restartu 10/10. Evidentne nezafungoval Happy Eyeballs algoritmus.

Doporucil bych kontaktovat Scamalytics s zadosti o delisting IP adresy, jedna se o NAT adresu, takze Anonymizing VPN je nesmysl. Druha moznost je kontaktovat VF a pozadat o prepnuti modemu do IPv4, cimz ziskate vlastni dynamickou IPv4 adresu.

VF i Google DNS cdn.app-parks.com prekladaji na adresu 98.98.185.201, ktera neni aktualne dostupna z VF. Jako workaround mi funguje pouziti CZ.NIC ODVR 193.17.47.1 a 185.43.135.1, ktere ji prelozi na jiny server (14.137.138.119).

Web funguje z napr. z 89.102.x.x rozsahu, nefunguje napr. z 78.102.x.x rozsahu. TCP spojeni na https portu se sestavi z obou rozsahu, ale behem TLS handshake neco sahne do spojeni a ze smeru od serveru jej odrizne. Jiz jsem se tim setkal u jineho webu a problem byl ve firewallu pred serverem. Takze krome VF, kde s tim nepujde moc udelat doporuciji kontaktovat adminy problematickeho serveru.

Latence 20ms do Lucemburku je neni spatna, podle Globalping testu je VF v CZ jeden z nejlepsich. https://www.jsdelivr.com/globalping?measurement=2CKClTbvy3zvzQKW

Udělal jsem test na S23 od VF, Volte mi funguje bez problémů. Během pingání přes hotspot se mi neztratil během sestavení a při hovoru ani jeden ping. Testováno na 5G a ručním přepnutí na 4G. Telefon je aktualivovaný na poslední SW, v příloze posílám screenshoty.