Ping w Poznaniu/Wrocławiu

[thatonedud]

Cześć, chcę przeprowadzić się do miasta z najlepszym pingiem w Polsce. Czy ktoś z Poznania lub Wrocławia mógłby mi pokazać zrzuty ekranu z opóźnieniem na niektórych europejskich serwerach?

Oto kilka przykładów:
Frankfurt - ec2.eu-central-1.amazonaws.com
Amsterdam - ams-nl-ping.vultr.com
Londyn - ec2.eu-west-2.amazonaws.com

Możesz użyć komendy ping/tracert w cmd lub winmtr. Byłoby to bardzo pomocne, dziękuję.

[j131]

Jestem niemal pewien że czas odpowiedzi tych serwerów jest w całej sieci operatora podobny. Będę we Wrocławiu w przyszłym tygodniu to sprawdzę jak tam to wygląda.

[adrjannn]

Przeprowadzka specjalnie po to aby mieć niski ping?

Co w przypadku gdy Orange zmieni routing (bo może? bo nie gwarantuje niskiego pingu do serwisów zewnętrznych) ?

[j131]

Warszawa LTE:
~ 

~ $ ping ams-nl-ping.vultr.com
PING ams-nl-ping.vultr.com (108.61.198.102) 56(84) bytes of data.
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=1 ttl=46 time=59.8 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=2 ttl=46 time=48.5 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=3 ttl=46 time=48.9 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=4 ttl=46 time=56.4 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=5 ttl=46 time=55.9 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=6 ttl=46 time=64.9 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=7 ttl=46 time=56.3 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=8 ttl=46 time=50.5 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=9 ttl=46 time=51.5 ms
64 bytes from 108.61.198.102.vultrusercontent.com (108.61.198.102): icmp_seq=10 ttl=46 time=51.0 ms
^C
--- ams-nl-ping.vultr.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 48.530/54.415/64.972/5.002 ms
~ $ ping ec2.eu-central-1.amazonaws.com
PING ec2.eu-central-1.amazonaws.com (52.94.141.13) 56(84) bytes of data.
64 bytes from 52.94.141.13: icmp_seq=1 ttl=237 time=40.4 ms
64 bytes from 52.94.141.13: icmp_seq=2 ttl=237 time=47.3 ms
64 bytes from 52.94.141.13: icmp_seq=3 ttl=237 time=42.2 ms
64 bytes from 52.94.141.13: icmp_seq=4 ttl=237 time=39.9 ms
64 bytes from 52.94.141.13: icmp_seq=5 ttl=237 time=39.0 ms
64 bytes from 52.94.141.13: icmp_seq=6 ttl=237 time=41.7 ms
64 bytes from 52.94.141.13: icmp_seq=7 ttl=237 time=38.9 ms
64 bytes from 52.94.141.13: icmp_seq=8 ttl=237 time=42.4 ms
64 bytes from 52.94.141.13: icmp_seq=9 ttl=237 time=38.0 ms
^C64 bytes from 52.94.141.13: icmp_seq=10 ttl=237 time=40.1 ms

--- ec2.eu-central-1.amazonaws.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 38.066/41.037/47.320/2.522 ms
~ $ ping ec2.eu-west-2.amazonaws.com
PING ec2.eu-west-2.amazonaws.com (52.94.56.52) 56(84) bytes of data.
64 bytes from 52.94.56.52: icmp_seq=1 ttl=235 time=47.9 ms
64 bytes from 52.94.56.52: icmp_seq=2 ttl=235 time=45.6 ms
64 bytes from 52.94.56.52: icmp_seq=3 ttl=235 time=48.5 ms
64 bytes from 52.94.56.52: icmp_seq=4 ttl=235 time=45.5 ms
64 bytes from 52.94.56.52: icmp_seq=5 ttl=235 time=49.8 ms
64 bytes from 52.94.56.52: icmp_seq=6 ttl=235 time=44.4 ms
64 bytes from 52.94.56.52: icmp_seq=7 ttl=235 time=52.5 ms
64 bytes from 52.94.56.52: icmp_seq=8 ttl=235 time=60.3 ms
64 bytes from 52.94.56.52: icmp_seq=9 ttl=235 time=58.7 ms
^C
--- ec2.eu-west-2.amazonaws.com ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8015ms
rtt min/avg/max/mdev = 44.488/50.437/60.391/5.421 ms
~ $

[thatonedud]

Przeprowadzam się nie tylko po to, żeby mieć niski ping, ale to dla mnie ważny czynnik. Rozumiem, że routing jest dynamiczny, ale zazwyczaj zmienia się między kilkoma opcjami. We Lwowie, gdzie mieszkam, mój ping do serwera AWS we Frankfurcie waha się między 22 ms, jeśli idzie przez Pragę, a 25 ms, jeśli idzie przez Warszawę.

Początkowo chciałem przeprowadzić się do Warszawy, ale koszty utrzymania są wysokie, a routing popularnych dostawców internetu jest kiepski, sądząc po testach na tej stronie https://globalping.io/network-tools/ping-from-warsaw (między 24 a 29 ms, a nie 14-19 ms, jak mogłoby być). Dlatego rozważam inne opcje, ale nie ma dokładnych informacji o opóźnieniu w grach online w Poznaniu ani we Wrocławiu.

[deest]

---

@thatonedudnapisał(-a)

Przeprowadzam się nie tylko po to, żeby mieć niski ping, ale to dla mnie ważny czynnik. Rozumiem, że routing jest dynamiczny, ale zazwyczaj zmienia się między kilkoma opcjami. We Lwowie, gdzie mieszkam, mój ping do serwera AWS we Frankfurcie waha się między 22 ms, jeśli idzie przez Pragę, a 25 ms, jeśli idzie przez Warszawę.

Początkowo chciałem przeprowadzić się do Warszawy, ale koszty utrzymania są wysokie, a routing popularnych dostawców internetu jest kiepski, sądząc po testach na tej stronie https://globalping.io/network-tools/ping-from-warsaw (między 24 a 29 ms, a nie 14-19 ms, jak mogłoby być). Dlatego rozważam inne opcje, ale nie ma dokładnych informacji o opóźnieniu w grach online w Poznaniu ani we Wrocławiu.

---

Ogółem coś takiego jest na stronie hurtowej Orange - nie wiem czym jest SuperPoP ale wygląda na to, że połączenie będzie leciało z Warszawy lub Poznania

[jaryn]

Z T-Mobile z W-wy.

[thatonedud]

Dziękuję, to naprawdę pomocne. Liczyłem na więcej takich odpowiedzi.

[j131 · Accepted solution]

W kontekście łącz FTTH oferowanych przez Orange mogę napisać co następuje.

Połączenia dla klientów indywidualnych są konfigurowane jako sesje pppoe w jednym z dwóch trybów: IPv4 lub IPv6. W trybie IPv4 dostaje się jeden publiczny adres IP i ruter zapewnia ewentualną obsługę przekierowywania/otwierania portów a także funkcjonalność zapory sieciowej.
W trybie IPv6 nie dostaje się publicznego adresu IPv4, połączenia w tym protokole są tunelowane i poddawane CGNAT - w efekcie publiczny adres IP jest dzielony z innymi użytkownikami, a porty można przekierowywać w ograniczonym zakresie. Ten tryb jest coraz częściej trybem domyślnym. Tunel zestawiany jest zgodnie z odpowiednim RFC pomiędzy LAN rutera ("B4") a najbliższym serwerem CGNAT ("AFTR"). Tych serwerów AFTR jest jednak tyle ile węzłów na mapce podlinkowanej powyżej, i na własnym sprzęcie można tunele zestawiać między B4 a dowolnym AFTR.

Odpowiadając na Twoje pytanie zrobiłem w związku z tym test polegający na utworzeniu tuneli do każdego z tych AFTR i przetestowaniu jak wyglądają czasy odpowiedzi z każdego z nich. Dla nadania kontekstu sprawdziłem też czasy odpowiedzi poszczególnych AFTR (łódzki AFTR nie chciał odpowiadać, nie wiem dlaczego akurat ten, kielecki AFTR co prawda na pingi odpowiadał, al przez tunel nic nie puszczał, więc Kielc nie pokazuję, a z Łodzi brakuje punktu odniesienia - to jednak chyba nie jest krytycznie ważne, bo pytałeś głównie o Wrocław i Poznań). Dysponując tymi danymi powinieneś móc wyrobić sobie zdanie na temat o który pytasz, w kontekście Orange FTTH w całej Polsce.

Umieszczę je w kolejnych postach, żeby łatwiej się w tym rozeznać i nie przekroczyć limitu słów na post.

Mnie jest oczywiście najbliżej do gdańskiego AFTR, zakładam że inne lokalizacje będą miały zbliżone czasy do "swojego" jak ja mam do gdańskiego, i sumaryczny czas będzie odpowiednio krótszy niż ten raportowany tutaj. Nie daje to może wglądu bezpośredniego, ale trendy w różnicach między miastami da się zauważyć. Tak jak pisałem wcześniej, są one minimalne.

[j131]

Kra, 2a01:1000:0:1::1214
PING 2a01:1000:0:1::1214(2a01:1000:0:1::1214) 56 data bytes
64 bytes from 2a01:1000:0:1::1214: icmp_seq=1 ttl=58 time=14.3 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=2 ttl=58 time=13.6 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=3 ttl=58 time=12.6 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=4 ttl=58 time=16.3 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=5 ttl=58 time=15.6 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=6 ttl=58 time=14.6 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=7 ttl=58 time=13.6 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=8 ttl=58 time=12.6 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=9 ttl=58 time=11.6 ms
64 bytes from 2a01:1000:0:1::1214: icmp_seq=10 ttl=58 time=15.3 ms

--- 2a01:1000:0:1::1214 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 11.618/14.015/16.260/1.402 ms

PING 108.61.198.102 (108.61.198.102) from 192.0.0.2 dsliteKra,: 56(84) bytes of data.
64 bytes from 108.61.198.102: icmp_seq=1 ttl=55 time=42.1 ms
64 bytes from 108.61.198.102: icmp_seq=2 ttl=55 time=41.5 ms
64 bytes from 108.61.198.102: icmp_seq=3 ttl=55 time=40.6 ms
64 bytes from 108.61.198.102: icmp_seq=4 ttl=55 time=43.1 ms
64 bytes from 108.61.198.102: icmp_seq=5 ttl=55 time=42.6 ms
64 bytes from 108.61.198.102: icmp_seq=6 ttl=55 time=42.8 ms
64 bytes from 108.61.198.102: icmp_seq=7 ttl=55 time=41.6 ms
64 bytes from 108.61.198.102: icmp_seq=8 ttl=55 time=41.6 ms
64 bytes from 108.61.198.102: icmp_seq=9 ttl=55 time=40.7 ms
64 bytes from 108.61.198.102: icmp_seq=10 ttl=55 time=40.3 ms

--- 108.61.198.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 905ms
rtt min/avg/max/mdev = 40.289/41.711/43.099/0.922 ms
PING 52.94.141.13 (52.94.141.13) from 192.0.0.2 dsliteKra,: 56(84) bytes of data.
64 bytes from 52.94.141.13: icmp_seq=1 ttl=245 time=27.0 ms
64 bytes from 52.94.141.13: icmp_seq=2 ttl=245 time=26.6 ms
64 bytes from 52.94.141.13: icmp_seq=3 ttl=245 time=26.8 ms
64 bytes from 52.94.141.13: icmp_seq=4 ttl=245 time=29.1 ms
64 bytes from 52.94.141.13: icmp_seq=5 ttl=245 time=28.6 ms
64 bytes from 52.94.141.13: icmp_seq=6 ttl=245 time=28.8 ms
64 bytes from 52.94.141.13: icmp_seq=7 ttl=245 time=27.6 ms
64 bytes from 52.94.141.13: icmp_seq=8 ttl=245 time=26.6 ms
64 bytes from 52.94.141.13: icmp_seq=9 ttl=245 time=30.3 ms
64 bytes from 52.94.141.13: icmp_seq=10 ttl=245 time=29.6 ms

--- 52.94.141.13 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 26.609/28.104/30.256/1.276 ms
PING 52.94.56.52 (52.94.56.52) from 192.0.0.2 dsliteKra,: 56(84) bytes of data.
64 bytes from 52.94.56.52: icmp_seq=1 ttl=243 time=43.7 ms
64 bytes from 52.94.56.52: icmp_seq=2 ttl=243 time=42.6 ms
64 bytes from 52.94.56.52: icmp_seq=3 ttl=243 time=41.6 ms
64 bytes from 52.94.56.52: icmp_seq=4 ttl=243 time=41.8 ms
64 bytes from 52.94.56.52: icmp_seq=5 ttl=243 time=44.1 ms
64 bytes from 52.94.56.52: icmp_seq=6 ttl=243 time=44.8 ms
64 bytes from 52.94.56.52: icmp_seq=7 ttl=243 time=42.5 ms
64 bytes from 52.94.56.52: icmp_seq=8 ttl=243 time=42.8 ms
64 bytes from 52.94.56.52: icmp_seq=9 ttl=243 time=42.6 ms
64 bytes from 52.94.56.52: icmp_seq=10 ttl=243 time=41.6 ms

--- 52.94.56.52 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 41.633/42.819/44.764/1.014 ms