Ping w Poznaniu/Wrocławiu

[j131]

Lub, 2a01:1000:0:1::8114
PING 2a01:1000:0:1::8114(2a01:1000:0:1::8114) 56 data bytes
64 bytes from 2a01:1000:0:1::8114: icmp_seq=1 ttl=59 time=12.7 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=2 ttl=59 time=12.3 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=3 ttl=59 time=12.8 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=4 ttl=59 time=11.6 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=5 ttl=59 time=10.6 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=6 ttl=59 time=13.1 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=7 ttl=59 time=13.8 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=8 ttl=59 time=12.6 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=9 ttl=59 time=11.6 ms
64 bytes from 2a01:1000:0:1::8114: icmp_seq=10 ttl=59 time=11.8 ms

--- 2a01:1000:0:1::8114 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 10.613/12.286/13.768/0.859 ms
PING 108.61.198.102 (108.61.198.102) from 192.0.0.2 dsliteLub,: 56(84) bytes of data.
64 bytes from 108.61.198.102: icmp_seq=1 ttl=56 time=43.7 ms
64 bytes from 108.61.198.102: icmp_seq=2 ttl=56 time=41.4 ms
64 bytes from 108.61.198.102: icmp_seq=3 ttl=56 time=40.6 ms
64 bytes from 108.61.198.102: icmp_seq=4 ttl=56 time=40.8 ms
64 bytes from 108.61.198.102: icmp_seq=5 ttl=56 time=43.1 ms
64 bytes from 108.61.198.102: icmp_seq=6 ttl=56 time=42.6 ms
64 bytes from 108.61.198.102: icmp_seq=7 ttl=56 time=42.8 ms
64 bytes from 108.61.198.102: icmp_seq=8 ttl=56 time=41.6 ms
64 bytes from 108.61.198.102: icmp_seq=9 ttl=56 time=40.6 ms
64 bytes from 108.61.198.102: icmp_seq=10 ttl=56 time=44.2 ms

--- 108.61.198.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 40.600/42.138/44.187/1.245 ms
PING 52.94.141.13 (52.94.141.13) from 192.0.0.2 dsliteLub,: 56(84) bytes of data.
64 bytes from 52.94.141.13: icmp_seq=1 ttl=246 time=36.5 ms
64 bytes from 52.94.141.13: icmp_seq=2 ttl=246 time=40.3 ms
64 bytes from 52.94.141.13: icmp_seq=3 ttl=246 time=38.5 ms
64 bytes from 52.94.141.13: icmp_seq=4 ttl=246 time=37.6 ms
64 bytes from 52.94.141.13: icmp_seq=5 ttl=246 time=37.7 ms
64 bytes from 52.94.141.13: icmp_seq=6 ttl=246 time=36.6 ms
64 bytes from 52.94.141.13: icmp_seq=7 ttl=246 time=35.6 ms
64 bytes from 52.94.141.13: icmp_seq=8 ttl=246 time=38.1 ms
64 bytes from 52.94.141.13: icmp_seq=9 ttl=246 time=37.6 ms
64 bytes from 52.94.141.13: icmp_seq=10 ttl=246 time=37.8 ms

--- 52.94.141.13 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 35.556/37.623/40.261/1.202 ms
PING 52.94.56.52 (52.94.56.52) from 192.0.0.2 dsliteLub,: 56(84) bytes of data.
64 bytes from 52.94.56.52: icmp_seq=1 ttl=244 time=44.6 ms
64 bytes from 52.94.56.52: icmp_seq=2 ttl=244 time=44.8 ms
64 bytes from 52.94.56.52: icmp_seq=3 ttl=244 time=48.3 ms
64 bytes from 52.94.56.52: icmp_seq=4 ttl=244 time=46.4 ms
64 bytes from 52.94.56.52: icmp_seq=5 ttl=244 time=46.8 ms
64 bytes from 52.94.56.52: icmp_seq=6 ttl=244 time=45.6 ms
64 bytes from 52.94.56.52: icmp_seq=7 ttl=244 time=44.6 ms
64 bytes from 52.94.56.52: icmp_seq=8 ttl=244 time=43.6 ms
64 bytes from 52.94.56.52: icmp_seq=9 ttl=244 time=43.8 ms
64 bytes from 52.94.56.52: icmp_seq=10 ttl=244 time=46.1 ms

--- 52.94.56.52 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 43.628/45.473/48.268/1.376 ms

[j131]

Ols, 2a01:1000:0:1::8914
PING 2a01:1000:0:1::8914(2a01:1000:0:1::8914) 56 data bytes
64 bytes from 2a01:1000:0:1::8914: icmp_seq=1 ttl=59 time=8.76 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=2 ttl=59 time=7.57 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=3 ttl=59 time=7.77 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=4 ttl=59 time=10.1 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=5 ttl=59 time=9.61 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=6 ttl=59 time=8.62 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=7 ttl=59 time=8.77 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=8 ttl=59 time=7.61 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=9 ttl=59 time=11.3 ms
64 bytes from 2a01:1000:0:1::8914: icmp_seq=10 ttl=59 time=10.6 ms

--- 2a01:1000:0:1::8914 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 7.566/9.068/11.260/1.225 ms
PING 108.61.198.102 (108.61.198.102) from 192.0.0.2 dsliteOls,: 56(84) bytes of data.
64 bytes from 108.61.198.102: icmp_seq=1 ttl=55 time=35.7 ms
64 bytes from 108.61.198.102: icmp_seq=2 ttl=55 time=35.7 ms
64 bytes from 108.61.198.102: icmp_seq=3 ttl=55 time=33.5 ms
64 bytes from 108.61.198.102: icmp_seq=4 ttl=55 time=33.8 ms
64 bytes from 108.61.198.102: icmp_seq=5 ttl=55 time=32.6 ms
64 bytes from 108.61.198.102: icmp_seq=6 ttl=55 time=36.3 ms
64 bytes from 108.61.198.102: icmp_seq=7 ttl=55 time=35.6 ms
64 bytes from 108.61.198.102: icmp_seq=8 ttl=55 time=34.6 ms
64 bytes from 108.61.198.102: icmp_seq=9 ttl=55 time=34.8 ms
64 bytes from 108.61.198.102: icmp_seq=10 ttl=55 time=32.8 ms

--- 108.61.198.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 32.620/34.531/36.267/1.244 ms
PING 52.94.141.13 (52.94.141.13) from 192.0.0.2 dsliteOls,: 56(84) bytes of data.
64 bytes from 52.94.141.13: icmp_seq=1 ttl=245 time=32.0 ms
64 bytes from 52.94.141.13: icmp_seq=2 ttl=245 time=32.8 ms
64 bytes from 52.94.141.13: icmp_seq=3 ttl=245 time=31.6 ms
64 bytes from 52.94.141.13: icmp_seq=4 ttl=245 time=30.6 ms
64 bytes from 52.94.141.13: icmp_seq=5 ttl=245 time=29.6 ms
64 bytes from 52.94.141.13: icmp_seq=6 ttl=245 time=28.6 ms
64 bytes from 52.94.141.13: icmp_seq=7 ttl=245 time=28.8 ms
64 bytes from 52.94.141.13: icmp_seq=8 ttl=245 time=31.1 ms
64 bytes from 52.94.141.13: icmp_seq=9 ttl=245 time=30.6 ms
64 bytes from 52.94.141.13: icmp_seq=10 ttl=245 time=30.8 ms

--- 52.94.141.13 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 28.631/30.656/32.780/1.267 ms
PING 52.94.56.52 (52.94.56.52) from 192.0.0.2 dsliteOls,: 56(84) bytes of data.
64 bytes from 52.94.56.52: icmp_seq=1 ttl=243 time=38.8 ms
64 bytes from 52.94.56.52: icmp_seq=2 ttl=243 time=42.3 ms
64 bytes from 52.94.56.52: icmp_seq=3 ttl=243 time=37.0 ms
64 bytes from 52.94.56.52: icmp_seq=4 ttl=243 time=37.8 ms
64 bytes from 52.94.56.52: icmp_seq=5 ttl=243 time=36.6 ms
64 bytes from 52.94.56.52: icmp_seq=6 ttl=243 time=48.4 ms
64 bytes from 52.94.56.52: icmp_seq=7 ttl=243 time=36.1 ms
64 bytes from 52.94.56.52: icmp_seq=8 ttl=243 time=35.5 ms
64 bytes from 52.94.56.52: icmp_seq=9 ttl=243 time=34.6 ms
64 bytes from 52.94.56.52: icmp_seq=10 ttl=243 time=36.0 ms

--- 52.94.56.52 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 904ms
rtt min/avg/max/mdev = 34.624/38.301/48.391/3.934 ms

[j131]

Na koniec jeszcze, dla porównania czasy bez CGNAT, w czystym IPv4, z mojego publicznego IP (pokazujące, że czasy przez CGNAT i w czystym IPv4 mieszczą się w zakresie ~1ms, czyli że na podstawie tych pomiarów można wyrobić sobie zdanie o sytuacji w poszczególnych ośrodkach niezależnie od docelowej konfiguracji usługi):

PING 108.61.198.102 (108.61.198.102) 56(84) bytes of data.
64 bytes from 108.61.198.102: icmp_seq=1 ttl=53 time=27.8 ms
64 bytes from 108.61.198.102: icmp_seq=2 ttl=53 time=26.6 ms
64 bytes from 108.61.198.102: icmp_seq=3 ttl=53 time=25.6 ms
64 bytes from 108.61.198.102: icmp_seq=4 ttl=53 time=30.4 ms
64 bytes from 108.61.198.102: icmp_seq=5 ttl=53 time=28.5 ms
64 bytes from 108.61.198.102: icmp_seq=6 ttl=53 time=27.6 ms
64 bytes from 108.61.198.102: icmp_seq=7 ttl=53 time=27.8 ms
64 bytes from 108.61.198.102: icmp_seq=8 ttl=53 time=26.6 ms
64 bytes from 108.61.198.102: icmp_seq=9 ttl=53 time=24.5 ms
64 bytes from 108.61.198.102: icmp_seq=10 ttl=53 time=30.6 ms

--- 108.61.198.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 24.480/27.607/30.594/1.829 ms
PING 52.94.141.13 (52.94.141.13) 56(84) bytes of data.
64 bytes from 52.94.141.13: icmp_seq=1 ttl=244 time=29.9 ms
64 bytes from 52.94.141.13: icmp_seq=2 ttl=244 time=28.5 ms
64 bytes from 52.94.141.13: icmp_seq=3 ttl=244 time=28.8 ms
64 bytes from 52.94.141.13: icmp_seq=4 ttl=244 time=27.7 ms
64 bytes from 52.94.141.13: icmp_seq=5 ttl=244 time=31.3 ms
64 bytes from 52.94.141.13: icmp_seq=6 ttl=244 time=30.6 ms
64 bytes from 52.94.141.13: icmp_seq=7 ttl=244 time=29.6 ms
64 bytes from 52.94.141.13: icmp_seq=8 ttl=244 time=28.6 ms
64 bytes from 52.94.141.13: icmp_seq=9 ttl=244 time=28.8 ms
64 bytes from 52.94.141.13: icmp_seq=10 ttl=244 time=27.6 ms

--- 52.94.141.13 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 27.620/29.128/31.264/1.139 ms
PING 52.94.56.52 (52.94.56.52) 56(84) bytes of data.
64 bytes from 52.94.56.52: icmp_seq=1 ttl=242 time=37.2 ms
64 bytes from 52.94.56.52: icmp_seq=2 ttl=242 time=35.5 ms
64 bytes from 52.94.56.52: icmp_seq=3 ttl=242 time=35.8 ms
64 bytes from 52.94.56.52: icmp_seq=4 ttl=242 time=38.1 ms
64 bytes from 52.94.56.52: icmp_seq=5 ttl=242 time=37.6 ms
64 bytes from 52.94.56.52: icmp_seq=6 ttl=242 time=37.8 ms
64 bytes from 52.94.56.52: icmp_seq=7 ttl=242 time=37.8 ms
64 bytes from 52.94.56.52: icmp_seq=8 ttl=242 time=35.5 ms
64 bytes from 52.94.56.52: icmp_seq=9 ttl=242 time=35.8 ms
64 bytes from 52.94.56.52: icmp_seq=10 ttl=242 time=38.1 ms

--- 52.94.56.52 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 35.455/36.915/38.101/1.081 ms

[thatonedud]

---

@j131napisał(-a)

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.

---

Dziękuję za szczegółową odpowiedź. Zastanawia mnie jedna rzecz. Czy jest jakiś konkretny powód tak dużego mdev w testach po Twojej stronie, czy też wynika to z obciążenia sieci? Czy to typowe zjawisko? Dla porównania załączam moje testy:

[jaryn]

Z T-Mobile.

[j131]

U mnie mdev na poziomie 1-2ms jest typowe. Uważam, że to przyzwoity jitter. Poza tym w tych testach było wymuszane bardzo krótkie oczekiwanie (opcja -i 0.1), to pewnie też mogło się nie spodobać. Identycznych czasów w dziesięciu powtórzeniach nie widziałem nigdy.
Sieć jakoś szczególnie obciążona nie była, ale też nie starałem się o sterylne warunki. W realnym użytkowaniu takie się przecież nie zdarzają.

[thatonedud]

---

@j131napisał(-a)
U mnie mdev na poziomie 1-2ms jest typowe. Uważam, że to przyzwoity jitter. Poza tym w tych testach było wymuszane bardzo krótkie oczekiwanie (opcja -i 0.1), to pewnie też mogło się nie spodobać. Identycznych czasów w dziesięciu powtórzeniach nie widziałem nigdy.
Sieć jakoś szczególnie obciążona nie była, ale też nie starałem się o sterylne warunki. W realnym użytkowaniu takie się przecież nie zdarzają.

---

Mój test WinMTR został wykonany w odstępie 0.02, podczas gdy programy działające w tle korzystały z mojego Internetu. Tak czy inaczej, dziękuję jeszcze raz za wszystkie odpowiedzi 

[j131]

Jeśli chcesz sprawdzę też przy takich ultrakrótkich odstępach, pewnie wtedy będzie "równiej". Ale to dopiero po 23 września.