View Full Version : Confronto Ping FTTH
riccardi.fede
29-07-2017, 17:49
CONFRONTO PING FTTH
Obiettivo di questo thread è confrontare il ping di ogni città e di ogni gestore differente, per capire al meglio i comportamenti.
Chi avesse una linea FTTH, può fare il ping dei seguenti server:
216.58.205.67 - Google Milano
172.217.22.35 - Google Francoforte
216.58.198.163 - Google Londra
172.217.12.196 - Google Chicago
216.58.200.4 - Google Hong Kong
verygames.net - Data center OVH, Roubaix, FR
multiplay.co.uk
i3d.net - interactive3D, NL
Per semplificare, aprite CMD (Prompt dei comandi) e fate copia e incolla del seguente codice:
@ECHO OFF
echo *** Google Milano ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.205.67 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Francoforte ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 172.217.22.35 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Londra ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.198.163 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Chicago ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 172.217.12.196 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Hong Kong ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.200.4 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Verygames, OVH, Roubaix, Francoforte (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping verygames.net -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** multiplay.co.uk - Inghilterra (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping multiplay.co.uk -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Interactive3D - Olanda (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping i3d.net -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
pause
[Chi avesse il MAC, trova il codice qua (http://www.hwupgrade.it/forum/showpost.php?p=44991235&postcount=224).]
Quando su CMD visualizzate "Pause", sul desktop avrete un file di testo "risultati-ping.txt". Nel caso non lo troviate, utilizzate la funzione cerca/trova del vostro PC.
Uploadatelo QUI (http://textuploader.com/), impostando come "Expiration" = NEVER e condividete il link sul thread, insieme alla vostra città e il vostro gestore.
Il risultato finale sarà un documento excel, corredato da grafici in cui per ogni città in FTTH, si confronterà l'operatore migliore in fatto di ping.
Grazie e aspetto i vostri test per completare l'indagine!
Un grazie a EliGabriRock44 per l'idea; ad Aereo per tutti i suoi preziosi suggerimenti e infine a tutti coloro che ci stanno supportando.
_________________________________________________________
RISULTATI
In questo link (https://drive.google.com/open?id=18mro20oY_I_5k9cmS3HiVnEQHIjegiXa) trovate il file Excel per ogni città, con i confronti per ogni operatore.
Invece qui, trovate direttamente il grafico, per un confronto immediato:
Ancona (https://drive.google.com/open?id=1vRMiDUXiSq815jhKtEefzGpz1f_1t_U7)
Bari (https://drive.google.com/open?id=1u9N91UOV04XEj_AkECKTBIusoBYlqGez)
Bergamo (https://drive.google.com/open?id=1ltzRTb8MvjjQKNQAReBkGSRVJtvHJEwo)
Bologna (https://drive.google.com/open?id=10vwijWjgdLV14jQcvnaEz24wqCtJdu46)
Cagliari (https://drive.google.com/open?id=11xL0mr2cI9wDlvQQBjoRdbHZwbzqFInH)
Catania (https://drive.google.com/open?id=1FB4pf8BwU7FGDu2BZyixZsfMxVFaWcTF)
Genova (https://drive.google.com/open?id=1M-z7JD6tkKuqIAHJVuRsyOITWaQzsXol)
Messina (https://drive.google.com/open?id=1SgeEcAbrW3tOb2h9viMGrbVcYBa3aEHF)
Milano (https://drive.google.com/open?id=1ucILg6wG9DOo7NpkL8tketDhzBD4pleZ)
Modena (https://drive.google.com/open?id=1X4Rqrmlxb81_A96th-THf_ZMYxkLvvqH)
Monza (https://drive.google.com/open?id=1v7kpn7UAJPYNhyZ5ZL56AYO9-ShNEQpt)
Napoli (https://drive.google.com/open?id=1rMU_26gXGmFl9QOin8En17cBMm2aal_L)
Padova (https://drive.google.com/open?id=1DFAxHOgmPLGszhjIwD6G1qiiDEn2XQfE)
Palermo (https://drive.google.com/open?id=1BoMU5FoNdx2Z_TT-O6srDhh--YfaYPWB)
Parma (https://drive.google.com/open?id=1h9fuHIp5Bp4tXqtBq8uVdxA4V3w-ZHNg)
Perugia (https://drive.google.com/open?id=1exI5W8VTjuqSfRWvnWfHtz2qcsYSC-kA)
Pescara (https://drive.google.com/open?id=1T5s81DyxLq7CZlhxZSbLbnt66pEQTAAz)
Roma (https://drive.google.com/open?id=1g9urMhMjDdHH9a359bg38ZV8Bzfz8fWt)
Torino (https://drive.google.com/open?id=1lo-163ZRVXW_y_lpHN2sjtPaEEHvvcep)
Trieste (https://drive.google.com/open?id=1otagD0tk5PhQGcfk6ImK9n1ZWh7T1OrW)
Udine (https://drive.google.com/open?id=1RpHnfzTniCRRslpAnVtJ8xxHGRotiofY)
Venezia (https://drive.google.com/open?id=1DajaqQv6Wmw3IfVsqEY8Jj1hgeqsOoy4)
cartmanland
29-07-2017, 18:32
città: Torino
ISP: Vodafone FTTH 1 gbit/s
file .bat che ho usato:
@ECHO OFF
ping 216.58.205.67 -n 10 >> output-ping.txt
ping 172.217.22.35 -n 10 >> output-ping.txt
ping 216.58.198.163 -n 10 >> output-ping.txt
ping 172.217.12.196 -n 10 >> output-ping.txt
ping 216.58.200.4 -n 10 >> output-ping.txt
pause
output:
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Ping statistics for 216.58.205.67:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 6ms, Average = 5ms
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Reply from 172.217.22.35: bytes=32 time=14ms TTL=52
Ping statistics for 172.217.22.35:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 14ms, Average = 14ms
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=26ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=26ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=26ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Ping statistics for 216.58.198.163:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 27ms, Average = 26ms
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Ping statistics for 172.217.12.196:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 95ms, Maximum = 96ms, Average = 95ms
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Reply from 216.58.200.4: bytes=32 time=288ms TTL=44
Ping statistics for 216.58.200.4:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 288ms, Maximum = 288ms, Average = 288ms
peronedj
29-07-2017, 18:37
A Palermo con Vodafone sono messo abbastanza male:
216.58.205.67 | Minimo = 27ms, Massimo = 29ms, Medio = 28ms
172.217.22.35 | Minimo = 40ms, Massimo = 41ms, Medio = 40ms
216.58.198.163 | Minimo = 50ms, Massimo = 51ms, Medio = 50ms
172.217.12.196 | Minimo = 118ms, Massimo = 119ms, Medio = 118ms
216.58.200.4 | Minimo = 317ms, Massimo = 318ms, Medio = 317ms
Da cosa può dipendere?
Se può servire, lo speedtest sul server di Vodafone Milano è:
ping 29ms
down 905Mbps
up 181Mbps
whatever
29-07-2017, 18:40
Probabilmente ti interessano solo le nuove gpon ma rispondo comunque
Torino, Fastweb 100 mega
Risposta da 216.58.205.67: byte=32 durata=4ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=4ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=4ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=4ms TTL=54
Risposta da 172.217.22.35: byte=32 durata=13ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=13ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=13ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=13ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=27ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=25ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=25ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=25ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=98ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=97ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=97ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=97ms TTL=49
Risposta da 216.58.200.4: byte=32 durata=287ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=286ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=286ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=286ms TTL=44
EliGabriRock44
29-07-2017, 18:44
Ho aperto questa nuova discussione, in quanto vorrei fare un confronto del ping tra utenti FTTH, soprattutto nelle diverse città, per confrontare le differenze tra Nord e Sud.
Vi chiedo pertanto se potreste indicarmi il ping dei seguenti server,
216.58.205.67
172.217.22.35
216.58.198.163
172.217.12.196
216.58.200.4
indicandomi inoltre il vostro gestore e la città.
Il risultato finale sarà un documento excel in cui per ogni città in FTTH, si confronterà l'operatore migliore in fatto di ping.
Grazie e aspetto i vostri test per completare l'indagine!
Si ma scusa un secondo, almeno dimmelo che lo richiedi a destra e manca! La tabella excel ce l'ho io, anche se puoi farla benissimo tu... vabè
riccardi.fede
29-07-2017, 19:37
Si ma scusa un secondo, almeno dimmelo che lo richiedi a destra e manca! La tabella excel ce l'ho io, anche se puoi farla benissimo tu... vabè
Ora lo sai :D
Che lo richiedo direi di no, abbiamo nuovi dati. In più almeno abbiamo un thread e possiamo parlarne qua :)
Hai dati in più rispetto a me?
riccardi.fede
29-07-2017, 19:38
@Whatever @cartmanland: ottimo e grazie!
@peronedj: grazie anche a te. Dipende dall'instradamento dell'operatore.
Ho aperto questa nuova discussione, in quanto vorrei fare un confronto del ping tra utenti FTTH, soprattutto nelle diverse città, per confrontare le differenze tra Nord e Sud.
Vi chiedo pertanto se potreste indicarmi il ping dei seguenti server,
216.58.205.67
172.217.22.35
216.58.198.163
172.217.12.196
216.58.200.4
indicandomi inoltre il vostro gestore e la città.
Il risultato finale sarà un documento excel in cui per ogni città in FTTH, si confronterà l'operatore migliore in fatto di ping.
Grazie e aspetto i vostri test per completare l'indagine!
PS: un grazie a EliGabriRock44 per l'idea.
Bravissimi EliGabriRock44 e Fede! Ottima idea! :) Io aggiungerei di pingare "alla vecchia maniera" anche:
ping -n 10 google.it
ping -n 10 google.com
ping -n 10 maya.ngi.it
Grazie :)
PS:
Quegli ip a quali server corrispondono esattamente?
Il primo IP è già quello di google.it e va a corrispondere a quello verso ngi che è sempre a Milano.
Google.com onestamente non so dove sia, presumo USA, quindi non ha molto senso.
Bene o male gli instradamenti verso l' estero passano tutti per Milano quindi saranno tutti uguali da lì in poi. La differenza la fa il ping verso Milano.
Il primo IP è già quello di google.it e va a corrispondere a quello verso ngi che è sempre a Milano.
Google.com onestamente non so dove sia, presumo USA, quindi non ha molto senso.
Ma se fosse in USA non dovrebbe dare risultati nettamente maggiori? Perché quando provo io sono quasi uguali a google.it.
Bene o male gli instradamenti verso l' estero passano tutti per Milano quindi saranno tutti uguali da lì in poi. La differenza la fa il ping verso Milano.
Ok.
EliGabriRock44
30-07-2017, 08:55
Il primo IP è già quello di google.it e va a corrispondere a quello verso ngi che è sempre a Milano.
Google.com onestamente non so dove sia, presumo USA, quindi non ha molto senso.
Bene o male gli instradamenti verso l' estero passano tutti per Milano quindi saranno tutti uguali da lì in poi. La differenza la fa il ping verso Milano.
Per quello ho selezionato 5 IP di 5 server google situati in giro per il mondo.
Per quello ho selezionato 5 IP di 5 server google situati in giro per il mondo.
Quindi sono tutti server Google in posti diversi, ok grazie.
Ma se fosse in USA non dovrebbe dare risultati nettamente maggiori? Perché quando provo io sono quasi uguali a google.it.
Ok.
Aspetta perchè verso google.com non riesci a pingare perchè reindirizza verso google.it.
Se eli anzinchè darci gli ip ci avesse detto " pinga verso google.it,google.de,google.fr etc" avresti avuto sempre lo stesso risultato.
Tra l' altro google.com sarebbe comunque troppo generico perchè google ha diversi server all' interno degli usa quindi l' ip di google della costa est, per esempio, non corrisponderebbe a quello della costa ovest.
Aspetta perchè verso google.com non riesci a pingare perchè reindirizza verso google.it.
Se eli anzinchè darci gli ip ci avesse detto " pinga verso google.it,google.de,google.fr etc" avresti avuto sempre lo stesso risultato.
Svelato l'arcano, grazie!
Tra l' altro google.com sarebbe comunque troppo generico perchè google ha diversi server all' interno degli usa quindi l' ip di google della costa est, per esempio, non corrisponderebbe a quello della costa ovest.
Giusto!
Quali sono le rispettive città dei server elencati nel primo post? Ho fatto una ricerca e del primo mi dice che sarebbe in California, ma dai miei valori mi sembra strano.
NB:
Io sono a Bologna e con FTTC TIM 100/20 Mb/sec (non è FTTH, però almeno contribuisco un po' anch'io):
216.58.205.67 (Milano): 8 ms
172.217.22.35 (Francoforte): 17 ms
216.58.198.163 (Londra): 29 ms
172.217.12.196 (Chicago): 106 ms
216.58.200.4 (Hong Kong): 304 ms
EliGabriRock44
30-07-2017, 11:09
Svelato l'arcano, grazie!
Giusto!
Quali sono le rispettive città dei server elencati nel primo post?
PS:
Io sono a Bologna e con FTTC TIM 100/20 Mb/sec (non è FTTH, però almeno contribuisco un po' anch'io):
216.58.205.67: 8 ms
172.217.22.35: 17 ms
216.58.198.163: 29 ms
172.217.12.196: 106 ms
216.58.200.4: 304 ms
Milano, Francoforte, Londra, Chicago e HongKong.
Li puoi scoprire tranquillamente su https://check-host.net
Milano, Francoforte, Londra, Chicago e HongKong.
Li puoi scoprire tranquillamente su https://check-host.net
Grazie Eli! Avevo proprio appena aggiornato il mio post: non so perché a me dava come "California", ed 8 ms mi sembravano molto strani :D Aggiorno di nuovo con la lista delle città (si, sono un maniaco dell'ordine :D).
PS:
Tra Chicago ed Hong Kong c'è una differenza del triplo, nonostante la prima risulti a 7200 km mentre la seconda a 9200 km: significa che viene instradato in modo particolare verso Hong Kong? Perché 2000 km in più non dovrebbero motivare il triplo della latenza.
Grazie Eli! Avevo proprio appena aggiornato il mio post: non so perché a me dava come "California", ed 8 ms mi sembravano molto strani :D Aggiorno di nuovo con la lista delle città (si, sono un maniaco dell'ordine :D).
PS:
Tra Chicago ed Hong Kong c'è una differenza del triplo, nonostante la prima risulti a 7200 km mentre la seconda a 9200 km: significa che viene instradato in modo particolare verso Hong Kong? Perché 2000 km in più non dovrebbero motivare il triplo della latenza.
Perchè tra Europa ed America c' è di mezzo la dorsale oceanica, tra europa ed estremo oriente essendo su terra ci sono un sacco di nodi. La distanza, se ci fosse un solo lunghissimo cavo in fibra che unisse 2 punti, non sarebbe un problema!
La distanza conta, non scriviamo inesattezze per cortesia.
La FO ha una latenza di circa 0,005 ms/km, poi ci sono i rigeneratori ottici interposti ogni tot km che la fanno aumentare di altri 0,1 ms circa, i router che smistano i pacchetti eccetera eccetera...
Il server del dns google ovviamente non si trova in USA ma in Italia, o al limite paesi confinanti, altrimenti te la sogneresti una latenza del genere.
Aggiungo che il traffico verso l'Oriente spesso viene instradato verso gli USA; quindi ti fai tutto il continente coast to coast, accumulando latenze di almeno 150-200 ms prima di arrivare in Asia.
In effetti il divario è proprio di circa 200 ms tra Chicago ed Hong Kong!
La distanza conta, non scriviamo inesattezze per cortesia.
La FO ha una latenza di circa 0,005 ms/km, poi ci sono i rigeneratori ottici interposti ogni tot km che la fanno aumentare di altri 0,1 ms circa, i router che smistano i pacchetti eccetera eccetera...
Il server del dns google ovviamente non si trova in USA ma in Italia, o al limite paesi confinanti, altrimenti te la sogneresti una latenza del genere.
Ho riletto tutti i messaggi ma non trovo nessuno che affermi che la distanza non conta.
Ho riletto tutti i messaggi ma non trovo nessuno che affermi che la distanza non conta.
Beh forse ho frainteso il tuo post, ma hai scritto che la distanza non sarebbe un problema in caso ipotetico di cavo lunghissimo in FO tra due punti.
MacBookPro: ping 216.58.205.67
PING 216.58.205.67 (216.58.205.67): 56 data bytes
64 bytes from 216.58.205.67: icmp_seq=0 ttl=52 time=10.975 ms
64 bytes from 216.58.205.67: icmp_seq=1 ttl=52 time=11.049 ms
64 bytes from 216.58.205.67: icmp_seq=2 ttl=52 time=10.822 ms
64 bytes from 216.58.205.67: icmp_seq=3 ttl=52 time=10.885 ms
64 bytes from 216.58.205.67: icmp_seq=4 ttl=52 time=10.947 ms
64 bytes from 216.58.205.67: icmp_seq=5 ttl=52 time=10.789 ms
64 bytes from 216.58.205.67: icmp_seq=6 ttl=52 time=10.986 ms
^C
--- 216.58.205.67 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.789/10.922/11.049/0.087 ms
MacBookPro:
MacBookPro: ping 172.217.22.35
PING 172.217.22.35 (172.217.22.35): 56 data bytes
64 bytes from 172.217.22.35: icmp_seq=0 ttl=52 time=19.416 ms
64 bytes from 172.217.22.35: icmp_seq=1 ttl=52 time=19.563 ms
64 bytes from 172.217.22.35: icmp_seq=2 ttl=52 time=19.272 ms
64 bytes from 172.217.22.35: icmp_seq=3 ttl=52 time=19.385 ms
64 bytes from 172.217.22.35: icmp_seq=4 ttl=52 time=19.445 ms
64 bytes from 172.217.22.35: icmp_seq=5 ttl=52 time=19.179 ms
64 bytes from 172.217.22.35: icmp_seq=6 ttl=52 time=19.457 ms
^C
--- 172.217.22.35 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.179/19.388/19.563/0.117 ms
MacBookPro:
MacBookPro: ping 216.58.198.163
PING 216.58.198.163 (216.58.198.163): 56 data bytes
64 bytes from 216.58.198.163: icmp_seq=0 ttl=50 time=32.478 ms
64 bytes from 216.58.198.163: icmp_seq=1 ttl=50 time=32.721 ms
64 bytes from 216.58.198.163: icmp_seq=2 ttl=50 time=32.723 ms
64 bytes from 216.58.198.163: icmp_seq=3 ttl=50 time=32.776 ms
64 bytes from 216.58.198.163: icmp_seq=4 ttl=50 time=32.808 ms
64 bytes from 216.58.198.163: icmp_seq=5 ttl=50 time=32.652 ms
64 bytes from 216.58.198.163: icmp_seq=6 ttl=50 time=32.652 ms
64 bytes from 216.58.198.163: icmp_seq=7 ttl=50 time=32.790 ms
^C
--- 216.58.198.163 ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.478/32.700/32.808/0.100 ms
MacBookPro:
MacBookPro: ping 172.217.12.196
PING 172.217.12.196 (172.217.12.196): 56 data bytes
64 bytes from 172.217.12.196: icmp_seq=0 ttl=50 time=100.847 ms
64 bytes from 172.217.12.196: icmp_seq=1 ttl=50 time=100.950 ms
64 bytes from 172.217.12.196: icmp_seq=2 ttl=50 time=101.006 ms
64 bytes from 172.217.12.196: icmp_seq=3 ttl=50 time=101.314 ms
64 bytes from 172.217.12.196: icmp_seq=4 ttl=50 time=100.986 ms
^C
--- 172.217.12.196 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 100.847/101.021/101.314/0.157 ms
MacBookPro:
MacBookPro: ping 216.58.200.4
PING 216.58.200.4 (216.58.200.4): 56 data bytes
64 bytes from 216.58.200.4: icmp_seq=0 ttl=42 time=292.162 ms
64 bytes from 216.58.200.4: icmp_seq=1 ttl=42 time=291.847 ms
64 bytes from 216.58.200.4: icmp_seq=2 ttl=42 time=292.448 ms
64 bytes from 216.58.200.4: icmp_seq=3 ttl=42 time=291.965 ms
64 bytes from 216.58.200.4: icmp_seq=4 ttl=42 time=291.994 ms
64 bytes from 216.58.200.4: icmp_seq=5 ttl=42 time=292.408 ms
64 bytes from 216.58.200.4: icmp_seq=6 ttl=42 time=291.907 ms
^C
--- 216.58.200.4 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 291.847/292.104/292.448/0.224 ms
MacBookPro:
Gestore Vodafone 1000/200 - 2 utenze FTTH nel palazzo - Bologna Zona San Ruffillo.
@kkaarlo
E sei il terzo bolognese che becco in due giorni (oltre a MisterFTTH e lamummia) :D
@MisterFTTH
Ottimo! Comunque mi sembra che non ci sia gran differenza tra la mia FTTC TIM e le vostre FTTH per il ping, cosa ne pensi?
riccardi.fede
30-07-2017, 20:59
Riporto anche i miei valori di latenza per le mie due linee FTTH in Bologna.
[....]
Ottimo! Quando avrai anche la linea Tiscali, facci sapere il ping :)
Grazie!
aeroxdefocu
30-07-2017, 21:04
Bologna FTTH Wind 500mbps(dovrebbe diventare 1gbps)
216.58.205.67 ---> 16ms
172.217.22.35 ---> 24ms
216.58.198.163 ---> 25ms
172.217.12.196 ---> 106ms
216.58.200.4 ---> 293ms
Test effettuato con DNS standard e non google
furiaceka87
31-07-2017, 09:29
Bologna FTTH Wind 500mbps(dovrebbe diventare 1gbps)
216.58.205.67 ---> 16ms
172.217.22.35 ---> 24ms
216.58.198.163 ---> 25ms
172.217.12.196 ---> 106ms
216.58.200.4 ---> 293ms
Test effettuato con DNS standard e non google
di dove sei?
riccardi.fede
31-07-2017, 09:36
di dove sei?
Bologna. C'è scritto all'inizio del post :p
sergio.pg
31-07-2017, 10:11
Infostrada FTTH 500 a Perugia:
64 bytes from 216.58.205.67: icmp_seq=1 ttl=54 time=15.0 ms
64 bytes from 216.58.205.67: icmp_seq=2 ttl=54 time=14.9 ms
64 bytes from 216.58.205.67: icmp_seq=3 ttl=54 time=14.6 ms
64 bytes from 216.58.205.67: icmp_seq=4 ttl=54 time=14.9 ms
64 bytes from 216.58.205.67: icmp_seq=5 ttl=54 time=14.7 ms
64 bytes from 216.58.205.67: icmp_seq=6 ttl=54 time=14.8 ms
64 bytes from 216.58.205.67: icmp_seq=7 ttl=54 time=14.7 ms
64 bytes from 216.58.205.67: icmp_seq=8 ttl=54 time=14.6 ms
64 bytes from 216.58.205.67: icmp_seq=9 ttl=54 time=14.9 ms
64 bytes from 216.58.205.67: icmp_seq=10 ttl=54 time=14.7 ms
rtt min/avg/max/mdev = 14.673/14.834/15.058/0.138 ms
64 bytes from 172.217.22.35: icmp_seq=1 ttl=52 time=24.9 ms
64 bytes from 172.217.22.35: icmp_seq=2 ttl=52 time=25.0 ms
64 bytes from 172.217.22.35: icmp_seq=3 ttl=52 time=24.6 ms
64 bytes from 172.217.22.35: icmp_seq=4 ttl=52 time=24.7 ms
64 bytes from 172.217.22.35: icmp_seq=5 ttl=52 time=24.8 ms
64 bytes from 172.217.22.35: icmp_seq=6 ttl=52 time=24.6 ms
64 bytes from 172.217.22.35: icmp_seq=7 ttl=52 time=24.8 ms
64 bytes from 172.217.22.35: icmp_seq=8 ttl=52 time=24.7 ms
64 bytes from 172.217.22.35: icmp_seq=9 ttl=52 time=24.6 ms
64 bytes from 172.217.22.35: icmp_seq=10 ttl=52 time=24.7 ms
rtt min/avg/max/mdev = 24.619/24.792/25.007/0.232 ms
64 bytes from 216.58.198.163: icmp_seq=1 ttl=50 time=34.2 ms
64 bytes from 216.58.198.163: icmp_seq=2 ttl=50 time=33.7 ms
64 bytes from 216.58.198.163: icmp_seq=3 ttl=50 time=33.7 ms
64 bytes from 216.58.198.163: icmp_seq=4 ttl=50 time=34.1 ms
64 bytes from 216.58.198.163: icmp_seq=5 ttl=50 time=34.3 ms
64 bytes from 216.58.198.163: icmp_seq=6 ttl=50 time=33.7 ms
64 bytes from 216.58.198.163: icmp_seq=7 ttl=50 time=33.8 ms
64 bytes from 216.58.198.163: icmp_seq=8 ttl=50 time=33.7 ms
64 bytes from 216.58.198.163: icmp_seq=9 ttl=50 time=33.7 ms
64 bytes from 216.58.198.163: icmp_seq=10 ttl=50 time=33.9 ms
rtt min/avg/max/mdev = 33.748/33.946/34.399/0.335 ms
64 bytes from 172.217.12.196: icmp_seq=1 ttl=50 time=107 ms
64 bytes from 172.217.12.196: icmp_seq=2 ttl=50 time=107 ms
64 bytes from 172.217.12.196: icmp_seq=3 ttl=50 time=107 ms
64 bytes from 172.217.12.196: icmp_seq=4 ttl=50 time=108 ms
64 bytes from 172.217.12.196: icmp_seq=5 ttl=50 time=107 ms
64 bytes from 172.217.12.196: icmp_seq=6 ttl=50 time=107 ms
64 bytes from 172.217.12.196: icmp_seq=7 ttl=50 time=108 ms
64 bytes from 172.217.12.196: icmp_seq=8 ttl=50 time=107 ms
64 bytes from 172.217.12.196: icmp_seq=9 ttl=50 time=107 ms
64 bytes from 172.217.12.196: icmp_seq=10 ttl=50 time=107 ms
rtt min/avg/max/mdev = 107.683/107.873/108.064/0.179 ms
64 bytes from 216.58.200.4: icmp_seq=1 ttl=44 time=301 ms
64 bytes from 216.58.200.4: icmp_seq=2 ttl=44 time=301 ms
64 bytes from 216.58.200.4: icmp_seq=3 ttl=44 time=302 ms
64 bytes from 216.58.200.4: icmp_seq=4 ttl=44 time=301 ms
64 bytes from 216.58.200.4: icmp_seq=5 ttl=44 time=302 ms
64 bytes from 216.58.200.4: icmp_seq=6 ttl=44 time=301 ms
64 bytes from 216.58.200.4: icmp_seq=7 ttl=44 time=302 ms
64 bytes from 216.58.200.4: icmp_seq=8 ttl=44 time=301 ms
64 bytes from 216.58.200.4: icmp_seq=9 ttl=44 time=302 ms
64 bytes from 216.58.200.4: icmp_seq=10 ttl=44 time=302 ms
rtt min/avg/max/mdev = 301.446/302.008/302.303/0.339 ms
Beh forse ho frainteso il tuo post, ma hai scritto che la distanza non sarebbe un problema in caso ipotetico di cavo lunghissimo in FO tra due punti.
Sono stato troppo generico e per quello hai frainteso.
Prendo spunto dal tuo messaggio precedente: facendo il traceroute verso l' ip di HK in effetti si passa attraverso gli USA. Invece pingando verso l' India ( es: 14.102.33.125) si fa la dorsale che attraversa mediterraneo, mar Rosso etc..
Quale può essere il motivo secondo te? Il tragitto sarebbe sicuramente più veloce continuando nell' Oceano Indiano. ( poi magari questo è l' instradamento solo del mio operatore-tim- e tutto il discorso salta..)
Ottimo! Comunque mi sembra che non ci sia gran differenza tra la mia FTTC TIM e le vostre FTTH per il ping, cosa ne pensi?
No anzi considerando la tara dei 5ms della tua fttc verso il gateway ( ms più , ms meno) è migliore l' instradamento della tua fttc. Non parliamo poi di Perugia.
Sarebbe interessante un confronto tra i vari traceroute ( Fttc bologna, ftth bologna, ftth perugia) verso un server di Milano. Potreste usare ngi per semplicità.
Sono stato troppo generico e per quello hai frainteso.
Prendo spunto dal tuo messaggio precedente: facendo il traceroute verso l' ip di HK in effetti si passa attraverso gli USA. Invece pingando verso l' India ( es: 14.102.33.125) si fa la dorsale che attraversa mediterraneo, mar Rosso etc..
Quale può essere il motivo secondo te? Il tragitto sarebbe sicuramente più veloce continuando nell' Oceano Indiano. ( poi magari questo è l' instradamento solo del mio operatore-tim- e tutto il discorso salta..)
Dipende dal routing degli operatori e dalle rotte. TIM instrada anche tramite i cavi sottomarini che attraversano il canale di Suez (tipo SEA-ME-WE3 e 5); ricordo di aver fatto dei test con alcuni server giapponesi e si veniva instradati su Singapore, con latenze un po' più basse del solito.
Con Infostrada non ho fatto molti test "intercontinentali" per ora, ma il grosso del traffico diretto verso l'Estremo Oriente dovrebbe fare ancora il percorso USA-Pacifico.
No anzi considerando la tara dei 5ms della tua fttc verso il gateway ( ms più , ms meno) è migliore l' instradamento della tua fttc. Non parliamo poi di Perugia.
La tara delle FTTH quant'è?
Sarebbe interessante un confronto tra i vari traceroute ( Fttc bologna, ftth bologna, ftth perugia) verso un server di Milano. Potreste usare ngi per semplicità.
FTTC TIM 100/20 Bologna:
Rilevazione instradamento verso test.ngi.it [88.149.202.248]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.89.185
4 5 ms 4 ms 4 ms 172.17.88.93
5 * * 5 ms 172.17.5.77
6 10 ms 11 ms 11 ms 172.17.14.161
7 12 ms 12 ms 12 ms 172.19.0.251
8 13 ms 11 ms 11 ms 195.31.82.206
9 14 ms 14 ms 13 ms 217-221-48-218-static.albacom.net [217.221.48.218]
10 * * * Richiesta scaduta.
11 12 ms 12 ms 12 ms 88-149-202-248.v4.ngi.it [88.149.202.248]
Rilevazione completata.
PS:
Per la FTTH Bologna aspetta l'amico MisterFTTH che può dare feedback sia su TIM che su Vodafone (e speriamo a breve Tiscali).
sergio.pg
31-07-2017, 12:18
No anzi considerando la tara dei 5ms della tua fttc verso il gateway ( ms più , ms meno) è migliore l' instradamento della tua fttc. Non parliamo poi di Perugia.
Sarebbe interessante un confronto tra i vari traceroute ( Fttc bologna, ftth bologna, ftth perugia) verso un server di Milano. Potreste usare ngi per semplicità.
La distanza tra Perugia e Milano è più del doppio più grande che da Bologna, è normale che la latenza sia il doppio. Ecco il traceroute:
traceroute to test.ngi.it (88.149.202.248), 30 hops max, 60 byte packets
1 gateway 0.545 ms 0.693 ms 0.880 ms
2 * * *
3 151.7.32.116 (151.7.32.116) 10.564 ms 10.567 ms 10.554 ms
4 151.7.32.16 (151.7.32.16) 11.597 ms 151.7.32.70 (151.7.32.70) 11.599 ms 151.7.32.12 (151.7.32.12) 12.410 ms
5 151.6.5.190 (151.6.5.190) 16.993 ms 17.555 ms 151.6.0.91 (151.6.0.91) 17.044 ms
6 151.6.1.180 (151.6.1.180) 18.554 ms 151.6.1.182 (151.6.1.182) 14.502 ms 151.6.1.178 (151.6.1.178) 15.578 ms
7 btglobal.mix-it.net (217.29.66.119) 15.964 ms 15.967 ms 16.750 ms
8 t2c3-xe-0-0-0-1.it-mil2.eu.bt.net (166.49.237.82) 16.936 ms 16.900 ms 17.114 ms
9 166-49-243-130.eu.bt.net (166.49.243.130) 26.734 ms 26.227 ms 26.726 ms
10 217-221-48-218-static.albacom.net (217.221.48.218) 28.989 ms 29.531 ms 28.985 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 *^C
Con Infostrada non ho fatto molti test "intercontinentali" per ora, ma il grosso del traffico diretto verso l'Estremo Oriente dovrebbe fare ancora il percorso USA-Pacifico.
Fatti un paio in questo momento.
Anche per il Giappone si può essere instradati verso gli USA - Oceano Pacifico (primo traceroute) oppure Canale di Suez - Mar Rosso - Singapore (secondo traceroute).
Traccia instradamento verso 45.63.120.97.vultr.com [45.63.120.97]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 5 ms 151.7.32.104
4 5 ms 5 ms 5 ms 151.7.32.12
5 12 ms 10 ms 11 ms 151.6.5.190
6 11 ms 10 ms 10 ms 151.6.1.176
7 10 ms 10 ms 10 ms et-1-1-0-xcr1.mlu.cw.net [195.2.10.133]
8 98 ms 98 ms 98 ms ae0-xcr1.mlb.cw.net [195.2.25.98]
9 98 ms 100 ms 100 ms ae33-xcr1.ptl.cw.net [195.2.25.254]
10 97 ms 98 ms 98 ms et-7-1-0-xcr1.nyh.cw.net [195.2.24.241]
11 98 ms 103 ms 98 ms ae13-xcr2.nyk.cw.net [195.2.25.69]
12 99 ms 99 ms 99 ms ae-36.r08.nycmny01.us.bb.gin.ntt.net [128.241.2.
153]
13 97 ms 97 ms 99 ms ae-3.r24.nycmny01.us.bb.gin.ntt.net [129.250.5.6
1]
14 225 ms 225 ms 225 ms ae-2.r20.sttlwa01.us.bb.gin.ntt.net [129.250.4.1
3]
15 277 ms 277 ms 277 ms ae-0.r21.sttlwa01.us.bb.gin.ntt.net [129.250.2.5
4]
16 239 ms 234 ms 233 ms ae-3.r23.snjsca04.us.bb.gin.ntt.net [129.250.3.1
24]
17 338 ms * * ae-21.r30.tokyjp05.jp.bb.gin.ntt.net [129.250.5.
77]
18 390 ms 390 ms 390 ms ae-5.r02.tokyjp03.jp.bb.gin.ntt.net [129.250.3.2
51]
19 330 ms * 330 ms ae-0.choopa.tokyjp03.jp.bb.gin.ntt.net [117.103.
177.122]
20 326 ms 326 ms 326 ms vl508-ds1-b5-2407.tyo1.choopa.net [45.32.30.94]
21 * * * Richiesta scaduta.
22 386 ms 386 ms 386 ms 45.63.120.97.vultr.com [45.63.120.97]
Traccia completata.
Traccia instradamento verso 45.121.184.137 su un massimo di 30 punti di passaggi
o
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 151.7.32.104
4 5 ms 4 ms 5 ms 151.7.32.74
5 10 ms 10 ms 10 ms 151.6.2.76
6 10 ms 10 ms 10 ms 151.6.1.237
7 40 ms 29 ms 29 ms 100ge7-2.core1.fra1.he.net [80.81.192.172]
8 41 ms 47 ms 41 ms 100ge5-2.core1.par2.he.net [72.52.92.13]
9 34 ms 34 ms 34 ms flag-as-as15412.10gigabitethernet7-13.core1.par2
.he.net [216.66.89.214]
10 215 ms 215 ms 215 ms 62.216.128.197
11 212 ms 211 ms 211 ms xe-8-1-1.0.pjr03.mmb004.flagtel.com [85.95.25.11
3]
12 217 ms 212 ms 233 ms ge-3-1-0.0.pjr01.mmb004.flagtel.com [85.95.26.22
9]
13 244 ms 223 ms 215 ms so-0-0-0.0.ejr03.sin001.flagtel.com [85.95.25.98
]
14 217 ms 212 ms 212 ms so-7-1-0.0.ejr04.sin001.flagtel.com [62.216.128.
153]
15 222 ms 214 ms 214 ms xe-1-0-2.0.cjr01.sin001.flagtel.com [62.216.137.
149]
16 276 ms 277 ms 279 ms 80.81.65.122
17 279 ms 281 ms 278 ms 192.168.150.22
18 305 ms 310 ms 297 ms 192.168.152.9
19 278 ms 278 ms 278 ms 45.121.184.137
Traccia completata.
TIM
traceroute to test.ngi.it (88.149.202.248), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.819 ms 0.853 ms 0.909 ms
2 * * *
3 172.17.88.216 (172.17.88.216) 5.547 ms 172.17.88.220 (172.17.88.220) 5.540 ms 172.17.89.185 (172.17.89.185) 5.536 ms
4 172.17.88.85 (172.17.88.85) 5.559 ms 172.17.88.161 (172.17.88.161) 5.561 ms 172.17.88.169 (172.17.88.169) 5.613 ms
5 172.17.14.161 (172.17.14.161) 15.330 ms 15.332 ms 172.17.14.169 (172.17.14.169) 12.668 ms
6 172.17.9.21 (172.17.9.21) 13.365 ms 10.839 ms 172.19.0.251 (172.19.0.251) 10.041 ms
7 195.31.82.206 (195.31.82.206) 21.264 ms 19.831 ms 21.246 ms
8 217-221-48-218-static.albacom.net (217.221.48.218) 23.625 ms 23.606 ms 24.485 ms
9 217-221-48-218-static.albacom.net (217.221.48.218) 23.585 ms * 18.806 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Vodafone
traceroute to test.ngi.it (88.149.202.248), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 7.911 ms 7.905 ms 7.887 ms
2 net-93-66-140-1.cust.vodafonedsl.it (93.66.140.1) 38.182 ms 38.253 ms 38.292 ms
3 83.224.40.182 (83.224.40.182) 8.550 ms 8.560 ms 8.555 ms
4 83.224.40.181 (83.224.40.181) 8.610 ms 8.673 ms 8.721 ms
5 83.224.40.217 (83.224.40.217) 15.713 ms 16.105 ms 17.161 ms
6 83.224.40.230 (83.224.40.230) 17.235 ms 12.011 ms 11.045 ms
7 85.205.14.101 (85.205.14.101) 21.741 ms 21.649 ms 21.761 ms
8 btitalia.mix-it.net (217.29.66.40) 14.873 ms 14.783 ms 16.525 ms
9 tr3-mi2-Te0100.v502.btitalia.it (213.255.14.74) 16.575 ms 16.655 ms 18.840 ms
10 217-221-48-218-static.albacom.net (217.221.48.218) 18.925 ms 18.968 ms 11.506 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
La distanza tra Perugia e Milano è più del doppio più grande che da Bologna, è normale che la latenza sia il doppio. Ecco il traceroute:
traceroute to test.ngi.it (88.149.202.248), 30 hops max, 60 byte packets
1 gateway 0.545 ms 0.693 ms 0.880 ms
2 * * *
3 151.7.32.116 (151.7.32.116) 10.564 ms 10.567 ms 10.554 ms
4 151.7.32.16 (151.7.32.16) 11.597 ms 151.7.32.70 (151.7.32.70) 11.599 ms 151.7.32.12 (151.7.32.12) 12.410 ms
5 151.6.5.190 (151.6.5.190) 16.993 ms 17.555 ms 151.6.0.91 (151.6.0.91) 17.044 ms
6 151.6.1.180 (151.6.1.180) 18.554 ms 151.6.1.182 (151.6.1.182) 14.502 ms 151.6.1.178 (151.6.1.178) 15.578 ms
7 btglobal.mix-it.net (217.29.66.119) 15.964 ms 15.967 ms 16.750 ms
8 t2c3-xe-0-0-0-1.it-mil2.eu.bt.net (166.49.237.82) 16.936 ms 16.900 ms 17.114 ms
9 166-49-243-130.eu.bt.net (166.49.243.130) 26.734 ms 26.227 ms 26.726 ms
10 217-221-48-218-static.albacom.net (217.221.48.218) 28.989 ms 29.531 ms 28.985 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 *^C
Con NGI ci sono problemi di routing in diverse zone d'Italia, io ormai non lo testo nemmeno più... Per Milano meglio kpnqwest.it o cloudflare.net .
Esecuzione di Ping test.ngi.it [88.149.202.248] con 32 byte di dati:
Risposta da 88.149.202.248: byte=32 durata=22ms TTL=53
Risposta da 88.149.202.248: byte=32 durata=21ms TTL=53
Risposta da 88.149.202.248: byte=32 durata=21ms TTL=53
Risposta da 88.149.202.248: byte=32 durata=21ms TTL=53
Statistiche Ping per 88.149.202.248:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 21ms, Massimo = 22ms, Medio = 21ms
Esecuzione di Ping kpnqwest.it [109.168.113.92] con 32 byte di dati:
Risposta da 109.168.113.92: byte=32 durata=11ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Statistiche Ping per 109.168.113.92:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 10ms, Massimo = 11ms, Medio = 10ms
Esecuzione di Ping cloudflare.net [104.16.198.150] con 32 byte di dati:
Risposta da 104.16.198.150: byte=32 durata=11ms TTL=57
Risposta da 104.16.198.150: byte=32 durata=10ms TTL=57
Risposta da 104.16.198.150: byte=32 durata=10ms TTL=57
Risposta da 104.16.198.150: byte=32 durata=10ms TTL=57
Statistiche Ping per 104.16.198.150:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 10ms, Massimo = 11ms, Medio = 10ms
(ho una FTTC, per non confondere le idee).
La distanza tra Perugia e Milano è più del doppio più grande che da Bologna, è normale che la latenza sia il doppio.
Secondo me si tratta di distanze in assoluto troppo piccole per motivare il raddoppio della latenza.
La tara delle FTTH quant'è?
FTTC TIM 100/20 Bologna:
Rilevazione instradamento verso test.ngi.it [88.149.202.248]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.89.185
4 5 ms 4 ms 4 ms 172.17.88.93
5 * * 5 ms 172.17.5.77
6 10 ms 11 ms 11 ms 172.17.14.161
7 12 ms 12 ms 12 ms 172.19.0.251
8 13 ms 11 ms 11 ms 195.31.82.206
9 14 ms 14 ms 13 ms 217-221-48-218-static.albacom.net [217.221.48.218]
10 * * * Richiesta scaduta.
11 12 ms 12 ms 12 ms 88-149-202-248.v4.ngi.it [88.149.202.248]
Rilevazione completata.
PS:
Per la FTTH Bologna aspetta l'amico MisterFTTH che può dare feedback sia su TIM che su Vodafone (e speriamo a breve Tiscali).
Non c'è visto che è tutto in fibra. Rifallo verso uno degli ip indicati da Psyred.
Fatti un paio in questo momento.
Anche per il Giappone si può essere instradati verso gli USA - Oceano Pacifico (primo traceroute) oppure Canale di Suez - Mar Rosso - Singapore (secondo traceroute).
Traccia instradamento verso 45.63.120.97.vultr.com [45.63.120.97]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 5 ms 151.7.32.104
4 5 ms 5 ms 5 ms 151.7.32.12
5 12 ms 10 ms 11 ms 151.6.5.190
6 11 ms 10 ms 10 ms 151.6.1.176
7 10 ms 10 ms 10 ms et-1-1-0-xcr1.mlu.cw.net [195.2.10.133]
8 98 ms 98 ms 98 ms ae0-xcr1.mlb.cw.net [195.2.25.98]
9 98 ms 100 ms 100 ms ae33-xcr1.ptl.cw.net [195.2.25.254]
10 97 ms 98 ms 98 ms et-7-1-0-xcr1.nyh.cw.net [195.2.24.241]
11 98 ms 103 ms 98 ms ae13-xcr2.nyk.cw.net [195.2.25.69]
12 99 ms 99 ms 99 ms ae-36.r08.nycmny01.us.bb.gin.ntt.net [128.241.2.
153]
13 97 ms 97 ms 99 ms ae-3.r24.nycmny01.us.bb.gin.ntt.net [129.250.5.6
1]
14 225 ms 225 ms 225 ms ae-2.r20.sttlwa01.us.bb.gin.ntt.net [129.250.4.1
3]
15 277 ms 277 ms 277 ms ae-0.r21.sttlwa01.us.bb.gin.ntt.net [129.250.2.5
4]
16 239 ms 234 ms 233 ms ae-3.r23.snjsca04.us.bb.gin.ntt.net [129.250.3.1
24]
17 338 ms * * ae-21.r30.tokyjp05.jp.bb.gin.ntt.net [129.250.5.
77]
18 390 ms 390 ms 390 ms ae-5.r02.tokyjp03.jp.bb.gin.ntt.net [129.250.3.2
51]
19 330 ms * 330 ms ae-0.choopa.tokyjp03.jp.bb.gin.ntt.net [117.103.
177.122]
20 326 ms 326 ms 326 ms vl508-ds1-b5-2407.tyo1.choopa.net [45.32.30.94]
21 * * * Richiesta scaduta.
22 386 ms 386 ms 386 ms 45.63.120.97.vultr.com [45.63.120.97]
Traccia completata.
Traccia instradamento verso 45.121.184.137 su un massimo di 30 punti di passaggi
o
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 151.7.32.104
4 5 ms 4 ms 5 ms 151.7.32.74
5 10 ms 10 ms 10 ms 151.6.2.76
6 10 ms 10 ms 10 ms 151.6.1.237
7 40 ms 29 ms 29 ms 100ge7-2.core1.fra1.he.net [80.81.192.172]
8 41 ms 47 ms 41 ms 100ge5-2.core1.par2.he.net [72.52.92.13]
9 34 ms 34 ms 34 ms flag-as-as15412.10gigabitethernet7-13.core1.par2
.he.net [216.66.89.214]
10 215 ms 215 ms 215 ms 62.216.128.197
11 212 ms 211 ms 211 ms xe-8-1-1.0.pjr03.mmb004.flagtel.com [85.95.25.11
3]
12 217 ms 212 ms 233 ms ge-3-1-0.0.pjr01.mmb004.flagtel.com [85.95.26.22
9]
13 244 ms 223 ms 215 ms so-0-0-0.0.ejr03.sin001.flagtel.com [85.95.25.98
]
14 217 ms 212 ms 212 ms so-7-1-0.0.ejr04.sin001.flagtel.com [62.216.128.
153]
15 222 ms 214 ms 214 ms xe-1-0-2.0.cjr01.sin001.flagtel.com [62.216.137.
149]
16 276 ms 277 ms 279 ms 80.81.65.122
17 279 ms 281 ms 278 ms 192.168.150.22
18 305 ms 310 ms 297 ms 192.168.152.9
19 278 ms 278 ms 278 ms 45.121.184.137
Traccia completata.
Ottimo, grazie.
(ho una FTTC, per non confondere le idee).
Ricordami da dove pls.
Secondo me si tratta di distanze in assoluto troppo piccole per motivare il raddoppio della latenza.
Hai pienamente ragione su questo punto, i ping di 8ms Bologna-Milano son già alti ( NB: per una ftth, i tuoi 8ms in fttc sono ottimali!), 15ms Perugia-Milano indicano un routing ancora peggiore semplicemente perchè se anche volessimo pingare un Perugia-Bologna tutto in fibra ( non è detto che il routing di una linea perugina debba passare per Bologna ma noi consideriamo il caso peggiore) dovrebbe essere inferiore ai 5ms.
Per questo chiedevo i traceroute.
Non hai tutti i torti, infatti i due server da te citati restituiscono valori in linea con google.it piuttosto che con i server speedtest, nel mio piccolo mi ero adeguato alla richiesta :)
Anche io :)
FTTC TIM 100/20 Bologna:
kpnqwest.it
Rilevazione instradamento verso kpnqwest.it [109.168.113.92]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 6 ms 4 ms 4 ms 172.17.88.218
4 5 ms 5 ms 5 ms 172.17.88.173
5 8 ms 8 ms 7 ms 172.19.177.28
6 8 ms 8 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 9 ms 9 ms 9 ms ae21.milano51.mil.seabone.net [195.22.205.39]
8 9 ms 9 ms 8 ms kpnqwest.milano51.mil.seabone.net [93.186.128.151]
9 9 ms 8 ms 8 ms cr1-tenge4-7-cal1.mil.kpnqwest.it [195.43.160.9]
10 9 ms 9 ms 9 ms cr2-tenge4-4-cal2.mil.kpnqwest.it [94.141.0.182]
11 10 ms 9 ms 9 ms cr1-tenge4-8-cal2.mil.kpnqwest.it [94.141.0.185]
12 9 ms 8 ms 8 ms kqi-cal2-fw.comm2000.it [94.141.30.244]
13 14 ms 9 ms 8 ms esrever.kpnqwest.it [109.168.113.92]
Rilevazione completata.
cloudflare.net
Rilevazione instradamento verso cloudflare.net [104.16.198.150]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 6 ms 4 ms 4 ms 172.17.88.220
4 5 ms 5 ms 6 ms 172.17.88.85
5 8 ms 7 ms 8 ms 172.19.177.28
6 9 ms 8 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 21 ms 23 ms 20 ms ae11.milano58.mil.seabone.net [195.22.208.79]
8 8 ms 8 ms 8 ms cloudflare.milano58.mil.seabone.net [195.22.196.97]
9 8 ms 8 ms 9 ms 104.16.198.150
Rilevazione completata.
Hai pienamente ragione su questo punto, i ping di 8ms Bologna-Milano son già alti (NB: per una ftth, i tuoi 8ms in fttc sono ottimali!), 15ms Perugia-Milano indicano un routing ancora peggiore semplicemente perchè un Perugia-Bologna tutto in fibra dovrebbe essere inferiore ai 5ms. Per questo chiedevo i traceroute.
Capisco. Certo che per me, al quale il ping interessa di più che la banda (anche perché ho 75 in down e 20 in up effettivi, quindi non sono proprio a piedi), mi dispiace e non poco peggiorare per passare in FTTH... speriamo bene in Tiscali.
Ricordami da dove pls.
Toscana.
Anche io :)
FTTC TIM 100/20 Bologna:
kpnqwest.it
Rilevazione instradamento verso kpnqwest.it [109.168.113.92]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 6 ms 4 ms 4 ms 172.17.88.218
4 5 ms 5 ms 5 ms 172.17.88.173
5 8 ms 8 ms 7 ms 172.19.177.28
6 8 ms 8 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 9 ms 9 ms 9 ms ae21.milano51.mil.seabone.net [195.22.205.39]
8 9 ms 9 ms 8 ms kpnqwest.milano51.mil.seabone.net [93.186.128.151]
9 9 ms 8 ms 8 ms cr1-tenge4-7-cal1.mil.kpnqwest.it [195.43.160.9]
10 9 ms 9 ms 9 ms cr2-tenge4-4-cal2.mil.kpnqwest.it [94.141.0.182]
11 10 ms 9 ms 9 ms cr1-tenge4-8-cal2.mil.kpnqwest.it [94.141.0.185]
12 9 ms 8 ms 8 ms kqi-cal2-fw.comm2000.it [94.141.30.244]
13 14 ms 9 ms 8 ms esrever.kpnqwest.it [109.168.113.92]
Rilevazione completata.
cloudflare.net
Rilevazione instradamento verso cloudflare.net [104.16.198.150]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 6 ms 4 ms 4 ms 172.17.88.220
4 5 ms 5 ms 6 ms 172.17.88.85
5 8 ms 7 ms 8 ms 172.19.177.28
6 9 ms 8 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 21 ms 23 ms 20 ms ae11.milano58.mil.seabone.net [195.22.208.79]
8 8 ms 8 ms 8 ms cloudflare.milano58.mil.seabone.net [195.22.196.97]
9 8 ms 8 ms 9 ms 104.16.198.150
Rilevazione completata.
Capisco. Certo che per me, al quale il ping interessa di più che la banda (anche perché ho 75 in down e 20 in up effettivi, quindi non sono proprio a piedi), mi dispiace e non poco peggiorare per passare in FTTH... speriamo bene in Tiscali.
Si beh non saranno quei 2ms in più a peggiorare la tua esperienza gioco ( C' ho preso? :D )
Toscana.
Ok grazie,io sono poco sopra Milano e non ho mai avuto problemi di routing verso ngi quindi hai fatto bene a precisarlo.
sergio.pg
31-07-2017, 13:35
Secondo me si tratta di distanze in assoluto troppo piccole per motivare il raddoppio della latenza.
La latenza Infostrada da Perugia è aumentata di circa 5 ms. sul primo hop da quando Infostrada ha aumentato la banda oltre i 500 Mb. a inizio giugno (al momento siamo sui 850 Mb. di throughput o 900 Mb. di banda). Aruba.it ad Arezzo (via Firenze) era fissa a 6 ms. ora a 11 ms. Quindi sì c'è una tara sul primo hop che spero tolgano quando come hanno promesso aumenteranno la banda a 1Gb entro settembre. Oltre quei 5 ms. credo che il resto lo faccia la distanza, se guardi gli altri aumenti di latenze su Francoforte ecc. sono coerenti con le distanze.
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=1 ttl=53 time=14.7 ms
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=2 ttl=53 time=14.8 ms
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=3 ttl=53 time=14.7 ms
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=4 ttl=53 time=14.9 ms
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=5 ttl=53 time=15.0 ms
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=6 ttl=53 time=15.4 ms
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=7 ttl=53 time=14.7 ms
64 bytes from esrever.kpnqwest.it (109.168.113.92): icmp_seq=8 ttl=53 time=14.9 ms
rtt min/avg/max/mdev = 14.734/14.933/15.416/0.259 ms
traceroute to kpnqwest.it (109.168.113.92), 30 hops max, 60 byte packets
1 gateway 0.562 ms 0.749 ms 0.928 ms
2 * * *
3 151.7.32.116 (151.7.32.116) 10.355 ms 10.531 ms 11.199 ms
4 151.7.32.16 (151.7.32.16) 11.192 ms 151.7.32.74 (151.7.32.74) 11.418 ms 151.7.32.90 (151.7.32.90) 11.582 ms
5 151.6.0.91 (151.6.0.91) 17.188 ms 151.6.2.76 (151.6.2.76) 17.373 ms 17.321 ms
6 151.6.1.182 (151.6.1.182) 18.267 ms 14.428 ms 151.6.1.176 (151.6.1.176) 15.438 ms
7 kpnqwest.mix-it.net (217.29.66.10) 14.219 ms 15.378 ms 15.470 ms
8 cr1-tenge4-7-cal1.mil.kpnqwest.it (195.43.160.9) 31.528 ms 31.526 ms 31.578 ms
9 cr2-tenge4-4-cal2.mil.kpnqwest.it (94.141.0.182) 16.791 ms 16.961 ms 37.500 ms
10 cr1-tenge4-8-cal2.mil.kpnqwest.it (94.141.0.185) 16.324 ms 16.912 ms 17.168 ms
11 kqi-cal2-fw.comm2000.it (94.141.30.244) 17.660 ms 18.509 ms 18.046 ms
12 esrever.kpnqwest.it (109.168.113.92) 15.235 ms !X 15.033 ms !X 15.002 ms !X
La latenza Infostrada da Perugia è aumentata di circa 5 ms. sul primo hop da quando Infostrada ha aumentato la banda oltre i 500 Mb. a inizio giugno (al momento siamo sui 850 Mb. di throughput o 900 Mb. di banda). Aruba.it ad Arezzo (via Firenze) era fissa a 6 ms. ora a 11 ms.
Speriamo risolvano a breve perchè non si possono vedere 10 ms al primo hop su una FTTH...
Se un utente interessato di Perugia legge il forum e vede latenze peggiori di una adsl è normale che se ne tenga alla larga.
Si beh non saranno quei 2ms in più a peggiorare la tua esperienza gioco ( C' ho preso? :D )
... e invece SI! Voglio < 5 ms come gli americani!!! :read: :D
La latenza Infostrada da Perugia è aumentata di circa 5 ms. sul primo hop da quando Infostrada ha aumentato la banda oltre i 500 Mb. a inizio giugno (al momento siamo sui 850 Mb. di throughput o 900 Mb. di banda). Aruba.it ad Arezzo (via Firenze) era fissa a 6 ms. ora a 11 ms. Quindi sì c'è una tara sul primo hop che spero tolgano quando come hanno promesso aumenteranno la banda a 1Gb entro settembre. Oltre quei 5 ms. credo che il resto lo faccia la distanza, se guardi gli altri aumenti di latenze su Francoforte ecc. sono coerenti con le distanze.
Capisco.
Speriamo risolvano a breve perchè non si possono vedere 10 ms al primo hop su una FTTH...
Se un utente interessato di Perugia legge il forum e vede latenze peggiori di una adsl è normale che se ne tenga alla larga.
Quoto, anche se per fortuna loro la stragrande maggioranza dell'utenza si abbona senza fare test come i nostri.
La latenza Infostrada da Perugia è aumentata di circa 5 ms. sul primo hop da quando Infostrada ha aumentato la banda oltre i 500 Mb. a inizio giugno (al momento siamo sui 850 Mb. di throughput o 900 Mb. di banda). Aruba.it ad Arezzo (via Firenze) era fissa a 6 ms. ora a 11 ms. Quindi sì c'è una tara sul primo hop che spero tolgano quando come hanno promesso aumenteranno la banda a 1Gb entro settembre. Oltre quei 5 ms. credo che il resto lo faccia la distanza, se guardi gli altri aumenti di latenze su Francoforte ecc. sono coerenti con le distanze.
Ah ecco grazie per la segnalazione.
... e invece SI! Voglio > 5 ms come gli americani!!! :read: :D
:eek:
sergio.pg
31-07-2017, 15:55
Speriamo risolvano a breve perchè non si possono vedere 10 ms al primo hop su una FTTH...
Se un utente interessato di Perugia legge il forum e vede latenze peggiori di una adsl è normale che se ne tenga alla larga.
Lo spero anch'io, anche se bisogna tenere presente che con il primo hop sei a Firenze e a Milano arrivi in 15 ms. Credo/spero che questa sia una "soluzione provvisoria" usata per dare una quasi 1Gb ai clienti prima di settembre. E si, lo so che non c'è niente di più permanente di una soluzione provvisoria :)
Ah ecco grazie per la segnalazione.
Di niente, lo avevo già segnalato qualche giorno fa nel thread Infostrada FTTH, è utile che sia anche qui così la gente sa che è un problema di Infostrada a Perugia.
:eek:
Nella fretta ho scritto "> 5" anziché "< 5" :D
Ecco i miei valori
Tim FTTH 300 mega da pc collegato a router Asus ( AP ) a sua volta collegato al Sercomm . Tutto via cavo . Citta Bari
216.58.205.67 - 15 16 15
172.217.22.35 - 27 28 27
216.58.198.163 - 37 37 37
172.217.12.196 - 113 114 113
216.58.200.4 - 311 311 311
I valori sono rispettivamente minimo , massimo e medio
Traceroute verso Kpnqwest
1 <1 ms <1 ms <1 ms modemtim [192.168.1.1]
2 * * * Richiesta scaduta.
3 3 ms 3 ms 3 ms 172.17.145.197
4 7 ms 6 ms 7 ms 172.17.144.122
5 15 ms 18 ms 18 ms 172.19.245.81
6 15 ms 25 ms 16 ms etrunk12.milano1.mil.seabone.net [93.186.128.205]
7 15 ms 15 ms 15 ms ae21.milano51.mil.seabone.net [195.22.205.39]
8 32 ms 15 ms 15 ms kpnqwest.milano51.mil.seabone.net [93.186.128.151]
9 18 ms 15 ms 15 ms cr1-tenge4-7-cal1.mil.kpnqwest.it [195.43.160.9]
10 16 ms 15 ms 16 ms cr2-tenge4-4-cal2.mil.kpnqwest.it [94.141.0.182]
11 15 ms 15 ms 16 ms cr1-tenge4-8-cal2.mil.kpnqwest.it [94.141.0.185]
12 15 ms 15 ms 15 ms kqi-cal2-fw.comm2000.it [94.141.30.244]
13 16 ms 16 ms 16 ms esrever.kpnqwest.it [109.168.113.92]
Traccia completata
Traceroute verso Cloudflare
raccia instradamento verso 104.16.198.150 su un massimo di 30 punti di passaggio
1 <1 ms <1 ms <1 ms modemtim [192.168.1.1]
2 * * * Richiesta scaduta.
3 3 ms 3 ms 9 ms 172.17.144.152
4 5 ms 6 ms 6 ms 172.17.144.85
5 18 ms 18 ms 19 ms 172.19.245.77
6 * * * Richiesta scaduta.
7 17 ms 17 ms 16 ms ae10.milano58.mil.seabone.net [195.22.208.117]
8 16 ms 16 ms 16 ms cloudflare.milano58.mil.seabone.net [195.22.196.97]
9 17 ms 16 ms 16 ms 104.16.198.150
Traccia completata.
Nella fretta ho scritto "> 5" anziché "< 5" :D
SI si avevo intuito!
Beh visto che pare che anche molti FTTC abbiano postato i valori.
Ecco i miei (diciamo 30-35km da Milano ma fuori provincia):
--- 8.8.8.8 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 4.594/4.907/5.683 ms
--- 216.58.205.67 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 4.726/5.031/5.408 ms
--- 172.217.22.35 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 13.416/13.927/14.537 ms
--- 216.58.198.163 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 24.360/24.956/26.054 ms
--- 172.217.12.196 ping statistics ---
10 packets transmitted, 9 packets received, 10% packet loss
round-trip min/avg/max = 97.157/97.421/98.056 ms
--- 216.58.200.4 ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max = 283.495/283.676/283.841 ms
--- esrever.kpnqwest.it ping statistics ---
12 packets transmitted, 12 packets received, 0% packet loss
round-trip min/avg/max = 5.213/5.556/5.905 ms
--- 104.16.198.150 ping statistics ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 15.438/15.729/16.171 ms
Of course rete TISCALI
Sembra che vadano meglio le FTTC delle FTTH, com'è sta cosa?
EliGabriRock44
02-08-2017, 13:44
Sembra che vadano meglio le FTTC delle FTTH, com'è sta cosa?
Forse perché gli instradamenti per l'FTTH sono ancora in fase di ottimizzazione...
Fastweb ftth 100/50 Milano
Non sono esperto. Se serve qualcosa in più fatemelo sapere (anche come ottenerlo). Questi sono i valori:
C:\>ping 216.58.205.67
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=3ms TTL=52
Risposta da 216.58.205.67: byte=32 durata=3ms TTL=52
Risposta da 216.58.205.67: byte=32 durata=3ms TTL=52
Risposta da 216.58.205.67: byte=32 durata=3ms TTL=52
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 3ms, Massimo = 3ms, Medio = 3ms
C:\>ping 172.217.22.35
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=12ms TTL=50
Risposta da 172.217.22.35: byte=32 durata=12ms TTL=50
Risposta da 172.217.22.35: byte=32 durata=11ms TTL=50
Risposta da 172.217.22.35: byte=32 durata=12ms TTL=50
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 11ms, Massimo = 12ms, Medio = 11ms
C:\>ping 216.58.198.163
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=23ms TTL=47
Risposta da 216.58.198.163: byte=32 durata=23ms TTL=47
Risposta da 216.58.198.163: byte=32 durata=24ms TTL=47
Risposta da 216.58.198.163: byte=32 durata=23ms TTL=47
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 23ms, Massimo = 24ms, Medio = 23ms
C:\>ping 172.217.12.196
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=96ms TTL=48
Risposta da 172.217.12.196: byte=32 durata=95ms TTL=48
Risposta da 172.217.12.196: byte=32 durata=95ms TTL=48
Risposta da 172.217.12.196: byte=32 durata=96ms TTL=48
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 95ms, Massimo = 96ms, Medio = 95ms
C:\>ping 216.58.200.4
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=43
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 282ms, Massimo = 282ms, Medio = 282ms
Un saluto a tutti.
Sembra che vadano meglio le FTTC delle FTTH, com'è sta cosa?
C'è pochissima differenza tra una VDSL g.inp e una FTTH (nelle migliori condizioni 3-4 ms).
Poi è logico che chi abita a Milano o nei pressi è favorito rispetto a un utente del Sud Italia, visto che il traffico passa quasi sempre dal MIX, e molti host italiani si trovano lì.
Se il routing è decente e al netto di modem "buggati" (i famosi + 4 ms dei Broadcom) un utente FTTC di Milano avrà sempre latenze migliori rispetto a uno di Bari in FTTH.
C'è pochissima differenza tra una VDSL g.inp e una FTTH (nelle migliori condizioni 3-4 ms).
Poi è logico che chi abita a Milano o nei pressi è favorito rispetto a un utente del Sud Italia, visto che il traffico passa quasi sempre dal MIX, e molti host italiani si trovano lì.
Se il routing è decente e al netto di modem "buggati" (i famosi + 4 ms dei Broadcom) un utente FTTC di Milano avrà sempre latenze migliori rispetto a uno di Bari in FTTH.
Io e MisterFTTH siamo molto vicini, o meglio, siamo collegati proprio alla stessa centrale, ma i ping delle sue FTTH (ha una TIM 1000/100 ed una Vodafone 1000/200) non sono meglio della mia FTTC TIM 100/20. Ora è in attesa della 1000/300 Tiscali, vedremo un po'.
Riguardo i modem buggati, non c'è modo di usarne altri non forniti? Come ai tempi dell'ADSL che si montava il DGN2200?
Io e MisterFTTH siamo molto vicini, o meglio, siamo collegati proprio alla stessa centrale, ma i ping delle sue FTTH (ha una TIM 1000/100 ed una Vodafone 1000/200) non sono meglio della mia FTTC TIM 100/20. Ora è in attesa della 1000/300 Tiscali, vedremo un po'.
Tu infatti vedo che parti con 4 ms al gateway remoto / primi hop, che è un ottimo ping. In pratica, a parità di routing hai appena 2-3 ms di differenza con una connessione FTTH.
Riguardo i modem buggati, non c'è modo di usarne altri non forniti? Come ai tempi dell'ADSL che si montava il DGN2200?
Se non interessa la fonia c'è l'imbarazzo della scelta, altrimenti dipende dai casi.
Io ho cambiato operatore anche per questo motivo: avevo la VDSL 100/20 Mb TIM e pingavo il BRAS 10 ms con il Technicolor, scesi a 4 ms con il Fritz! 7490 di Infostrada.
Tu infatti vedo che parti con 4 ms al gateway remoto / primi hop, che è un ottimo ping. In pratica, a parità di routing hai appena 2-3 ms di differenza con una connessione FTTH.
Cioè 2-3 ms in meglio intendi?
Se non interessa la fonia c'è l'imbarazzo della scelta, altrimenti dipende dai casi.
Mah, la fonia ce l'ho perché me l'hanno data all'epoca nel pacchetto, ma alla fine io non la uso, e serve solo a ricevere chiamate promozionali, o di gente che cerca il vecchio intestatario di sto numero maledetto (era uno pieno di debiti e quindi i primi mesi chiamavano in media un paio di agenzie recupero crediti al giorno :D, e rido per non piangere! :muro:).
Io ho cambiato operatore anche per questo motivo: avevo la VDSL 100/20 Mb TIM e pingavo il BRAS 10 ms con il Technicolor, scesi a 4 ms con il Fritz! 7490 di Infostrada.
Cioè Psyred fammi capire, io che ho ancora il router originale TIM che mi diedero ai tempi della 30/3 (mai cambiato, manco quando passai alla 50/10 né tanto meno alla 100/20), con un altro router potrei migliorare ancora questo ping...? Se si, scrivimi quale devo prendere, che tra 8 ore e 2 minuti me lo procurerò :D
Cioè 2-3 ms in meglio intendi?
1-2 ms di una FTTH contro i 4-5-6 ms di una FTTC.
Cioè Psyred fammi capire, io che ho ancora il router originale TIM che mi diedero ai tempi della 30/3 (mai cambiato, manco quando passai alla 50/10 né tanto meno alla 100/20), con un altro router potrei migliorare ancora questo ping...? Se si, scrivimi quale devo prendere, che tra 8 ore e 2 minuti me lo procurerò :D
Non credo tu la possa migliorare di molto, forse 1 ms... Se hai un ping del genere con il Technicolor sei molto fortunato :read:, probabilmente hai una portante ancora al di sotto della soglia che fa scattare i famigerati +4 ms.
1-2 ms di una FTTH contro i 4-5-6 ms di una FTTC.
Quindi il fatto che il mio valore sia così meglio è un motivo in più per sostenere che ste FTTH non vanno ancora come dovrebbero?
Non credo tu la possa migliorare di molto, forse 1 ms...
Se si tratta solo di ambiare il router ci sto :cool:
Se hai un ping del genere con il Technicolor sei molto fortunato :read:, probabilmente hai una portante ancora al di sotto della soglia che fa scattare i famigerati +4 ms.
Qual'è la soglia?
Quindi il fatto che il mio valore sia così meglio è un motivo in più per sostenere che ste FTTH non vanno ancora come dovrebbero?
Sono andato a riguardarmi le latenze su kpnqwest e cloudflare (adesso non ho voglia di confrontarli tutti) dell'altro utente bolognese, i vostri ping sono praticamente identici.
Differenze così contenute posso essere ampiamente compensate dal routing; quello di TIM oltretutto tende ad essere molto variabile in base all'IP assegnato, per cui è possibile che tu in quel momento avessi un routing migliore del suo.
Qual'è la soglia?
Diciamo sopra i 100 Mb. Alcuni hanno riscontrato il fenomeno a partire dai 94-95 Mb di portante, per cui è probabile che dipenda anche dalla linea.
Qundi sia l'ip assegnato che la portante giocano un ruolo non indifferente, pk grazie. Per l'ip, è perché il segnale fa un giro diverso? Invece per la portante non ne ho idea, ma comunque è solo un problema di FTTC >95 Mb/Sec, non anche di FTTH?
L'IP è importante per entrambe le tecnologie di accesso in quanto a IP diversi possono corrispondere differenti instradamenti dei pacchetti.
Il discorso del "bug" dei 4 ms invece riguarda solo le utenze in VDSL con modem Broadcom (il BCM63138 del nuovo modem compatibile con il 35b pare che non ne sia afflitto). Oltretutto in FTTH non c'è una vera e propria "portante".
L'IP è importante per entrambe le tecnologie di accesso in quanto a IP diversi possono corrispondere differenti instradamenti dei pacchetti.
Questo è molto interessante, forse dovremmo cominciare ad indicare come inizia l'ip di quando facciamo la rilevazione, in modo da avere una statistica riguardo a quali sia meglio.
Il discorso del "bug" dei 4 ms invece riguarda solo le utenze in VDSL con modem Broadcom (il BCM63138 del nuovo modem compatibile con il 35b pare che non ne sia afflitto). Oltretutto in FTTH non c'è una vera e propria "portante".
Se il mio router dovesse tirare le cuoia, mi manderebbero il Broadcom?
Questo è molto interessante, forse dovremmo cominciare ad indicare come inizia l'ip di quando facciamo la rilevazione, in modo da avere una statistica riguardo a quali sia meglio.
Ho già fatto molti test con tutte le classi di IP Telecom. Non ce ne sono di migliori o peggiori, è tutto molto imprevedibile.
Se il mio router dovesse tirare le cuoia, mi manderebbero il Broadcom?
Sono tutti Broadcom i modem che fornisce TIM.
Ho già fatto molti test con tutte le classi di IP Telecom. Non ce ne sono di migliori o peggiori, è tutto molto imprevedibile.
Quindi va a fortuna diciamo.
Sono tutti Broadcom i modem che fornisce TIM.
Ok grazie :)
furiaceka87
06-08-2017, 22:25
Vodafone - FFTH 1Gbits - Torino
216.58.205.67 = 6ms
172.217.22.35 = 15ms
216.58.198.163 = 27ms
172.217.12.196 = 96ms
216.58.200.4 = 294ms
Vodafone - FFTH 1Gbits - Torino
216.58.205.67 = 6ms
172.217.22.35 = 15ms
216.58.198.163 = 27ms
172.217.12.196 = 96ms
216.58.200.4 = 294ms
Non male.
[QUOTE=Aereo;44931657]Quindi va a fortuna diciamo.
"Fortuna" e' un po riduttivo....
In TIM (ma anche gli altri operatori) in genere assegnano le classi di IP staticamente ad ogni router che gestisce l'accesso di clienti in rete (PE\NAS\POP).
Da questi router ovviamente il routing (scusa il gioco di parole) e' dinamico; l'instradamento anche verso la stessa destinazione e' variabile in base a tutta una serie di parametri (carico di traffico sulla rotta, garanzia, tasso d'errore, affidablilta' della rotta ecc) automaticamente calcolati dai protocolli di routing che girano sulla macchina stessa (RIP,EIGRP,BGP,OSPF ecc).
Quindi va a fortuna diciamo.
"Fortuna" e' un po riduttivo....
In TIM (ma anche gli altri operatori) in genere assegnano le classi di IP staticamente ad ogni router che gestisce l'accesso di clienti in rete (PE\NAS\POP).
Da questi router ovviamente il routing (scusa il gioco di parole) e' dinamico; l'instradamento anche verso la stessa destinazione e' variabile in base a tutta una serie di parametri (carico di traffico sulla rotta, garanzia, tasso d'errore, affidablilta' della rotta ecc) automaticamente calcolati dai protocolli di routing che girano sulla macchina stessa (RIP,EIGRP,BGP,OSPF ecc).
"Fortuna" e' un po riduttivo....
In TIM (ma anche gli altri operatori) in genere assegnano le classi di IP staticamente ad ogni router che gestisce l'accesso di clienti in rete (PE\NAS\POP).
Da questi router ovviamente il routing (scusa il gioco di parole) e' dinamico; l'instradamento anche verso la stessa destinazione e' variabile in base a tutta una serie di parametri (carico di traffico sulla rotta, garanzia, tasso d'errore, affidablilta' della rotta ecc) automaticamente calcolati dai protocolli di routing che girano sulla macchina stessa (RIP,EIGRP,BGP,OSPF ecc).
Ok grazie :)
gerry722
09-08-2017, 18:49
Fastweb Torino 1 Gbits FTTH
216.58.205.67 = 6ms
172.217.22.35 = 14ms
216.58.198.163 = 27ms
172.217.12.196 = 99ms
216.58.200.4 = 288ms
Buono! È stabile anche nelle ore di punta?
gerry722
10-08-2017, 16:58
Per ora si. Ho provato mattina pomeriggio e sera e i valori sono sempre uguali
gerry722
11-08-2017, 20:21
;) Grazie Gerry! :)
FTTC Tim 100/20, Sirmione (BS)
PING 216.58.205.67 (216.58.205.67): 56 data bytes
64 bytes from 216.58.205.67: icmp_seq=0 ttl=53 time=9.059 ms
64 bytes from 216.58.205.67: icmp_seq=1 ttl=53 time=9.164 ms
64 bytes from 216.58.205.67: icmp_seq=2 ttl=53 time=9.263 ms
64 bytes from 216.58.205.67: icmp_seq=3 ttl=53 time=9.051 ms
64 bytes from 216.58.205.67: icmp_seq=4 ttl=53 time=9.376 ms
64 bytes from 216.58.205.67: icmp_seq=5 ttl=53 time=9.561 ms
64 bytes from 216.58.205.67: icmp_seq=6 ttl=53 time=8.678 ms
64 bytes from 216.58.205.67: icmp_seq=7 ttl=53 time=9.230 ms
64 bytes from 216.58.205.67: icmp_seq=8 ttl=53 time=9.226 ms
64 bytes from 216.58.205.67: icmp_seq=9 ttl=53 time=9.292 ms
--- 216.58.205.67 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.678/9.190/9.561/0.221 ms
PING 172.217.22.35 (172.217.22.35): 56 data bytes
64 bytes from 172.217.22.35: icmp_seq=0 ttl=53 time=28.859 ms
64 bytes from 172.217.22.35: icmp_seq=1 ttl=53 time=29.111 ms
64 bytes from 172.217.22.35: icmp_seq=2 ttl=53 time=28.967 ms
64 bytes from 172.217.22.35: icmp_seq=3 ttl=53 time=28.966 ms
64 bytes from 172.217.22.35: icmp_seq=4 ttl=53 time=28.779 ms
64 bytes from 172.217.22.35: icmp_seq=5 ttl=53 time=28.520 ms
64 bytes from 172.217.22.35: icmp_seq=6 ttl=53 time=29.287 ms
64 bytes from 172.217.22.35: icmp_seq=7 ttl=53 time=28.833 ms
64 bytes from 172.217.22.35: icmp_seq=8 ttl=53 time=28.869 ms
64 bytes from 172.217.22.35: icmp_seq=9 ttl=53 time=29.377 ms
--- 172.217.22.35 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.520/28.957/29.377/0.238 ms
PING 216.58.198.163 (216.58.198.163): 56 data bytes
64 bytes from 216.58.198.163: icmp_seq=0 ttl=49 time=29.515 ms
64 bytes from 216.58.198.163: icmp_seq=1 ttl=49 time=28.936 ms
64 bytes from 216.58.198.163: icmp_seq=2 ttl=49 time=28.860 ms
64 bytes from 216.58.198.163: icmp_seq=3 ttl=49 time=28.935 ms
64 bytes from 216.58.198.163: icmp_seq=4 ttl=49 time=29.118 ms
64 bytes from 216.58.198.163: icmp_seq=5 ttl=49 time=29.171 ms
64 bytes from 216.58.198.163: icmp_seq=6 ttl=49 time=28.733 ms
64 bytes from 216.58.198.163: icmp_seq=7 ttl=49 time=28.965 ms
64 bytes from 216.58.198.163: icmp_seq=8 ttl=49 time=28.747 ms
64 bytes from 216.58.198.163: icmp_seq=9 ttl=49 time=29.261 ms
--- 216.58.198.163 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.733/29.024/29.515/0.231 ms
PING 172.217.12.196 (172.217.12.196): 56 data bytes
64 bytes from 172.217.12.196: icmp_seq=0 ttl=50 time=106.118 ms
64 bytes from 172.217.12.196: icmp_seq=1 ttl=50 time=106.313 ms
64 bytes from 172.217.12.196: icmp_seq=2 ttl=50 time=106.150 ms
64 bytes from 172.217.12.196: icmp_seq=3 ttl=50 time=105.981 ms
64 bytes from 172.217.12.196: icmp_seq=4 ttl=50 time=106.175 ms
64 bytes from 172.217.12.196: icmp_seq=5 ttl=50 time=105.713 ms
64 bytes from 172.217.12.196: icmp_seq=6 ttl=50 time=106.465 ms
64 bytes from 172.217.12.196: icmp_seq=7 ttl=50 time=106.169 ms
64 bytes from 172.217.12.196: icmp_seq=8 ttl=50 time=106.082 ms
64 bytes from 172.217.12.196: icmp_seq=9 ttl=50 time=106.036 ms
--- 172.217.12.196 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 105.713/106.120/106.465/0.189 ms
PING 216.58.200.4 (216.58.200.4): 56 data bytes
64 bytes from 216.58.200.4: icmp_seq=0 ttl=49 time=307.341 ms
64 bytes from 216.58.200.4: icmp_seq=1 ttl=49 time=307.576 ms
64 bytes from 216.58.200.4: icmp_seq=2 ttl=49 time=307.211 ms
64 bytes from 216.58.200.4: icmp_seq=3 ttl=49 time=306.998 ms
64 bytes from 216.58.200.4: icmp_seq=4 ttl=49 time=307.206 ms
64 bytes from 216.58.200.4: icmp_seq=5 ttl=49 time=307.482 ms
64 bytes from 216.58.200.4: icmp_seq=6 ttl=49 time=307.179 ms
64 bytes from 216.58.200.4: icmp_seq=7 ttl=49 time=307.135 ms
64 bytes from 216.58.200.4: icmp_seq=8 ttl=49 time=307.248 ms
64 bytes from 216.58.200.4: icmp_seq=9 ttl=49 time=307.403 ms
--- 216.58.200.4 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 306.998/307.278/307.576/0.164 ms
riccardi.fede
13-08-2017, 10:51
FTTC Tim 100/20, Sirmione (BS)
Solo FTTH (fibra fino a casa), non FTTC.
HyundaiBenz
18-08-2017, 09:56
FTTH Bari Infostrada 1 giga
216.58.205.67 (Milano)
Minimum = 21ms, Maximum = 21ms, Average = 21ms
172.217.22.35 (Francoforte)
Minimum = 30ms, Maximum = 33ms, Average = 31ms
216.58.198.163 (Londra)
Minimum = 42ms, Maximum = 43ms, Average = 42ms
172.217.12.196 (Chicago)
Minimum = 116ms, Maximum = 117ms, Average = 116ms
216.58.200.4
Minimum = 299ms, Maximum = 301ms, Average = 300ms
Wind FTTH - Perugia
Comunque sono dati da prendere con le pinze. Parlando con diversi tecnici/responsabili in questi mesi (e soprattutto nelle ultime settimane), mi dicevano che la rete qui è ancora in fase di "test"/ottimizzazione e che quindi le prestazioni dovrebbero migliorare nelle prossime settimane.
Comunque credo che i lavori di scavi veri e propri qui siano conclusi.
Da gennaio Sirti aveva la base in un Hotel nella zona, con furgoni e camion parcheggiati di fronte. Nei giorni scorsi e tutt'ora, passando lì non ce ne è più uno.
Ora girano altre società per passare i cavi di fibra, fare attivazioni e cose collaterali.
Bando alle ciance, ecco i miei dati:
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=14ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=14ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=14ms TTL=54
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 14ms, Massimo = 15ms, Medio = 14ms
________________________
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 23ms, Massimo = 23ms, Medio = 23ms
________________________
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=50
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 34ms, Massimo = 35ms, Medio = 34ms
________________________
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=118ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=118ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=118ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=118ms TTL=49
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 118ms, Massimo = 118ms, Medio = 118ms
________________________
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=306ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=305ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=305ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=305ms TTL=44
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 305ms, Massimo = 306ms, Medio = 305ms
Aggiungo, se servisse, anche il ping sui DNS di google:
Esecuzione di Ping 8.8.8.8 con 32 byte di dati:
Risposta da 8.8.8.8: byte=32 durata=15ms TTL=57
Risposta da 8.8.8.8: byte=32 durata=15ms TTL=57
Risposta da 8.8.8.8: byte=32 durata=15ms TTL=57
Risposta da 8.8.8.8: byte=32 durata=15ms TTL=57
Statistiche Ping per 8.8.8.8:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 15ms, Massimo = 15ms, Medio = 15ms
________________________
Esecuzione di Ping 8.8.4.4 con 32 byte di dati:
Risposta da 8.8.4.4: byte=32 durata=24ms TTL=56
Risposta da 8.8.4.4: byte=32 durata=24ms TTL=56
Risposta da 8.8.4.4: byte=32 durata=24ms TTL=56
Risposta da 8.8.4.4: byte=32 durata=24ms TTL=56
Statistiche Ping per 8.8.4.4:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 24ms, Massimo = 24ms, Medio = 24ms
Visto che anche altri lo hanno messo, penso che sia utile capire dove le reti si "perdano":
Traccia instradamento verso test.ngi.it [88.149.202.248]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 9 ms 9 ms 9 ms 151.7.198.15
3 9 ms 9 ms 9 ms 151.7.32.24
4 9 ms 9 ms 9 ms 151.7.32.18
5 17 ms 14 ms 14 ms 151.6.0.91
6 14 ms 14 ms 14 ms 151.6.1.180
7 14 ms 14 ms 31 ms btglobal.mix-it.net [217.29.66.119]
8 16 ms 16 ms 16 ms t2c3-xe-0-0-0-1.it-mil2.eu.bt.net [166.49.237.82]
9 26 ms 25 ms 26 ms 166-49-243-130.eu.bt.net [166.49.243.130]
10 25 ms 25 ms 25 ms 217-221-48-218-static.albacom.net [217.221.48.218]
11 * * * Richiesta scaduta.
12 23 ms 23 ms 23 ms 88-149-202-248.v4.ngi.it [88.149.202.248]
Traccia completata.
Ciao!
A Perugia Infostrada ha da qualche tempo problemi di routing verso il BRAS, lo si evince chiaramente dai 9 ms, latenza veramente mediocre per una FTTH.
Da PG a MI con una FTTH 14 ms... comunque cosa debbano ottimizzare vorrei capire, perché sta storia che le linee si dovrebbero "assestare" la raccontano sempre tutti, ma poi non si assesta mai niente.
A me hanno detto ottimizzare, non assestare. :)
Ottimizzare una rete nuova, mai accesa prima valutando e sistemando eventuali nodi lenti o centrali non preformanti.
Io personalmente ho notato la prima settimana molto ballerina nelle prestazioni periodi (ore) a 30Mbps, altri a 650/750Mbps.
Il primo giorno non superavo i 350Mbps, già il secondo stavo a 400/500Mbps e da qualche giorno dopo 650/750Mbps. Una settimana dopo ho toccato i 920Mbps e da allora, in base alle fasce orarie e ai giorni, sto tra gli 870Mbps e i 934Mbps (picco massimo nella sera del 16 Agosto).
Poi se sono venuti fuori problemi sul BBRAS di Wind, dove c'è un peggioramento di 5/6ms sul ping... la rete è ufficiosamente ancora in fase di sviluppo (e ottimizzazione) ;)
Non lo so, ma quello che so è che vedo la stragrande maggioranza delle FTTH testate avere ping peggiore della mia FTTC, e questo secondo me è assurdo.
Non lo so, ma quello che so è che vedo la stragrande maggioranza delle FTTH testate avere ping peggiore della mia FTTC, e questo secondo me è assurdo.
Questo senza dubbio... una FTTH con questi ping è una bestemmia alla tecnologia stessa...
È tra i motivi principali per i quali non mi danno per non aver ancora disponibile la commerciabilità (sia su rete TIM che OF) nonostante sia stato cablato da mesi. Finché non vedo ping migliori del mio sto con la mia FTTC 100/20 TIM con 8 ms su Milano. Oltre a questo, tutte le peripezie di attesa di attivazione infinita (vedi Tiscali) o di frequenti segnalazioni di problemi (vedi Vodafone) non mi lasciano ben sperare assolutamente (Fasweb invece è un punto interrogativo con la Gb, mentre Infostrada non l'ho ancora inquadrata). Secondo me sarebbe utile, riguardo al ping, che l'autore del topic ordinasse i risultati per provider/profilo nel primo post, in modo che le statistiche siano fruibili nell'immediato accedendo alla prima pagina del topic, altrimenti nel tempo diventerà sempre più difficile confrontare i dati tra le tante pagine prodotte.
riccardi.fede
23-08-2017, 10:15
Ho aggiornato il primo post e ho aggiunto i risultati, seppur parziali visto che ne mancano ancora...
Ecco i grafici: che ve ne pare?
- Bari (https://drive.google.com/open?id=0B7DKWVT2g56kNUxTQ3dyT1J1TGs)
- Bologna (https://drive.google.com/open?id=0B7DKWVT2g56kWDVhZ0Y5R3NDMEU)
- Cagliari - No dati
- Catania - No dati
- Milano (https://drive.google.com/open?id=0B7DKWVT2g56kelNXT0dFZ2RtRHc)
- Napoli (https://drive.google.com/open?id=0B7DKWVT2g56kOFJuX091ck1VYk0)
- Padova - No dati
- Palermo (https://drive.google.com/open?id=0B7DKWVT2g56kUGkzM0JYbWt4a2c)
- Perugia (https://drive.google.com/open?id=0B7DKWVT2g56kV2RkaUdkQWY5ZDg)
- Torino (https://drive.google.com/open?id=0B7DKWVT2g56kbWJxRzhYVVc1SmM)
- Venezia - No dati
Ho aggiornato il primo post e ho aggiunto i risultati, seppur parziali visto che ne mancano ancora...
Ecco i grafici: che ve ne pare?
- Bari (https://drive.google.com/open?id=0B7DKWVT2g56kNUxTQ3dyT1J1TGs)
- Bologna (https://drive.google.com/open?id=0B7DKWVT2g56kWDVhZ0Y5R3NDMEU)
- Cagliari - No dati
- Catania - No dati
- Milano (https://drive.google.com/open?id=0B7DKWVT2g56kelNXT0dFZ2RtRHc)
- Napoli (https://drive.google.com/open?id=0B7DKWVT2g56kOFJuX091ck1VYk0)
- Padova - No dati
- Palermo (https://drive.google.com/open?id=0B7DKWVT2g56kUGkzM0JYbWt4a2c)
- Perugia (https://drive.google.com/open?id=0B7DKWVT2g56kWkVHMUpiMy1aNXc)
- Torino (https://drive.google.com/open?id=0B7DKWVT2g56kbWJxRzhYVVc1SmM)
- Venezia - No dati
Bravo Fede! :)
Eccomi, posto i miei dati, anche se con un po' di ritardo.
Wind - Perugia
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=14ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=14ms TTL=54
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 5, Ricevuti = 5,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 14ms, Massimo = 15ms, Medio = 14ms
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=23ms TTL=52
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 5, Ricevuti = 5,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 23ms, Massimo = 23ms, Medio = 23ms
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=37ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=37ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=37ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=37ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=37ms TTL=50
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 5, Ricevuti = 5,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 37ms, Massimo = 37ms, Medio = 37ms
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=49
Risposta da 172.217.12.196: byte=32 durata=118ms TTL=49
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 5, Ricevuti = 5,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 115ms, Massimo = 118ms, Medio = 115ms
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=295ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=295ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=295ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=295ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=295ms TTL=45
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 5, Ricevuti = 5,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 295ms, Massimo = 295ms, Medio = 295ms
15 ms su Milano... vedo che anche Infostrada luccica... che tristezza! :muro:
EliGabriRock44
23-08-2017, 21:27
15 ms su Milano... vedo che anche Infostrada luccica... che tristezza! :muro:
Beh, a me non sembra tutto sto scandalo, contando che:
- io pingo da carpi-milano 17ms in fttc(si lo so, tecnologia diversa, instradamento diverso);
- in ftth la gente fa bologna-milano con 8-10ms e guardando su maps la distanza é simile milano-bologna e bologna-perugia, quindi penso che ci possano anche stare 16ms circa.
Ovviamente come ha detto Psyred ci sono problemi quindi basta aspettare e migliorerà nel tempo, nulla di più facile...io in 2 anni sono passato da 21/22ms a 17 di colpo, un giorno qualsiasi...
Beh, a me non sembra tutto sto scandalo, contando che:
- io pingo da carpi-milano 17ms in fttc(si lo so, tecnologia diversa, instradamento diverso);
- in ftth la gente fa bologna-milano con 8-10ms e guardando su maps la distanza é simile milano-bologna e bologna-perugia, quindi penso che ci possano anche stare 16ms circa.
Ovviamente come ha detto Psyred ci sono problemi quindi basta aspettare e migliorerà nel tempo, nulla di più facile...io in 2 anni sono passato da 21/22ms a 17 di colpo, un giorno qualsiasi...
8 ms BO-MI con FTTC 100/20 sono io, ed FTTH con 15 ms è si uno scandalo, altroché, non ci sono scuse. Che sistemassero e portassero tutto < 5 ms, come una FTTH seria deve andare.
PS:
Io in ULL con Infostrada avevo 12 ms con ADSL...
riccardi.fede
23-08-2017, 22:06
Più che altro notate per esempio il confronto Perugia - Bologna. Confrontate Wind|3 visto che abbiamo i dati.
Perugia-Milano: 14,417ms
Bologna-Milano: 16ms
Anche il ping verso Francoforte è simile.
Invece da Londra, il ping da Perugia si innalza.
Il ping da Perugia dovrebbe essere più alto e invece per i primi due server è praticamente uguale.
Ovviamente dobbiamo avere più dati per un confronto più "idoneo" e di tutti gli operatori.
Sono alti Fede c'è poco da fare, se non augurarsi che sistemino i problemi i quali causerebbero questo.
Comunque con l'host "milanese" di google il routing non è ottimale
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=19ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=19ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=18ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=19ms TTL=53
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 18ms, Massimo = 19ms, Medio = 18ms
Io Milano con Infostrada generalmente lo pingo sui 10 ms (in FTTC dalla Toscana)
Esecuzione di Ping kpnqwest.it [109.168.113.92] con 32 byte di dati:
Risposta da 109.168.113.92: byte=32 durata=11ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Statistiche Ping per 109.168.113.92:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 10ms, Massimo = 11ms, Medio = 10ms
Esecuzione di Ping wind.mix-it.net [217.29.66.9] con 32 byte di dati:
Risposta da 217.29.66.9: byte=32 durata=10ms TTL=59
Risposta da 217.29.66.9: byte=32 durata=9ms TTL=59
Risposta da 217.29.66.9: byte=32 durata=10ms TTL=59
Risposta da 217.29.66.9: byte=32 durata=10ms TTL=59
Statistiche Ping per 217.29.66.9:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 10ms, Medio = 9ms
Esecuzione di Ping cloudflare.net [104.16.196.150] con 32 byte di dati:
Risposta da 104.16.196.150: byte=32 durata=10ms TTL=57
Risposta da 104.16.196.150: byte=32 durata=10ms TTL=57
Risposta da 104.16.196.150: byte=32 durata=9ms TTL=57
Risposta da 104.16.196.150: byte=32 durata=10ms TTL=57
Statistiche Ping per 104.16.196.150:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 10ms, Medio = 9ms
Esecuzione di Ping gamesnet.it [195.36.6.10] con 32 byte di dati:
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=9ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Statistiche Ping per 195.36.6.10:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 10ms, Medio = 9ms
EliGabriRock44
24-08-2017, 08:24
Comunque con l'host "milanese" di google il routing non è ottimale
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=19ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=19ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=18ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=19ms TTL=53
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 18ms, Massimo = 19ms, Medio = 18ms
Io Milano con Infostrada generalmente lo pingo sui 10 ms (in FTTC dalla Toscana)
Esecuzione di Ping kpnqwest.it [109.168.113.92] con 32 byte di dati:
Risposta da 109.168.113.92: byte=32 durata=11ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Risposta da 109.168.113.92: byte=32 durata=10ms TTL=53
Statistiche Ping per 109.168.113.92:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 10ms, Massimo = 11ms, Medio = 10ms
Esecuzione di Ping wind.mix-it.net [217.29.66.9] con 32 byte di dati:
Risposta da 217.29.66.9: byte=32 durata=10ms TTL=59
Risposta da 217.29.66.9: byte=32 durata=9ms TTL=59
Risposta da 217.29.66.9: byte=32 durata=10ms TTL=59
Risposta da 217.29.66.9: byte=32 durata=10ms TTL=59
Statistiche Ping per 217.29.66.9:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 10ms, Medio = 9ms
Esecuzione di Ping cloudflare.net [104.16.196.150] con 32 byte di dati:
Risposta da 104.16.196.150: byte=32 durata=10ms TTL=57
Risposta da 104.16.196.150: byte=32 durata=10ms TTL=57
Risposta da 104.16.196.150: byte=32 durata=9ms TTL=57
Risposta da 104.16.196.150: byte=32 durata=10ms TTL=57
Statistiche Ping per 104.16.196.150:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 10ms, Medio = 9ms
Esecuzione di Ping gamesnet.it [195.36.6.10] con 32 byte di dati:
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=9ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Statistiche Ping per 195.36.6.10:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 10ms, Medio = 9ms
Eh però dopo il problema che salta fuori é: su cosa testi il ping? Su che server? Hai IP di server Wind? Ci sono server Wind all'estero?
Ma quelli non sono mica server di Wind (eccetto il secondo, che è un router di Wind al MIX).
Appunto sarebbe meglio scegliere due o più host, perchè se tu hai un routing non ottimale verso un certo host non è assolutamente detto che la cosa si ripeta anche su altri della stessa zona.
Ho cambiato IP, adesso ping 10 ms anche quello
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=10ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=10ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=10ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=10ms TTL=54
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 10ms, Massimo = 10ms, Medio = 10ms
EliGabriRock44
24-08-2017, 08:43
Ma quelli non sono mica server di Wind (eccetto il secondo, che è un router di Wind al MIX).
Appunto sarebbe meglio scegliere due o più host, perchè se tu hai un routing non ottimale verso un certo host non è assolutamente detto che la cosa si ripeta anche su altri della stessa zona.
Ma infatti é stato scelto un host generico e che penso non favorisca gli operatori...se poi gli stessi operatori hanno problemi é un altro discorso.
Ma infatti é stato scelto un host generico e che penso non favorisca gli operatori...se poi gli stessi operatori hanno problemi é un altro discorso.
Si comunque degli host google mi fiderei fino a un certo punto perchè il routing tende a variare (vedi sopra).
Ma quelli non sono mica server di Wind (eccetto il secondo, che è un router di Wind al MIX).
Appunto sarebbe meglio scegliere due o più host, perchè se tu hai un routing non ottimale verso un certo host non è assolutamente detto che la cosa si ripeta anche su altri della stessa zona.
Si comunque degli host google mi fiderei fino a un certo punto perchè il routing tende a variare (vedi sopra).
Quali server è meglio pingare esattamente? Facciamo pingare anche quelli così siamo sicuri.
EliGabriRock44
24-08-2017, 09:01
Quali server è meglio pingare esattamente? Facciamo pingare anche quelli così siamo sicuri.
La fai facile visto che non devi fare nulla :D
Quali server è meglio pingare esattamente? Facciamo pingare anche quelli così siamo sicuri.
Per esempio kpnqwest.it e cloudflare.net dovrebbero essere "stabili" con la maggior parte degli operatori.
P.S.
Tu che hai la FTTC TIM a Bologna posteresti un tracert verso telnet.it e gamesnet.it ? Sono curioso di vedere l'instradamento nella vostra zona. Grazie.
EliGabriRock44
24-08-2017, 09:09
Per esempio kpnqwest.it e cloudflare.net dovrebbero essere "stabili" con la maggior parte degli operatori.
P.S.
Tu che hai la FTTC TIM a Bologna posteresti un tracert verso telnet.it e gamesnet.it ? Sono curioso di vedere l'instradamento nella vostra zona. Grazie.
Bah insomma, 1 test per host e ho avuto solo valori di m****.
Faccio su google sono stabili, bassi e fissi, come i prezzi del conad.
Bah insomma, 1 test per host e ho avuto solo valori di m****.
Faccio su google sono stabili, bassi e fissi, come i prezzi del conad.
Non esiste mica solo google sul web :read: Evidentemente il tuo operatore non è il massimo in quanto a routing.
La fai facile visto che non devi fare nulla :D
Mi impegno a farlo su FTTC, la fatica è la medesima :D
Per esempio kpnqwest.it e cloudflare.net dovrebbero essere "stabili" con la maggior parte degli operatori.
OK grazie :)
DATI FTTC TIM 100/20
Ping su kpnqwest.it
Esecuzione di Ping kpnqwest.it [109.168.113.92] con 32 byte di dati:
Risposta da 109.168.113.92: byte=32 durata=13ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=12ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=13ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=12ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=13ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=13ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=13ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=15ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=12ms TTL=52
Risposta da 109.168.113.92: byte=32 durata=12ms TTL=52
Statistiche Ping per 109.168.113.92:
Pacchetti: Trasmessi = 10, Ricevuti = 10, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 12ms, Massimo = 15ms, Medio = 12ms
Ping su cloudflare.net
Esecuzione di Ping cloudflare.net [104.16.194.150] con 32 byte di dati:
Risposta da 104.16.194.150: byte=32 durata=12ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=9ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Risposta da 104.16.194.150: byte=32 durata=10ms TTL=56
Statistiche Ping per 104.16.194.150:
Pacchetti: Trasmessi = 10, Ricevuti = 10, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 12ms, Medio = 10ms
P.S.
Tu che hai la FTTC TIM a Bologna posteresti un tracert verso telnet.it e gamesnet.it ? Sono curioso di vedere l'instradamento nella vostra zona. Grazie.
Certo figurati :)
Tracert su telnet.it
Rilevazione instradamento verso telnet.it [195.36.1.104] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.89.57
4 5 ms 4 ms 4 ms 172.17.88.153
5 11 ms 11 ms 11 ms 172.19.177.18
6 * 17 ms 16 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 28 ms 28 ms 28 ms et7-3-0.franco31.fra.seabone.net [195.22.214.196]
8 31 ms 30 ms 31 ms teleglobe.franco31.fra.seabone.net [195.22.214.55]
9 53 ms 53 ms 52 ms if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net [195.219.87.17]
10 52 ms 52 ms 52 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net [195.219.87.14]
11 53 ms 53 ms 53 ms if-et-39-2.hcore3.MLT-Milan.as6453.net [195.219.241.30]
12 52 ms 52 ms 52 ms 195.219.158.62
13 52 ms 52 ms 52 ms itaca.telnetwork.it [195.36.1.104]
Tracert su gamesnet.it
Rilevazione instradamento verso gamesnet.it [195.36.6.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 6 ms 172.17.89.61
4 * * * Richiesta scaduta.
5 8 ms 7 ms 7 ms 172.19.177.28
6 * 9 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 17 ms 16 ms 16 ms et5-3-0.franco31.fra.seabone.net [195.22.214.92]
8 21 ms 20 ms 19 ms teleglobe.franco31.fra.seabone.net [195.22.214.55]
9 43 ms 40 ms 41 ms if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net [195.219.87.17]
10 41 ms 41 ms 40 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net [195.219.87.10]
11 41 ms 40 ms 41 ms if-et-39-2.hcore3.MLT-Milan.as6453.net [195.219.241.30]
12 40 ms 40 ms 40 ms 195.219.158.62
13 41 ms 40 ms 41 ms www.gamesnet.it [195.36.6.10]
Bah insomma, 1 test per host e ho avuto solo valori di m****.
Faccio su google sono stabili, bassi e fissi, come i prezzi del conad.
Non condivido il paragone (il quale equivale a quello con la COOP!) :D
Certo figurati :)
Tracert su telnet.it
Rilevazione instradamento verso telnet.it [195.36.1.104] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.89.57
4 5 ms 4 ms 4 ms 172.17.88.153
5 11 ms 11 ms 11 ms 172.19.177.18
6 * 17 ms 16 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 28 ms 28 ms 28 ms et7-3-0.franco31.fra.seabone.net [195.22.214.196]
8 31 ms 30 ms 31 ms teleglobe.franco31.fra.seabone.net [195.22.214.55]
9 53 ms 53 ms 52 ms if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net [195.219.87.17]
10 52 ms 52 ms 52 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net [195.219.87.14]
11 53 ms 53 ms 53 ms if-et-39-2.hcore3.MLT-Milan.as6453.net [195.219.241.30]
12 52 ms 52 ms 52 ms 195.219.158.62
13 52 ms 52 ms 52 ms itaca.telnetwork.it [195.36.1.104]
Tracert su gamesnet.it
Rilevazione instradamento verso gamesnet.it [195.36.6.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 6 ms 172.17.89.61
4 * * * Richiesta scaduta.
5 8 ms 7 ms 7 ms 172.19.177.28
6 * 9 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 17 ms 16 ms 16 ms et5-3-0.franco31.fra.seabone.net [195.22.214.92]
8 21 ms 20 ms 19 ms teleglobe.franco31.fra.seabone.net [195.22.214.55]
9 43 ms 40 ms 41 ms if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net [195.219.87.17]
10 41 ms 41 ms 40 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net [195.219.87.10]
11 41 ms 40 ms 41 ms if-et-39-2.hcore3.MLT-Milan.as6453.net [195.219.241.30]
12 40 ms 40 ms 40 ms 195.219.158.62
13 41 ms 40 ms 41 ms www.gamesnet.it [195.36.6.10]
OK grazie :p
Anche da Bologna la saga degli orrori, vi fanno fare il giro d'Europa... :mc:
Io ho cambiato operatore (avevo la FTTC di TIM fino a un paio di mesi fa) anche per questo motivo.
OK grazie :p
Anche da Bologna la sagra degli orrori, vi fanno fare il giro d'Europa... :mc:
Io ho cambiato operatore (avevo la FTTC di TIM fino a un paio di mesi fa) anche per questo motivo.
Figurati :) Dunque a quale operatore sei passato? E sempre in FTTC o in FTTH? Tu quali valori hai ora? Grazie :)
curiosità, a quanto pingate (FTTH e non) codecguide.com? (codecguide.com United States Arizona Phoenix)
curiosità, a quanto pingate (FTTH e non) codecguide.com? (codecguide.com United States Arizona Phoenix)
FTTC TIM 100/20 ping verso codecguide.com:
Esecuzione di Ping codecguide.com [104.24.118.99] con 32 byte di dati:
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=11ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=11ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=14ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=11ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Statistiche Ping per 104.24.118.99:
Pacchetti: Trasmessi = 20, Ricevuti = 20, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 11ms, Massimo = 14ms, Medio = 12ms
Dubito fortemente che sia in Arizona! :D
Figurati :) Dunque a quale operatore sei passato? E sempre in FTTC o in FTTH? Tu quali valori hai ora? Grazie :)
Infostrada FTTC (ho la All Inclusive Unlimited).
Ecco i miei:
Traccia instradamento verso gamesnet.it [195.36.6.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 151.7.32.106
4 4 ms 4 ms 4 ms 151.7.32.18
5 10 ms 14 ms 10 ms 151.6.2.5
6 10 ms 10 ms 10 ms 151.6.1.182
7 10 ms 10 ms 10 ms telnet.mix-it.net [217.29.66.5]
8 10 ms 11 ms 10 ms www.gamesnet.it [195.36.6.10]
Traccia completata.
Traccia instradamento verso telnet.it [195.36.1.104]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 5 ms 151.7.32.106
4 4 ms 4 ms 4 ms 151.7.32.96
5 11 ms 10 ms 10 ms 151.6.2.5
6 10 ms 10 ms 10 ms 151.6.1.182
7 10 ms 10 ms 10 ms telnet.mix-it.net [217.29.66.5]
8 10 ms 10 ms 10 ms itaca.telnetwork.it [195.36.1.104]
Traccia completata.
TIM era ottima a livello di banda DL/UL, ma come latenze/routing lasciamo perdere :nono:
FTTC TIM 100/20 ping verso codecguide.com:
Esecuzione di Ping codecguide.com [104.24.118.99] con 32 byte di dati:
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=11ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=11ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=14ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=11ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=13ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Risposta da 104.24.118.99: byte=32 durata=12ms TTL=56
Statistiche Ping per 104.24.118.99:
Pacchetti: Trasmessi = 20, Ricevuti = 20, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 11ms, Massimo = 14ms, Medio = 12ms
Dubito fortemente che sia in Arizona! :D
Esecuzione di Ping codecguide.com [104.24.118.99] con 32 byte di dati:
Risposta da 104.24.118.99: byte=32 durata=10ms TTL=57
Risposta da 104.24.118.99: byte=32 durata=10ms TTL=57
Risposta da 104.24.118.99: byte=32 durata=10ms TTL=57
Risposta da 104.24.118.99: byte=32 durata=10ms TTL=57
Statistiche Ping per 104.24.118.99:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 10ms, Massimo = 10ms, Medio = 10ms
Traccia instradamento verso codecguide.com [104.24.118.99]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 151.7.32.104
4 5 ms 4 ms 4 ms 151.7.32.74
5 10 ms 10 ms 10 ms 151.6.5.190
6 12 ms 11 ms 11 ms 151.6.1.178
7 10 ms 10 ms 10 ms cloudflare.mix-it.net [217.29.66.167]
8 10 ms 10 ms 10 ms 104.24.118.99
Traccia completata.
E' hostato a Milano da cloudflare infatti.
Ah ok ok, mi pareva strano infatti... su https://www.iplocation.net/ lo danno negli USA ed anche io ho 14ms di ping
I tool di geolocalizzazione lo danno negli USA perchè cloudflare è una società statunitense (come google), ma in realtà i suoi server possono essere ubicati un po' ovunque (al MIX in questo caso).
I tool di geolocalizzazione lo danno negli USA perchè cloudflare è una società statunitense (come google), ma in realtà i suoi server possono essere ubicati un po' ovunque (al MIX in questo caso).
Certo, mi ero semplicemente fidato della geolocalizzazione via ip.
Infostrada FTTC (ho la All Inclusive Unlimited).
Dici che sia la FTTC migliore in assoluto come ping? E come banda invece come va?
Ecco i miei:
Traccia instradamento verso gamesnet.it [195.36.6.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 151.7.32.106
4 4 ms 4 ms 4 ms 151.7.32.18
5 10 ms 14 ms 10 ms 151.6.2.5
6 10 ms 10 ms 10 ms 151.6.1.182
7 10 ms 10 ms 10 ms telnet.mix-it.net [217.29.66.5]
8 10 ms 11 ms 10 ms www.gamesnet.it [195.36.6.10]
Traccia completata.
Traccia instradamento verso telnet.it [195.36.1.104]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 5 ms 151.7.32.106
4 4 ms 4 ms 4 ms 151.7.32.96
5 11 ms 10 ms 10 ms 151.6.2.5
6 10 ms 10 ms 10 ms 151.6.1.182
7 10 ms 10 ms 10 ms telnet.mix-it.net [217.29.66.5]
8 10 ms 10 ms 10 ms itaca.telnetwork.it [195.36.1.104]
Traccia completata.
C'è una differenza abissale! Invece su Google MI come va? La mia va così:
Rilevazione instradamento verso mil04s25-in-f3.1e100.net [216.58.205.67]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 5 ms 172.17.88.220
4 5 ms 5 ms 4 ms 172.17.88.81
5 9 ms 8 ms 7 ms 172.19.177.28
6 9 ms 11 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 10 ms 10 ms 10 ms 72.14.209.236
8 * * * Richiesta scaduta.
9 10 ms 10 ms 10 ms 216.239.42.11
10 10 ms 10 ms 10 ms mil04s25-in-f3.1e100.net [216.58.205.67]
Certo, mi ero semplicemente fidato della geolocalizzazione via ip.
Tornando ai ping delle vostre FTTH è un peccato che a Perugia abbiate quei +5-6 ms di latenza in più... Perchè a Milano potreste stare tranquillamente sotto i 10 ms in condizioni ottimali.
Dici che sia la FTTC migliore in assoluto come ping? E come banda invece come va?
Non penso ci sia una FTTC migliore in assoluto anche perché i suoi tempi sono uguagliati (beh se vai al minimo della tecnlogia di meglio certo altri non possono fare :D), ed a volte migliorati anche da Tiscali, come in alcune zone vince pure Tim o Vodafone.
Dipende da dove stai e cosa vuoi raggiungere e caso per caso ci potrebbe essere un vincitore diverso.
Ecco a parità di zona di partenza e zona di arrivo i confronti avrebbero più senso, ma magari l'OLO che vince in tra A e B, non è più quello che vince tra A (stessa zona di partenza) e C o tra A e D.
Infine quando sono tutti tempi predominati dal routing, conta poco che tu parta come Adsl, FTTC o FTTH (le prime 2 praticamente hanno ping quasi identici se usiamo il Fast, e la terza al meglio li abbassa di 2-4ms).
PS
Le applicazioni però non si scambiano solo pacchetti icmp, e la latenza pratica (soprattutto quando il pacchetto è cicciotto o c'è da trasferire un treno di pacchetti) viene influenzata anche dalla banda (fino a certi valori di banda).
Ergo le adsl fast pingano come una FTTC ma se devi scambiarti un bel 1460B di pacchetto ogni volta, FTTC e FTTH la distaccano notevolmente sulla latenza necessaria.
Dici che sia la FTTC migliore in assoluto come ping? E come banda invece come va?
C'è una differenza abissale! Invece su Google MI come va? La mia va così:
Rilevazione instradamento verso mil04s25-in-f3.1e100.net [216.58.205.67]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 5 ms 172.17.88.220
4 5 ms 5 ms 4 ms 172.17.88.81
5 9 ms 8 ms 7 ms 172.19.177.28
6 9 ms 11 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 10 ms 10 ms 10 ms 72.14.209.236
8 * * * Richiesta scaduta.
9 10 ms 10 ms 10 ms 216.239.42.11
10 10 ms 10 ms 10 ms mil04s25-in-f3.1e100.net [216.58.205.67]
Ecco il mio Traccia instradamento verso mil04s25-in-f67.1e100.net [216.58.205.67]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 5 ms 151.7.32.106
4 5 ms 5 ms 5 ms 151.7.32.76
5 10 ms 10 ms 10 ms 151.6.2.76
6 10 ms 9 ms 9 ms 151.6.1.237
7 11 ms 10 ms 10 ms 151.6.0.30
8 * * * Richiesta scaduta.
9 10 ms 10 ms 10 ms 216.239.42.11
10 11 ms 11 ms 11 ms mil04s25-in-f67.1e100.net [216.58.205.67]
Traccia completata.
Come banda per ora (:sperem:) siamo sugli stessi livelli di TIM. Volendo trovare il pelo nell'uovo un po' più "timida" quella in upload su certi server USA. Però non ho fatto test approfonditi oltreoceano, solo qualche speedtest.
Non penso ci sia una FTTC migliore in assoluto anche perché i suoi tempi sono uguagliati (beh se vai al minimo della tecnlogia di meglio certo altri non possono fare :D), ed a volte migliorati anche da Tiscali, come in alcune zone vice pure Tim o Vodafone.
Dipende da dove stai e cosa vuoi raggiungere e caso per caso ci potrebbe essere un vincitore diverso.
Ecco a parità di zona di partenza e zona di arrivo i confronti avrebbero più senso, ma magari l'OLO che vince in tra A e B, non è più quello che vince tra A (stessa zona di partenza) e C o tra A e D.
Infine quando sono tutti tempi predominati dal routing, conta poco che tu parta come Adsl, FTTC o FTTH (le prime 2 praticamente hanno ping quasi identici se usiamo il Fast, e la terza al meglio li abbassa di 2-4ms).
PS
Le applicazioni però non si scambiano solo pacchetti icmp, e la latenza pratica (soprattutto quando il pacchetto è cicciotto o c'è da trasferire un treno di pacchetti) viene influenzata anche dalla banda (fino a certi valori di banda).
Ergo le adsl fast pingano come una FTTC ma se devi scambiarti un bel 1460B di pacchetto ogni volta, FTTC e FTTH la distaccano notevolmente sulla latenza necessaria.
Il problema è che ste FTTH non vanno mai come dovrebbero! Comunque io sono disponibile a fare qualunque test (da Bologna) :)
Ecco il mio Traccia instradamento verso mil04s25-in-f67.1e100.net [216.58.205.67]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 5 ms 151.7.32.106
4 5 ms 5 ms 5 ms 151.7.32.76
5 10 ms 10 ms 10 ms 151.6.2.76
6 10 ms 9 ms 9 ms 151.6.1.237
7 11 ms 10 ms 10 ms 151.6.0.30
8 * * * Richiesta scaduta.
9 10 ms 10 ms 10 ms 216.239.42.11
10 11 ms 11 ms 11 ms mil04s25-in-f67.1e100.net [216.58.205.67]
Traccia completata.
Come banda per ora (:sperem:) siamo sugli stessi livelli di TIM. Volendo trovare il pelo nell'uovo un po' più "timida" quella in upload su certi server USA. Però non ho fatto test approfonditi oltreoceano, solo qualche speedtest.
OK grazie :)
Tornando ai ping delle vostre FTTH è un peccato che a Perugia abbiate quei +5-6 ms di latenza in più... Perchè a Milano potreste stare tranquillamente sotto i 10 ms in condizioni ottimali.
Già, speriamo risolvano presto. Se non erro fino a non molto tempo fa (comunque prima che l'attivassi io) c'erano proprio 5-6 ms in meno verso il BBRAS Wind (e di conseguenza a cascata su tutto il percorso)... che pelotas!
Confido nel fatto che siamo una struttura completamente nuova ed anche la prima sperimentale d'Italia con Open Fiber... confido e spero, ma temo.
Già, speriamo risolvano presto. Se non erro fino a non molto tempo fa (comunque prima che l'attivassi io) c'erano proprio 5-6 ms in meno verso il BBRAS Wind (e di conseguenza a cascata su tutto il percorso)... che pelotas!
Confido nel fatto che siamo una struttura completamente nuova ed anche la prima sperimentale d'Italia con Open Fiber... confido e spero, ma temo.
Si, tanto che fino a un paio di mesi fa vedevo gente che pingava Aruba 5-6 ms, adesso saliti a 11. Speriamo che Wind prenda provvedimenti...
@ MisterFTTH
Potresti per favore postare i tracert, eseguiti sia con FTTH TIM che con FTTH Vodafone, su:
telnet.it
gamesnet.it
216.58.205.67
Grazie :)
@ Psyred
Hai pm :)
MisterFTTH (che ringrazio) mi ha risposto nel topic FTTH TIM, i risultati sono molto sconfortanti, questi sono fatti su FTTH TIM 1000/100 da Bologna:
http://www.hwupgrade.it/forum/showpost.php?p=44970449&postcount=10040
traceroute to telnet.it (195.36.1.104), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.807 ms 0.797 ms 0.905 ms
2 * * *
3 172.17.88.216 (172.17.88.216) 4.947 ms 172.17.88.218 (172.17.88.218) 4.948 ms 172.17.89.189 (172.17.89.189) 5.414 ms
4 * * *
5 172.19.177.28 (172.19.177.28) 9.124 ms 9.585 ms 172.19.177.18 (172.19.177.18) 12.853 ms
6 * * *
7 ae23.franco31.fra.seabone.net (195.22.211.48) 19.703 ms et5-1-0.franco31.fra.seabone.net (195.22.214.88) 19.660 ms et7-3-0.franco31.fra.seabone.net (195.22.214.196) 38.920 ms
8 teleglobe.franco31.fra.seabone.net (195.22.214.55) 17.280 ms 17.238 ms 29.408 ms
9 if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net (195.219.87.17) 42.315 ms 51.261 ms 47.875 ms
10 if-ae-9-2.tcore1.PVU-Paris.as6453.net (195.219.87.10) 39.177 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net (195.219.87.14) 39.182 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net (195.219.87.10) 39.836 ms
11 if-et-39-2.hcore3.MLT-Milan.as6453.net (195.219.241.30) 45.361 ms 42.939 ms 39.798 ms
12 195.219.158.62 (195.219.158.62) 40.545 ms 42.102 ms 43.730 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute to gamesnet.it (195.36.6.10), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.837 ms 0.910 ms 0.990 ms
2 * * *
3 172.17.89.189 (172.17.89.189) 5.288 ms 172.17.89.185 (172.17.89.185) 5.267 ms 5.270 ms
4 172.17.88.161 (172.17.88.161) 5.257 ms 172.17.88.77 (172.17.88.77) 6.042 ms 172.17.88.153 (172.17.88.153) 6.045 ms
5 * 172.19.177.18 (172.19.177.18) 12.771 ms 12.778 ms
6 etrunk49.milano50.mil.seabone.net (195.22.205.116) 13.564 ms 12.498 ms *
7 et7-1-0.franco31.fra.seabone.net (195.22.214.154) 32.719 ms 32.750 ms et7-3-0.franco31.fra.seabone.net (195.22.214.196) 32.758 ms
8 teleglobe.franco31.fra.seabone.net (195.22.214.55) 21.498 ms 16.925 ms 29.247 ms
9 if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net (195.219.87.17) 41.555 ms 41.246 ms 41.232 ms
10 if-ae-9-2.tcore1.PVU-Paris.as6453.net (195.219.87.10) 42.543 ms 45.055 ms 39.861 ms
11 if-et-39-2.hcore3.MLT-Milan.as6453.net (195.219.241.30) 52.033 ms 42.848 ms 40.009 ms
12 195.219.158.62 (195.219.158.62) 39.431 ms 43.126 ms 51.038 ms
13 www.gamesnet.it (195.36.6.10) 39.470 ms 43.597 ms 51.477 ms
traceroute to 216.58.205.67 (216.58.205.67), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.779 ms 0.840 ms 0.768 ms
2 * * *
3 172.17.88.218 (172.17.88.218) 5.064 ms 172.17.89.185 (172.17.89.185) 5.066 ms 172.17.89.57 (172.17.89.57) 5.061 ms
4 * * *
5 172.19.177.18 (172.19.177.18) 12.716 ms 172.19.177.28 (172.19.177.28) 8.878 ms 172.19.177.18 (172.19.177.18) 12.725 ms
6 etrunk49.milano50.mil.seabone.net (195.22.205.116) 13.491 ms 12.166 ms 12.102 ms
7 72.14.204.72 (72.14.204.72) 8.047 ms * 72.14.219.236 (72.14.219.236) 40.542 ms
8 * * *
9 216.239.42.9 (216.239.42.9) 9.588 ms 8.871 ms 8.819 ms
10 mil04s25-in-f67.1e100.net (216.58.205.67) 7.065 ms 9.651 ms 8.387 ms
Ragazzi! A detta del 159 risulto finalmente attivabile da Infostrada con la 1000/200 (anche se su kqi no...)! :)
Vi rimando al post del topic dedicato se vi interessasse:
http://www.hwupgrade.it/forum/showpost.php?p=44973196&postcount=1909
PS:
L'operatore, a domanda specifica, alla quale non mi aspettavo sapesse cosa rispondermi, mi ha detto che per il ping è meglio il "router" Nokia!
PS 2:
@ Psyred
Hai la casella pm piena :)
PS 2:
@ Psyred
Hai la casella pm piena :)
Ok, ho fatto nuovamente spazio :read:
Sono risultati normali per TIM. Ormai da anni non fanno più peering negli internet exchange, e chi vuole fare peering con loro deve pagare il servizio IP Look. Inutile dire che molti provider (giustamente) se ne fregano.. il risultato è che spesso il traffico passa per l'estero, perchè il loro upstream (Sparkle) ragiona allo stesso modo: o gli compri il transito o passano anche loro per chi ti da il transito. In questo caso Sparkle non ha un peering su Milano con Tata per cui si finisce per forza a Francoforte.
Wind, Tiscali, Fastweb e tutti gli altri sono generalmente presenti negli internet exchange per cui la situazione è diversa rispetto all'incumbent.
Esatto, la policy di depeering di Telecom si è rivelata nefasta dal punto di vista del routing.
riccardi.fede
27-08-2017, 09:50
Aggiunto grafico di Cagliari (https://drive.google.com/open?id=0B7DKWVT2g56kMWRKRS1oQXB3RkE).
Grazie lion83.
riccardi.fede
27-08-2017, 09:59
Se riesco, in giornata fornisco i risultati da linea Infostrada FTTH, sempre in Bologna.
Quante linee FTTH hai :D :D
Tutte nella stessa abitazione?
riccardi.fede
27-08-2017, 10:45
Al momento in casa mia ho due linee (TIM e Vodafone), in attesa di Tiscali (se mai ce la faranno :ciapet: ).
La linea Infostrada è da tempo attiva presso casa dei miei, ma non ho mai fatto prove specifiche, anche se mi ha sempre restituita un'ottima sensazione nell'uso "casual".
Sensazione così ottima, che potrei anche decidere di richiederne attivazione (per altro a casa dei miei eseguita nel giro di nemmeno una settimana dalla richiesta) e dimenticare Tiscali (che però per il mio utilizzo ha due plus non da poco: upstream a 300 Mb e IP pubblico statico anche su contratto residenziale).
Che poi tra l'altro con la FTTH si eliminano quelle "differenze" di prestazioni che si hanno di città in città. Per esempio velocità uguali per tutti e quindi si può capire meglio quale operatore vada meglio in determinate cose.
Giusto per Tiscali però caspita...
Ultima domanda: per le linee FTTH fai load balancing con apparecchi tipo Mikrotik? :)
Sono risultati normali per TIM. Ormai da anni non fanno più peering negli internet exchange, e chi vuole fare peering con loro deve pagare il servizio IP Look. Inutile dire che molti provider (giustamente) se ne fregano.. il risultato è che spesso il traffico passa per l'estero, perchè il loro upstream (Sparkle) ragiona allo stesso modo: o gli compri il transito o passano anche loro per chi ti da il transito. In questo caso Sparkle non ha un peering su Milano con Tata per cui si finisce per forza a Francoforte.
Wind, Tiscali, Fastweb e tutti gli altri sono generalmente presenti negli internet exchange per cui la situazione è diversa rispetto all'incumbent.
Molto interessante grazie :) Personalmente saluterò TIM a brevissimo, sia perché così imparano a non aver fatto nulla di concreto contro il famoso call center, ma soprattutto perché, come hai palesato, c'è ben di meglio in giro :)
Città: Cagliari
Gestore: Tiscali
Tipo: FTTH GPON 1000/300
Google Milano:
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=19ms TTL=51
Reply from 216.58.205.67: bytes=32 time=19ms TTL=51
Ping statistics for 216.58.205.67:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 19ms, Average = 19ms
Google Francoforte:
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=27ms TTL=49
Reply from 172.217.22.35: bytes=32 time=27ms TTL=49
Ping statistics for 172.217.22.35:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 27ms, Average = 27ms
Google Londra:
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=39ms TTL=47
Reply from 216.58.198.163: bytes=32 time=39ms TTL=47
Reply from 216.58.198.163: bytes=32 time=39ms TTL=47
Ping statistics for 216.58.198.163:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 39ms, Average = 39ms
Google New York:
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=112ms TTL=46
Reply from 172.217.12.196: bytes=32 time=111ms TTL=46
Reply from 172.217.12.196: bytes=32 time=111ms TTL=46
Ping statistics for 172.217.12.196:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 111ms, Maximum = 112ms, Average = 111ms
Google Hong Kong:
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=298ms TTL=42
Reply from 216.58.200.4: bytes=32 time=298ms TTL=42
Reply from 216.58.200.4: bytes=32 time=298ms TTL=42
Ping statistics for 216.58.200.4:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 298ms, Maximum = 298ms, Average = 298ms
Il BRAS lo pingo a 1ms.
Palermo = 6ms (rete Tiscali)
Roma = 10ms
Torino = 17ms
Milano = 19ms
Posteresti anche il ping/tracert su telnet.it e gamesnet.it? Perché abbiamo visto che sono molto più veritieri di quelli di Google, grazie :)
Ok, ho fatto nuovamente spazio :read:
Ok grazie Psyred :)
Aggiunto grafico di Cagliari (https://drive.google.com/open?id=0B7DKWVT2g56kMWRKRS1oQXB3RkE).
Grazie lion83.
Fede cosa ne dici di aggiungere telnet.it e gamesnet.it? Grazie :)
Con TIM ho già dato :p, ecco i riscontri con Vodafone:
1 192.168.1.1 (192.168.1.1) 7.870 ms 7.872 ms 7.877 ms
2 *** (***) 8.568 ms 8.628 ms 8.752 ms
3 83.224.40.182 (83.224.40.182) 8.743 ms 8.916 ms 8.916 ms
4 83.224.40.181 (83.224.40.181) 8.913 ms 9.724 ms 9.797 ms
5 83.224.40.217 (83.224.40.217) 16.126 ms 16.645 ms 16.927 ms
6 83.224.40.230 (83.224.40.230) 17.148 ms 10.153 ms 10.695 ms
7 85.205.14.101 (85.205.14.101) 66.830 ms 16.304 ms 20.553 ms
8 telnet.mix-it.net (217.29.66.5) 12.439 ms 12.456 ms 13.044 ms
9 itaca.telnetwork.it (195.36.1.104) 13.208 ms 13.337 ms 14.318 ms
1 192.168.1.1 (192.168.1.1) 7.920 ms 7.895 ms 7.891 ms
2 *** (***) 8.445 ms 8.515 ms 8.587 ms
3 83.224.40.182 (83.224.40.182) 8.797 ms 8.797 ms 8.794 ms
4 83.224.40.181 (83.224.40.181) 8.861 ms 8.912 ms 9.008 ms
5 83.224.40.217 (83.224.40.217) 15.996 ms 16.355 ms 16.818 ms
6 83.224.40.230 (83.224.40.230) 17.920 ms 10.182 ms 10.485 ms
7 85.205.14.101 (85.205.14.101) 21.183 ms 18.775 ms 18.756 ms
8 telnet.mix-it.net (217.29.66.5) 12.148 ms 16.136 ms 16.201 ms
9 www.gamesnet.it (195.36.6.10) 16.208 ms 16.203 ms 16.240 ms
1 192.168.1.1 (192.168.1.1) 7.957 ms 7.949 ms 7.957 ms
2 *** (***) 8.432 ms 8.507 ms 8.657 ms
3 83.224.40.182 (83.224.40.182) 8.649 ms 8.839 ms 8.837 ms
4 83.224.40.181 (83.224.40.181) 8.834 ms 9.591 ms 9.697 ms
5 83.224.40.217 (83.224.40.217) 16.309 ms 16.513 ms 16.573 ms
6 85.205.14.105 (85.205.14.105) 20.934 ms 12.856 ms 18.997 ms
7 72.14.223.169 (72.14.223.169) 11.313 ms 12.513 ms 12.542 ms
8 * * *
9 216.239.42.11 (216.239.42.11) 13.856 ms 216.239.42.9 (216.239.42.9) 14.010 ms 14.396 ms
10 mil04s25-in-f67.1e100.net (216.58.205.67) 14.737 ms 15.717 ms 15.847 ms
Gli asterischi all'hop 2 sono stati volutamente inseriti da me per oscurare l'IP del GTW.
Grazie! :) Direi che Vodafone è nettamente meglio di TIM, c'è poco da fare!
Se riesco, in giornata fornisco i risultati da linea Infostrada FTTH, sempre in Bologna.
Mitico! :) A proposito, ricordi quanto impiegarono ad attivare la linea? Ad oggi a Bologna c'è una grossa offerta Infostrada per la 1000/200 (vedi qui (https://www.infostrada.it/promo/absolute-fibra-bologna/)), e se le prestazioni sono top, più non fanno penare come Tiscali... è presto detto che mi "accontenterei" di 200 Mb/sec in up anziché 300 e via! :)
Quante linee FTTH hai :D :D
Tutte nella stessa abitazione?
Il Mister è allucinante! :cool:
Sensazione così ottima, che potrei anche decidere di richiederne attivazione (per altro a casa dei miei eseguita nel giro di nemmeno una settimana dalla richiesta) e dimenticare Tiscali (che però per il mio utilizzo ha due plus non da poco: upstream a 300 Mb e IP pubblico statico anche su contratto residenziale).
Penso che probabilemente darò da cavia io, quindi considera che farò qualunque test del quale ci sarà bisogno, basta che chiediate :)
http://m.memegen.com/2qo6c7.jpg
:D :D :D
Ti ho già risposto in altro mio passaggio che tu stesso hai citato successivamente nel tuo intervento :p : circa una settimana :)
Azz ho fatto casino coi quote allora, cioè non devo averlo letto, sorry Bro :)
PS:
L'operatore mi ha detto ieri che, se tengo al ping, sia importante avere il "router" Nokia: i tuoi quale hanno? Cmunque temo che non mi facciano scelgiere il modello... mannaggia! :mc:
PS 2:
Sensazione così ottima, che potrei anche decidere di richiederne attivazione (per altro a casa dei miei eseguita nel giro di nemmeno una settimana dalla richiesta) e dimenticare Tiscali (che però per il mio utilizzo ha due plus non da poco: upstream a 300 Mb e IP pubblico statico anche su contratto residenziale).
Visto ora, hai ragione! :D
Invece riguardo all'IP pubblico statico, quali sono i vantaggi esattamente?
L'operatore mi ha detto ieri che, se tengo al ping, sia importante avere il "router" Nokia: i tuoi quale hanno? Cmunque temo che non mi facciano scelgiere il modello... mannaggia! :mc:
Mah secondo me l'operatore ti ha detto la prima cosa che gli passava per la testa.
Se dai un'occhiata al thread della FTTH Infostrada gli unici che hanno avuto problemi di latenza (peraltro limitati) finora sono stati gli utenti di Perugia, e non certo per via dell'ONT/router...
L'apparato non si può scegliere in quanto viene fornito l'ONT del vendor omologo a quello dell'OLT presente in centrale/POP. A Bologna da quel che se ne sa hanno installato solo apparati Nokia/ALU, quindi quasi certamente ti daranno il Nokia.
Mah secondo me l'operatore ti ha detto la prima cosa che gli passava per la testa.
Se dai un'occhiata al thread della FTTH Infostrada gli unici che hanno avuto problemi di latenza (peraltro limitati) finora sono stati gli utenti di Perugia, e non certo per via dell'ONT/router...
L'apparato non si può scegliere in quanto viene fornito l'ONT del vendor omologo a quello dell'OLT presente in centrale/POP. A Bologna da quel che se ne sa hanno installato solo apparati Nokia/ALU, quindi quasi certamente ti daranno il Nokia.
Molto interessante, grazie :)
PS:
L'ONT su FTTH sta al router/modem su ADSL? Sempre e comunque con ogni provider, o il nome può cambiare? Perché io ho molta esperienza su ADSL, un po' su FTTC, mentre su FTTH sono praticamente un neofita, e mi trovo spesso tra molti acronimi a me sconosciuti! :D
Tieni presente che la marca dell'ONT segue quella dell'OLT (anche se il protocollo GPON sulla carta è interoperabile) ergo poiché Infostrada ad ora fornisce apparati all-in-one router/ONT riceverai il Nokia o altra marca in base all'OLT installato nella centrale di tua attestazione.
:read: :D
Nel caso dei miei (centrale San Donato) hanno ricevuto il Nokia.
Ok grazie :)
Comunque l'affermazione dell'operatrice è a mio avviso vagamente creativa: che il loro router/ONT in generale possa fornire prestazioni più affidabili per così dire, poiché si presume abbia seguito un preciso iter di certificazione per l'utilizzo con i loro apparati trasmissivi, non ho motivi a priori di metterlo in discussione, ma che sia consigliabile specificamente per ottimizzare le latenze mi lascia perplesso...a meno ché non sottintendesse il concetto che sia preferibile usare soltanto il loro router e non uno in cascata in doppio NAT, configurazione che sì in ridottissima parte potrebbe inficiare le latenze.
A proposito! Nel topic FTTH Infostrada c'è un ragazzo che cerca info a riguardo, ti lascio il link:
http://www.hwupgrade.it/forum/showpost.php?p=44973932&postcount=1916
Ma siamo sicuri che ci sia un livello di competenza tecnica sufficiente per considerare lato Servizio Clienti questa ipotesi? Senza voler giudicare in un senso o nell'altro qualcuno o qualcosa che non conosco in dettaglio, la mia sensazione a pelle è che si sia sbilanciata con quell'indicazione esclusivamente per supportare meglio agli occhi del cliente l'adozione di quel modello di router.
Si probabilmente hai ragione! L'unico dettagli contrastante, era un operatore e non un'operatrice, ma la cose non cambiano :D
Notata ora l'integrazione del tuo intervento :)
Sorry Bro ho sta abitudine di inviare il post e poi mettermi a modificarlo 100 volte :D
A livello domestico i vantaggi sono squisitamente soggettivi: nel mio caso mi eviterebbe il disagio di aggiornare le tabelle DNS lato Registrar per i miei domini in ogni evento di cambio IP dinamico (riavvio router, black-out, caduta sessione PPP, etc etc...) e mi consentirebbe la richiesta di inserimento record PTR nelle tabelle DNS dell'ISP (condizionale d'obbligo, poiché non ho la certezza che Tiscali esegua una richiesta del genere nel caso di IP statico assegnato a cliente residenziale). In generale potrei finalmente dimenticarmi di qualsiasi DYNDNS,
:read: :D
eventuali disservizi di qualsiasi natura compresi, avendo la certezza di sapere come raggiungere sempre router/server.
Capisco :)
D'altro canto un IP statico ha anche svantaggi...se per qualsiasi motivo finisci nelle mire di malintenzionati seri potrebbero essere dolori, ad esempio...
Perché quell'ip sarebbe necessariamente riconducibile a te, giusto? Ma cosa potrebbero farci esattamente?
Comunque, a livello di ping e di banda, un ip dinamico o statico non farebbe differenza, vero?
NB:
Siete entrambi due enormi risorse del forum, complimenti davvero! :)
Molto interessante, grazie :)
PS:
L'ONT su FTTH sta al router/modem su ADSL? Sempre e comunque con ogni provider, o il nome può cambiare? Perché io ho molta esperienza su ADSL, un po' su FTTC, mentre su FTTH sono praticamente un neofita, e mi trovo spesso tra molti acronimi a me sconosciuti! :D
Si praticamente l'ONT (Optical Network Terminal) sta al modem di ADSL. Alcuni operatori lo forniscono come apparato separato rispetto al router (TIM e Vodafone). Altri adottano la soluzione ONT+router integrato (Infostrada e Tiscali).
riccardi.fede
27-08-2017, 13:57
Fede cosa ne dici di aggiungere telnet.it e gamesnet.it? Grazie :)
Per ora lasciamo solo google, che se no dobbiamo richiedere il ping/tracert agli utenti ed è un casino. :muro:
Che poi tra l'altro gamesnet.it che server è? Un server di un gioco? Dobbiamo utilizzare server che vengano utilizzati "quotidianamente".
Poi ovviamente io sono di questa teoria: ogni operatore ha i pro/contro di ogni instradamento.
Se prendiamo come esempio Bologna (https://drive.google.com/file/d/0B7DKWVT2g56kWDVhZ0Y5R3NDMEU/view), Wind è la peggiore per il ping verso Milano e Francofrote. Ok il problema e speriamo risolvano, però intanto ad oggi c'è.
Verso Londra invece la migliore è WIND.
Chicago, Hong Kong: Vodafone.
Pertanto come vedete dipende anche dall'utilizzo che ne fate voi. Se utilizzate molto spesso i server italiani, meglio non puntare a WIND.
Ovviamente manca ancora all'appello Tiscali e vedremo a breve.
L'ONT su FTTH sta al router/modem su ADSL? Sempre e comunque con ogni provider, o il nome può cambiare? Perché io ho molta esperienza su ADSL, un po' su FTTC, mentre su FTTH sono praticamente un neofita, e mi trovo spesso tra molti acronimi a me sconosciuti! :D
Diciamo più alla parte modem pura, il router è hw a parte (ovviamente come ci sono router con modem integrati presumo ci siano anche qualche router con ont integrato).
Semplificando un po' il Optical Network Terminator puoi considerarlo come il convertitore fibra->ethernet in rame.
Perché quell'ip sarebbe necessariamente riconducibile a te, giusto? Ma cosa potrebbero farci esattamente?
Se hai un ip fisso una volta che sei preso di mira lo rimani.
Un po' come il tuo indirizzo di casa, se lo vengo a sapere poi posso venire tutti i gg a romperti (se voglio).
Se stai in albergo (ip dinamico) se ti scoccia la cosa cambi albergo ed io sono fregato (per un po' almeno).
Poi il dinamico può tornare utile per certi giochetti.
Es. magari un servizio Free può limitarti a 3 download al giorno e per limitarti (se non ci sono account, anche free, da fare, o cookie salvati) può usare il tuo ip.
Tu fai i 3 download, scolleghi e ricolleghi il ppp per cambiare ip (se il tuo provider lo fa ad ogni ppp session) e poi ti fai altri 3 download :D
Se hai lo statico aspetti per forza domani.
Comunque, a livello di ping e di banda, un ip dinamico o statico non farebbe differenza, vero?
No cambia spesso il routing e quindi cambia o può cambiare il ping.
Io avevo una linea adsl (tiscali ovv.) in passato che se la usavo con ip statico pingavo a 30-50ms (non ricordo il valore ma era mediamente alto) e se la usavo con ip dinamico pingavo (lo stesso server di prima) a 15-25ms
Poi dopo un po' di mie lamentele (o magari per conto loro e non sono stati io a...) hanno migliorato la latenza (alias il routing) anche in versione statica.
PS
Ora ho una FTTC con ip statico ed i ping sono stra-ottimi (li ho pubblicati gg fa).
Quindi non fare associazione statico = ping peggiore, io ho solo detto statico e dinamico possono (non devono) avere ping diversi perché spesso fanno rotte diverse.
Perchè l'utilità di pingare 10 ms in più o in meno qualche server google sparso chissadove dove sarebbe allora? :rolleyes:
Gamesnet hostava (e credo lo faccia ancora) game server; e in ogni caso si appoggia a telnet.it , un importante fornitore di connettività internet italiano, presente anche al MIX.
http://www.telnet.it/it/home/
Si praticamente l'ONT (Optical Network Terminal) sta al modem di ADSL. Alcuni operatori lo forniscono come apparato separato rispetto al router (TIM e Vodafone). Altri adottano la soluzione ONT+router integrato (Infostrada e Tiscali).
Ok ora mi è chiaro grazie mille! :) Infatti non capivo sta cosa che alcuni avessero un dispositivo unico mentre altri no! Comunque diciamo che ONT sta per modem, mentre il router è quello che ha la funzione di gestire le altre connessioni interne, da questi sia ha l'ONT+router per la FTTH e il modem+router per l'ADSL e la FTTC, a prescindere che possano essere due dispositivi separati od uno solo, giusto?
Per ora lasciamo solo google, che se no dobbiamo richiedere il ping/tracert agli utenti ed è un casino. :muro:
Se vuoi mi prendo l'incarico io di contattarli uno per uno per pm, non è un problema :)
Che poi tra l'altro gamesnet.it che server è? Un server di un gioco? Dobbiamo utilizzare server che vengano utilizzati "quotidianamente".
Io non sono esperto, ma invece Psyred parecchio, e dice che sono due server da tenere in considerazione per il gaming, quindi secondo me sono utilizzati quotidianamente, ma dai gamer e non da chiunque; ma sentiamo da lui perché ne sa molto più di me!
Poi ovviamente io sono di questa teoria: ogni operatore ha i pro/contro di ogni instradamento.
Se prendiamo come esempio Bologna (https://drive.google.com/file/d/0B7DKWVT2g56kWDVhZ0Y5R3NDMEU/view), Wind è la peggiore per il ping verso Milano e Francofrote. Ok il problema e speriamo risolvano, però intanto ad oggi c'è.
Verso Londra invece la migliore è WIND.
Chicago, Hong Kong: Vodafone.
Intendi la peggiore secondo la media dei dati che abbiamo qui? Perché come singole connessioni prese credo che la migliore in assoluto sia stata semrpe Wind/Infostrada. Comunque MisterFTTH farà prove dirette anche su quella da Bologna, quindi avremo novità di certo :)
Pertanto come vedete dipende anche dall'utilizzo che ne fate voi. Se utilizzate molto spesso i server italiani, meglio non puntare a WIND.
Ovviamente manca ancora all'appello Tiscali e vedremo a breve.
I server citati da Psyred sono italiani!
Diciamo più alla parte modem pura, il router è hw a parte (ovviamente come ci sono router con modem integrati presumo ci siano anche qualche router con ont integrato).
Semplificando un po' il Optical Network Terminator puoi considerarlo come il convertitore fibra->ethernet in rame.
Se hai un ip fisso una volta che sei preso di mira lo rimani.
Un po' come il tuo indirizzo di casa, se lo vengo a sapere poi posso venire tutti i gg a romperti (se voglio).
Se stai in albergo (ip dinamico) se ti scoccia la cosa cambi albergo ed io sono fregato (per un po' almeno).
Poi il dinamico può tornare utile per certi giochetti.
Es. magari un servizio Free può limitarti a 3 download al giorno e per limitarti (se non ci sono account, anche free, da fare, o cookie salvati) può usare il tuo ip.
Tu fai i 3 download, scolleghi e ricolleghi il ppp per cambiare ip (se il tuo provider lo fa ad ogni ppp session) e poi ti fai altri 3 download :D
Se hai lo statico aspetti per forza domani.
No cambia spesso il routing e quindi cambia o può cambiare il ping.
Io avevo una linea adsl (tiscali ovv.) in passato che se la usavo con ip statico pingavo a 30-50ms (non ricordo il valore ma era mediamente alto) e se la usavo con ip dinamico pingavo (lo stesso server di prima) 15-25ms
Poi dopo un po' di mie lamentele (o magari per conto loro e non sono stati io a...) hanno migliorato la latenza (alias il routing) anche in versione statica.
PS
Ora ho una FTTC con ip statico ed i ping sono stra-ottimi (li ho pubblicati gg fa).
Quindi non fare associazione statico = ping peggiore, io ho solo detto statico e dinamico possono (non devono) avere ping diversi perché spesso fanno rotte diverse.
Molto interessante grazie! :) Si potrebbe quindi dire che con l'ip dinamico, se si pingasse male, si potrebbe riavviare l'ONT/router (:read: :D) e tentare con il nuovo assegnato, mentre con quello statico, se si prende male, ce lo si tiene per forza, giusto?
Perchè l'utilità di pingare 10 ms in più o in meno qualche server google sparso chissadove dove sarebbe allora? :rolleyes:
Gamesnet hostava (e credo lo faccia ancora) game server; e in ogni caso si appoggia a telnet.it , un importante fornitore di connettività internet italiano, presente anche al MIX.
http://www.telnet.it/it/home/
Allora io li includerei nella statistica! Mi prendo io l'onere di contattare gli utenti per pm uno per uno, don't worry bros :cool:
Molto interessante grazie! :) Si potrebbe quindi dire che con l'ip dinamico, se si pingasse male, si potrebbe riavviare l'ONT/router (:read: :D) e tentare con il nuovo assegnato, mentre con quello statico, se si prende male, ce lo si tiene per forza, giusto?
Si con statico se pinga male te la tieni così finché il provider non decide di migliorare (cosa che può anche essere automatica dato che le rotte tra gli endpoint si autoriconfigurano tramite i protocolli di routing, es: BGP, OSPF, ...ecc).
Se hai ip dinamico puoi provare a cambiarlo più volte alla ricerca di rotte (e quindi latenze) migliori (senza garanzie di migliorare però, come puoi anche peggiorare).
Su TIM (che ha più subnet ip per gli ip dinamici) ho letto che alcuni in FTTC fanno proprio così e qualche volta ottengono dei miglioramenti tangibili.
Sugli altri OLO non ho letto di attività simili (alias magari cambiare ip non serve, tranne al più nel passaggio da subnet/classe ip per ip dinamici a subnet/classe ip per ip statici e viceversa)
Allora io li includerei nella statistica! Mi prendo io l'onere di contattare gli utenti per pm uno per uno, don't worry bros :cool:
Io li ho proposti soprattutto per confronto con il routing di Telecom, poi fate a vostra discrezione... Se l'obiettivo è il gaming ci sarebbe da inserirne molti altri, tipo OVH, multiplay UK, ecc. (vedi firma ;) ).
Ma siamo sicuri che ci sia un livello di competenza tecnica sufficiente per considerare lato Servizio Clienti questa ipotesi? Senza voler giudicare in un senso o nell'altro qualcuno o qualcosa che non conosco in dettaglio, la mia sensazione a pelle è che si sia sbilanciata con quell'indicazione esclusivamente per supportare meglio agli occhi del cliente l'adozione di quel modello di router.
Ma pensate davvero che gli operatori di call center abbiano una conoscenza approfondita di tutto quello che trattano?
Hanno un albero di domande e risposte che cliccano in base a quello che gli dite.
Se poi giungono ad un punto morto al limite possono passarvi qualcuno con le competenze necessarie.
Questa scrematura permette di limitare il numero di persone realmente qualificate (abbassando i costi) ed è il motivo per cui inizialmente vi vengono rivolte domande tipo "il modem è acceso?".
Si con statico se pinga male te la tieni così finché il provider non decide di migliorare (cosa che può anche essere automatica dato che le rotte tra gli endpoint si autoriconfigurano tramite i protocolli di routing, es: BGP, OSPF, ...ecc).
Se hai ip dinamico puoi provare a cambiarlo più volte alla ricerca di rotte (e quindi latenze) migliori (senza garanzie di migliorare però, come puoi anche peggiorare).
Ora che mi ricordo su FTTC TIM facemmo molti test anni fa proprio con diversi ip (riavviavamo i router), e scrissi la lista con i vari ip con migliori prestazioni!!! :cool:
Su TIM (che ha più subnet ip per gli ip dinamici) ho letto che alcuni in FTTC fanno proprio così e qualche volta ottengono dei miglioramenti tangibili.
Sugli altri OLO non ho letto di attività simili (alias magari cambiare ip non serve, tranne al più nel passaggio da subnet/classe ip per ip dinamici a subnet/classe ip per ip statici e viceversa)
Si si! Se l'hai letto su topic di altro forum quel topic l'ho aperto e seguito io per anni! Fece oltre un milione di visite :D
Io li ho proposti soprattutto per confronto con il routing di Telecom, poi fate a vostra discrezione... Se l'obiettivo è il gaming ci sarebbe da inserirne molti altri, tipo OVH, multiplay UK, ecc. (vedi firma ;) ).
Si si! Facciamo il listone server gaming, poi Fede lo aiuto io (se no chiama il sindacato!!!) :D Scherzo eh @ Fede! :)
Milano, Francoforte, Londra, Chicago e HongKong.
Li puoi scoprire tranquillamente su https://check-host.net
Li puoi scoprire ancor più facilmente usando l'attributo -a al comando ping e leggendo il nome dell'host ;-)
C:\WINDOWS\System32>ping -a 172.217.22.35
Pinging fra15s16-in-f3.1e100.net [172.217.22.35] with 32 bytes of data
Dove fra si intende sia Francia.
Se vi può tornare utile, FTTB dalla periferia Londinese (30 km circa) ed uno scriptino scritto con i piedi che potete riusare così da non editare il vostro post specificando i luoghi di destinazione:
test_ping.bat:
@ECHO OFF
echo *** Google Italia (Milano) ***>> output-ping.txt
ping 216.58.205.67 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google Germania (Francoforte) ***>> output-ping.txt
ping 172.217.22.35 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google UK (Londra) ***>> output-ping.txt
ping 216.58.198.163 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google USA (New York) ***>> output-ping.txt
ping 172.217.12.196 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google Hong Kong (HK) ***>> output-ping.txt
ping 216.58.200.4 -n 10 >> output-ping.txt
pause
output-ping.txt:
*** Google Italia (Milano) ***
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Ping statistics for 216.58.205.67:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 22ms, Average = 22ms
*** Google Germania (Francoforte) ***
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=15ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Ping statistics for 172.217.22.35:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 15ms, Average = 14ms
*** Google UK (Londra) ***
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Ping statistics for 216.58.198.163:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms
*** Google USA (New York) ***
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Ping statistics for 172.217.12.196:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 80ms, Maximum = 80ms, Average = 80ms
*** Google Hong Kong (HK) ***
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Ping statistics for 216.58.200.4:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 263ms, Maximum = 263ms, Average = 263ms
Dove fra si intende sia Francia.
fra = Francoforte
riccardi.fede
27-08-2017, 16:10
Io li ho proposti soprattutto per confronto con il routing di Telecom, poi fate a vostra discrezione... Se l'obiettivo è il gaming ci sarebbe da inserirne molti altri, tipo OVH, multiplay UK, ecc. (vedi firma ;) ).
Non sapevo di Telnet, o meglio, io non l'avevo mai sentito :D
Allora visto che insistete, aggiungiamo alla lista altri due/tre server da pingare.
Visto che non sono esperto di gaming online, lascio a voi scegliere il server. Però ad una condizione: dovranno essere i server più utilizzati in ambito gaming.
fra = Francoforte
eheh, svista, grazie ;-)
EliGabriRock44
27-08-2017, 16:16
Non sapevo di Telnet, o meglio, io non l'avevo mai sentito :D
Allora visto che insistete, aggiungiamo alla lista altri due/tre server da pingare.
Visto che non sono esperto di gaming online, lascio a voi scegliere il server. Però ad una condizione: dovranno essere i server più utilizzati in ambito gaming.
E chi li conosce gli IP?
I maggiori server sono in Nord Europa, tra l'Irlanda e la Germania...
verygames.net (data center OVH, Roubaix, FR)
multiplay.co.uk
i3d.net (interactive3D, NL).
Ok sono FTTC però cmq questi sono i miei ping:
--- verygames.net ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 20.388/20.727/21.134 ms
--- multiplay.co.uk ping statistics ---
21 packets transmitted, 21 packets received, 0% packet loss
round-trip min/avg/max = 24.451/26.719/28.087 ms
--- i3d.net ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 25.649/25.979/26.576 ms
--- Google Milano ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 4.613/4.918/5.173 ms
--- Google Francoforte ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max = 13.130/13.582/13.944 ms
--- Google Londra ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max = 24.224/24.754/25.083 ms
--- Google New York ping statistics ---
18 packets transmitted, 18 packets received, 0% packet loss
round-trip min/avg/max = 97.381/97.767/98.090 ms
--- Google Hong Kong ping statistics ---
18 packets transmitted, 17 packets received, 5% packet loss
round-trip min/avg/max = 283.632/283.922/284.217 ms
Li puoi scoprire ancor più facilmente usando l'attributo -a al comando ping e leggendo il nome dell'host ;-)
C:\WINDOWS\System32>ping -a 172.217.22.35
Pinging fra15s16-in-f3.1e100.net [172.217.22.35] with 32 bytes of data
Interessante! :)
Se vi può tornare utile, FTTB dalla periferia Londinese (30 km circa) ed uno scriptino scritto con i piedi che potete riusare così da non editare il vostro post specificando i luoghi di destinazione:
test_ping.bat:
@ECHO OFF
echo *** Google Italia (Milano) ***>> output-ping.txt
ping 216.58.205.67 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google Germania (Francoforte) ***>> output-ping.txt
ping 172.217.22.35 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google UK (Londra) ***>> output-ping.txt
ping 216.58.198.163 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google USA (New York) ***>> output-ping.txt
ping 172.217.12.196 -n 10 >> output-ping.txt
echo. >> output-ping.txt
echo. >> output-ping.txt
echo *** Google Hong Kong (HK) ***>> output-ping.txt
ping 216.58.200.4 -n 10 >> output-ping.txt
pause
output-ping.txt:
*** Google Italia (Milano) ***
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Reply from 216.58.205.67: bytes=32 time=22ms TTL=50
Ping statistics for 216.58.205.67:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 22ms, Average = 22ms
*** Google Germania (Francoforte) ***
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=15ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Reply from 172.217.22.35: bytes=32 time=14ms TTL=50
Ping statistics for 172.217.22.35:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 15ms, Average = 14ms
*** Google UK (Londra) ***
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Reply from 216.58.198.163: bytes=32 time=2ms TTL=54
Ping statistics for 216.58.198.163:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms
*** Google USA (New York) ***
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Reply from 172.217.12.196: bytes=32 time=80ms TTL=51
Ping statistics for 172.217.12.196:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 80ms, Maximum = 80ms, Average = 80ms
*** Google Hong Kong (HK) ***
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Reply from 216.58.200.4: bytes=32 time=263ms TTL=46
Ping statistics for 216.58.200.4:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 263ms, Maximum = 263ms, Average = 263ms
Meno male che sarebbe uno scriptino scritto con i piedi! Gran bel lavoro! :)
fra = Francoforte
eheh, svista, grazie ;-)
Questa è una grande Squadra, cari Signore e Signori, c'è poco da aggiungere :cool:
Non sapevo di Telnet, o meglio, io non l'avevo mai sentito :D
Allora visto che insistete, aggiungiamo alla lista altri due/tre server da pingare.
Visto che non sono esperto di gaming online, lascio a voi scegliere il server. Però ad una condizione: dovranno essere i server più utilizzati in ambito gaming.
Fede ci affidiamo a Psyred :)
E chi li conosce gli IP?
I maggiori server sono in Nord Europa, tra l'Irlanda e la Germania...
Abbi fede Eli! :read: Cioè intesa come "faith" eh, non come "Fede" (se no Fede si sente chiamato in causa!) :D
verygames.net (data center OVH, Roubaix, FR)
multiplay.co.uk
i3d.net (interactive3D, NL).
:read:
verygames.net (data center OVH, Roubaix, FR)
multiplay.co.uk
i3d.net (interactive3D, NL).
Ho incluso i famosi gamesnet.it e telnet.it, siccome non ho capito se li dobbiamo mantenere, più tutti i Google (ma penso che per confrontare con i 3 che hai citato, date le distanze, forse Londra e Francoforte siano i più indicati, o sbaglio?).
FTTC TIM 100/20 da Bologna:
Rilevazione instradamento verso verygames.net [94.23.214.174]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.89.61
4 5 ms 4 ms 5 ms 172.17.88.153
5 * 11 ms 11 ms 172.19.177.18
6 12 ms 13 ms 20 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 19 ms 20 ms 19 ms ae10.milano58.mil.seabone.net [195.22.208.117]
8 10 ms 10 ms 10 ms be100-152.mil-5-a9.it.eu [91.121.131.62]
9 17 ms 16 ms 16 ms vl110.rbx-g2-a75.fr.eu [91.121.215.220]
10 * * * Richiesta scaduta.
11 28 ms 25 ms 25 ms vl1251.rbx-g2-a75.fr.eu [37.187.232.28]
12 * * * Richiesta scaduta.
13 * * * Richiesta scaduta.
14 25 ms 25 ms 25 ms www-3.verygames.net [94.23.214.174]
Rilevazione instradamento verso multiplay.co.uk [85.236.96.26] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 11 ms 4 ms 172.17.89.189
4 5 ms 4 ms 4 ms 172.17.88.177
5 11 ms 11 ms 11 ms 172.19.177.18
6 15 ms 12 ms 20 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 12 ms 16 ms 12 ms ae10.milano58.mil.seabone.net [195.22.208.117]
8 * * 13 ms lag-10.bear1.Milan2.Level3.net [4.68.73.37]
9 * * * Richiesta scaduta.
10 * * * Richiesta scaduta.
11 29 ms 29 ms 29 ms 195.50.120.99
12 29 ms 29 ms 29 ms ha01.multiplay.co.uk [85.236.96.26]
Rilevazione instradamento verso i3d.net [188.122.94.99] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.88.218
4 * 5 ms 5 ms 172.17.88.97
5 11 ms 12 ms 11 ms 172.19.177.18
6 12 ms 12 ms 12 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 31 ms 31 ms 34 ms ae24.amster51.ams.seabone.net [195.22.213.216]
8 32 ms 32 ms 32 ms 100ge.ams-ix.i3d.net [80.249.208.162]
9 39 ms 39 ms 38 ms 60ge.cr1-ar0.smartdc.rtm.i3d.net [109.200.218.86]
10 38 ms 38 ms 38 ms 100ge.br2-cr1.smartdc.rtm.i3d.net [188.122.95.84]
11 34 ms 31 ms 32 ms www.i3d.net [188.122.94.99]
Rilevazione instradamento verso gamesnet.it [195.36.6.10]
su un massimo di 30 punti di passaggio:
1 1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 7 ms 4 ms 4 ms 172.17.89.61
4 5 ms 5 ms 5 ms 172.17.88.77
5 * 11 ms 11 ms 172.19.177.18
6 * * * Richiesta scaduta.
7 31 ms 31 ms 41 ms et7-3-0.franco31.fra.seabone.net [195.22.214.196]
8 29 ms 29 ms 29 ms teleglobe.franco31.fra.seabone.net [195.22.214.55]
9 55 ms 54 ms 53 ms if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net [195.219.87.17]
10 53 ms 53 ms 53 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net [195.219.87.14]
11 54 ms 53 ms 53 ms if-et-39-2.hcore3.MLT-Milan.as6453.net [195.219.241.30]
12 53 ms 53 ms 52 ms 195.219.158.62
13 54 ms 53 ms 52 ms www.gamesnet.it [195.36.6.10]
Rilevazione instradamento verso telnet.it [195.36.1.104]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.89.57
4 5 ms 4 ms 5 ms 172.17.88.165
5 8 ms 7 ms 7 ms 172.19.177.28
6 9 ms 10 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 19 ms 19 ms 19 ms ae23.franco31.fra.seabone.net [195.22.211.48]
8 20 ms 22 ms 19 ms teleglobe.franco31.fra.seabone.net [195.22.214.55]
9 45 ms 43 ms 44 ms if-ae-4-2.tcore2.FNM-Frankfurt.as6453.net [195.219.87.17]
10 43 ms 43 ms 44 ms if-ae-9-2.tcore1.PVU-Paris.as6453.net [195.219.87.14]
11 44 ms 44 ms 43 ms if-et-39-2.hcore3.MLT-Milan.as6453.net [195.219.241.30]
12 44 ms 43 ms 43 ms 195.219.158.62
13 43 ms 43 ms 43 ms itaca.telnetwork.it [195.36.1.104]
Rilevazione instradamento verso mil04s25-in-f67.1e100.net [Google Milano - 216.58.205.67] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.89.185
4 4 ms 5 ms 5 ms 172.17.88.177
5 12 ms 11 ms 11 ms 172.19.177.18
6 * * 13 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 10 ms 10 ms 11 ms 74.125.51.148
8 * * * Richiesta scaduta.
9 10 ms 9 ms 15 ms 216.239.42.11
10 21 ms 21 ms 21 ms mil04s25-in-f67.1e100.net [216.58.205.67]
Rilevazione instradamento verso fra15s16-in-f35.1e100.net [Google Francoforte - 172.217.22.35] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 5 ms 172.17.89.185
4 5 ms 4 ms 5 ms 172.17.88.177
5 12 ms 11 ms 11 ms 172.19.177.18
6 * 12 ms * etrunk49.milano50.mil.seabone.net [195.22.205.11
6]
7 10 ms 10 ms 10 ms 74.125.51.148
8 10 ms 10 ms 11 ms 108.170.245.72
9 19 ms 19 ms 19 ms 108.170.233.11
10 20 ms 18 ms 19 ms 209.85.241.70
11 22 ms 21 ms 21 ms 108.170.251.129
12 22 ms 21 ms 22 ms 66.249.95.29
13 19 ms 19 ms 19 ms fra15s16-in-f35.1e100.net [172.217.22.35]
Rilevazione instradamento verso lhr25s10-in-f163.1e100.net [Google Londra - 216.58.198.163] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.89.61
4 5 ms 5 ms 4 ms 172.17.88.153
5 11 ms 11 ms 11 ms 172.19.177.18
6 * 12 ms 11 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 12 ms 11 ms 11 ms 74.125.51.12
8 10 ms 9 ms 10 ms 108.170.245.89
9 19 ms 24 ms 18 ms 209.85.247.81
10 25 ms 24 ms 55 ms 108.170.236.120
11 38 ms 33 ms 33 ms 108.170.237.243
12 34 ms 33 ms 33 ms 216.239.57.236
13 * * * Richiesta scaduta.
14 30 ms 30 ms 30 ms 108.170.232.99
15 41 ms 41 ms 41 ms lhr25s10-in-f163.1e100.net [216.58.198.163]
Rilevazione instradamento verso lga25s63-in-f4.1e100.net [Google Chicago - 172.217.12.196] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 7 ms 4 ms 5 ms 172.17.88.218
4 * * 5 ms 172.17.88.105
5 8 ms 8 ms 7 ms 172.19.177.28
6 9 ms 8 ms 8 ms etrunk49.milano1.mil.seabone.net [195.22.205.98]
7 8 ms 8 ms 8 ms 72.14.196.141
8 8 ms 8 ms 8 ms 108.170.245.88
9 20 ms 19 ms 20 ms 209.85.247.45
10 28 ms 28 ms 29 ms 209.85.253.185
11 111 ms 111 ms 111 ms 209.85.249.60
12 111 ms 115 ms 111 ms 209.85.254.138
13 * * * Richiesta scaduta.
14 111 ms 111 ms 110 ms 108.170.226.207
15 111 ms 110 ms 110 ms lga25s63-in-f4.1e100.net [172.217.12.196]
Rilevazione instradamento verso hkg12s11-in-f4.1e100.net [Google Hong Kong - 216.58.200.4] su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms modemtelecom.homenet.telecomitalia.it [192.168.1.1]
2 * * * Richiesta scaduta.
3 8 ms 5 ms 4 ms 172.17.89.189
4 * 5 ms 4 ms 172.17.88.97
5 12 ms 11 ms 11 ms 172.19.177.18
6 * 12 ms 12 ms etrunk49.milano50.mil.seabone.net [195.22.205.116]
7 11 ms 10 ms 10 ms 72.14.195.206
8 10 ms 18 ms 10 ms 108.170.245.89
9 22 ms 21 ms 21 ms 216.239.57.246
10 27 ms 27 ms 27 ms 216.239.50.187
11 112 ms 112 ms 111 ms 216.239.42.90
12 125 ms 124 ms 124 ms 216.239.59.0
13 178 ms 178 ms 177 ms 72.14.233.111
14 182 ms 178 ms 178 ms 72.14.238.85
15 323 ms 297 ms 296 ms 209.85.246.188
16 309 ms 310 ms 308 ms 216.239.46.118
17 308 ms 308 ms 309 ms 72.14.232.154
18 303 ms 302 ms 302 ms 108.170.241.65
19 307 ms 306 ms 307 ms 209.85.240.9
20 305 ms 305 ms 305 ms hkg12s11-in-f4.1e100.net [216.58.200.4]
Riepilogo valori massimi tracert Aereo - FTTC TIM 100/20 da Bologna:
verygames.net: 28 ms
multiplay.co.uk: 29 ms
i3d.net: 39 ms
gamesnet.it: 55 ms
telnet.it: 45 ms
Google Milano: 21 ms
Google Francoforte: 22 ms
Google Londra: 41 ms
Google Chicago: 115 ms
Google Hong Kong: 323 ms
I valori massimi dei tracert possono essere equiparati ad un test diretto del ping?
Comunque al di là di gamesnet.it io considererei anche il routing internazionale visto che buona parte dei gaming server sono fuori Italia.
Avendo attualmente tre linee (TIM, Tiscali, Infostrada) e quindi potendole facilmente mettere a confronto, almeno qui da Firenze TIM è la meglio delle tre nel complesso (fino a qualche anno fa era Tiscali), poi magari da altre zone potrebbe essere diverso.
In Italia è vero che TIM pinga male su alcuni server (tipo gamesnet.it) da quando nel 2013 ha tolto i peering al mix, ma in molti casi, per raggiungere la destinazione il Seabone si aggancia comunque a qualche carrier in Italia\Milano e quindi la latenza finale risulta pressochè analoga a quella che sarebbe passando per il mix.
Su gamesnet invece sfortunatamente il peering con Teleglobe\TATA è a Francoforte quindi si perdono un 20\30ms facendo un giro lungo.
Come latenze in Italia probabilmente la migliore è Infostrada sempre relativamente alla mia zona.
Alla fine dipende dove uno ha interesse a pingare basso, anche se in generale le differenze non sono poi così enormi, sicuramente si sono assottigliate rispetto al passato, tanto per dirne una ricordo quando anni fa quasi nessun Carrier faceva peering con Cogent in Europa e di conseguenza tutti i server su quella rete, tipo alcuni da gaming in Germania, si dovevano raggiungere passando da New York..... e la cosa chiaramente non era temporanea ma una costante fino a quando non sono cambiate le politiche di routing negli anni successivi.
Comunque questi i miei ping con TIM e Infostrada sui server esteri accennati da Psyred, (ne aggiungo altri in Europa ed un paio in USA).
Traccia instradamento verso verygames.de [51.255.33.115]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.105.229
4 7 ms 7 ms 7 ms 172.17.104.145
5 35 ms 11 ms 11 ms 172.19.241.228
6 * * * Richiesta scaduta.
7 17 ms 14 ms 19 ms ae11.milano58.mil.seabone.net [195.22.208.79]
8 10 ms 9 ms 9 ms be100-152.mil-5-a9.it.eu [91.121.131.62]
9 * * * Richiesta scaduta.
10 21 ms 21 ms 21 ms be99-1258.gsw-1-a9.fr.eu [91.121.215.219]
11 26 ms 26 ms 25 ms be10-150.rbx-g1-a9.fr.eu [91.121.215.176]
12 * * * Richiesta scaduta.
13 25 ms 25 ms 24 ms be5.gra-z1g2-a75.fr.eu [37.187.232.77]
14 * * * Richiesta scaduta.
15 25 ms 24 ms 25 ms 51.255.244.236
16 25 ms 25 ms 25 ms 149.202.255.33
17 25 ms 24 ms 24 ms web-3.verygames.net [51.255.33.115]
Traccia completata.
C:\Users\Admin>tracert fshost.de
Traccia instradamento verso fshost.de [212.224.93.2]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.104.164
4 7 ms 7 ms 7 ms 172.17.104.145
5 10 ms 11 ms 11 ms 172.19.241.228
6 * 9 ms 9 ms etrunk39.milano1.mil.seabone.net [195.22.192.178]
7 8 ms 9 ms 9 ms et5-1-0-50.milano51.mil.seabone.net [195.22.205.55]
8 9 ms 9 ms 11 ms ntt-verio.milano51.mil.seabone.net [93.186.128.157]
9 21 ms 21 ms 21 ms ae-1.r01.mlanit01.it.bb.gin.ntt.net [129.250.5.82]
10 21 ms 21 ms 21 ms ae-2.r24.frnkge08.de.bb.gin.ntt.net [129.250.3.183]
11 22 ms 22 ms 22 ms ae-13.r03.frnkge03.de.bb.gin.ntt.net [129.250.6.207]
12 24 ms 24 ms 24 ms 212.119.27.218
13 26 ms 54 ms 44 ms cr03.fra1.de.first-colo.net [212.224.102.133]
14 24 ms 24 ms 24 ms 212.224.93.2
Traccia completata.
C:\Users\Admin>tracert multiplay.co.uk
Traccia instradamento verso multiplay.co.uk [85.236.96.26]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.105.229
4 6 ms 7 ms 7 ms 172.17.104.96
5 11 ms 11 ms 11 ms 172.19.241.226
6 11 ms 10 ms 10 ms etrunk41.milano50.mil.seabone.net [
7 9 ms 10 ms 11 ms ae10.milano58.mil.seabone.net [195.
8 * * * Richiesta scaduta.
9 * * * Richiesta scaduta.
10 30 ms 30 ms 30 ms ae-24-3612.ear2.London15.Level3.net
11 28 ms 28 ms 28 ms 195.50.120.99
12 29 ms 28 ms 28 ms ha01.multiplay.co.uk [85.236.96.26]
C:\Users\Admin>tracert aixit.com
Traccia instradamento verso aixit.com [82.149.224.98]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 4 ms 5 ms 172.17.105.101
4 7 ms 7 ms 7 ms 172.17.104.129
5 11 ms 11 ms 11 ms 172.19.241.228
6 * * * Richiesta scaduta.
7 10 ms 10 ms 10 ms ae21.milano51.mil.seabone.net [195.22.205.39]
8 11 ms 11 ms 11 ms deutsche-telekom.milano51.mil.seabone.net [195.22.192.177]
9 31 ms 30 ms 30 ms f-ee7-i.F.DE.NET.DTAG.DE [62.156.131.222]
10 30 ms 31 ms 95 ms 80.157.131.233
11 19 ms 21 ms 20 ms ae0-3002.er1.of.aixit.net [83.141.5.102]
12 19 ms 19 ms 19 ms www.aixit.com [82.149.224.98]
Traccia completata.
C:\Users\Admin>tracert hetzner.de
Traccia instradamento verso hetzner.de [213.133.107.227]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.105.97
4 8 ms 7 ms 7 ms 172.17.104.73
5 10 ms 11 ms 11 ms 172.19.241.228
6 * * 9 ms etrunk38.milano1.mil.seabone.net [195.22.192.108]
7 32 ms 9 ms 9 ms et7-1-0-50.milano51.mil.seabone.net [195.22.196.215]
8 9 ms 9 ms 9 ms ntt-verio.milano51.mil.seabone.net [93.186.128.157]
9 24 ms 24 ms 24 ms ae-11.r01.mlanit01.it.bb.gin.ntt.net [129.250.2.40]
10 21 ms 22 ms 23 ms ae-2.r24.frnkge08.de.bb.gin.ntt.net [129.250.3.183]
11 21 ms 21 ms 22 ms ae-13.r03.frnkge03.de.bb.gin.ntt.net [129.250.6.207]
12 21 ms 22 ms 21 ms 213.198.82.130
13 27 ms 28 ms 27 ms core11.nbg1.hetzner.com [213.239.245.249]
14 24 ms 36 ms 24 ms ex9k2.rz1.hetzner.de [213.239.203.214]
15 24 ms 24 ms 24 ms www.hetzner.de [213.133.107.227]
Traccia completata.
C:\Users\Admin>tracert 5.135.128.81
Traccia instradamento verso sbg.proof.ovh.net [5.135.128.81]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.105.225
4 5 ms 7 ms 7 ms 172.17.104.153
5 12 ms 11 ms 11 ms 172.19.241.228
6 * 9 ms 9 ms etrunk46.milano1.mil.seabone.net [195.22.196.68]
7 16 ms 15 ms 16 ms ae11.milano58.mil.seabone.net [195.22.208.79]
8 9 ms 9 ms 9 ms be100-152.mil-5-a9.it.eu [91.121.131.62]
9 * * * Richiesta scaduta.
10 * * * Richiesta scaduta.
11 18 ms 14 ms 16 ms be50-5.sbg-4b-a9.routeurs.fr.eu [188.165.9.74]
12 15 ms 15 ms 15 ms sbg.proof.ovh.net [5.135.128.81]
Traccia completata.
C:\Users\Admin>tracert xs4all.nl
Traccia instradamento verso xs4all.nl [194.109.6.93]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 4 ms 172.17.105.229
4 5 ms 7 ms 7 ms 172.17.104.145
5 10 ms 11 ms 11 ms 172.19.241.228
6 * * * Richiesta scaduta.
7 20 ms 20 ms 20 ms et5-1-0.franco31.fra.seabone.net [195.22.214.88]
8 17 ms 17 ms 17 ms ffm-s6-rou-1041.DE.eurorings.net [134.222.249.25]
9 21 ms 21 ms 20 ms ffm-s1-rou-1102.DE.eurorings.net [134.222.48.144]
10 23 ms 24 ms 23 ms asd2-rou-1043.NL.eurorings.net [134.222.48.176]
11 24 ms 24 ms 24 ms 134.222.93.145
12 24 ms 24 ms 23 ms xs4all.nl [194.109.6.93]
Traccia completata.
C:\Users\Admin>tracert proserve.nl
Traccia instradamento verso proserve.nl [83.96.141.5]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.104.164
4 8 ms 7 ms 7 ms 172.17.104.85
5 12 ms 11 ms 11 ms 172.19.241.228
6 * 10 ms 9 ms etrunk15.milano1.mil.seabone.net [93.186.128.217]
7 21 ms 20 ms 19 ms ae11.milano58.mil.seabone.net [195.22.208.79]
8 * * * Richiesta scaduta.
9 * * 25 ms ae-1-3.ear1.Amsterdam1.Level3.net [4.69.153.186]
10 25 ms 25 ms 25 ms IT-ERNITY-I.ear1.Amsterdam1.Level3.net [213.19.196.214]
11 25 ms 25 ms 27 ms be10-300.cr1.nkf.as49685.net [80.246.207.249]
12 25 ms 24 ms 24 ms www.proserve.nl [83.96.141.5]
Traccia completata.
C:\Users\Admin>tracert i3d.net
Traccia instradamento verso i3d.net [188.122.94.99]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 4 ms 172.17.105.225
4 5 ms 7 ms 7 ms 172.17.104.81
5 10 ms 11 ms 11 ms 172.19.241.226
6 10 ms 12 ms 10 ms etrunk47.milano50.mil.seabone.net [195.22.196.216]
7 9 ms 14 ms 11 ms et7-3-0-50.milano51.mil.seabone.net [195.22.196.191]
8 11 ms 10 ms 10 ms ntt-verio.milano51.mil.seabone.net [93.186.128.157]
9 35 ms 35 ms 34 ms ae-0.r24.amstnl02.nl.bb.gin.ntt.net [129.250.3.178]
10 35 ms 36 ms 35 ms ae-1.r02.amstnl02.nl.bb.gin.ntt.net [129.250.2.113]
11 38 ms 39 ms 38 ms xe-0-5-0-5.i3dnet.r02.amstnl02.nl.ce.gin.ntt.net [81.20.65.30]
12 34 ms 37 ms 38 ms 100ge.br2-cr1.smartdc.rtm.i3d.net [188.122.95.84]
13 31 ms 31 ms 31 ms www.i3d.net [188.122.94.99]
Traccia completata.
C:\Users\Admin>tracert surfnet.nl
Traccia instradamento verso surfnet.nl [192.87.108.15]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.105.97
4 7 ms 7 ms 7 ms 172.17.104.77
5 11 ms 11 ms 11 ms 172.19.241.226
6 10 ms * 11 ms etrunk47.milano50.mil.seabone.net [195.22.196.216]
7 11 ms 10 ms 10 ms et8-0-2-51.milano51.mil.seabone.net [195.22.205.89]
8 10 ms 10 ms 10 ms ae8.cr1-mil2.ip4.gtt.net [46.33.83.178]
9 25 ms 24 ms 24 ms xe-0-0-3.cr0-ams2.ip4.gtt.net [141.136.108.213]
10 24 ms 25 ms 25 ms surfnet-gw.ip4.gtt.net [77.67.76.34]
11 32 ms 32 ms 32 ms AE0.500.JNR01.Asd002A.surf.net [145.145.80.81]
12 34 ms 33 ms 33 ms snet-router.customer.surf.net [145.145.17.14]
13 33 ms 33 ms 32 ms revproxy20.surfnet.nl [192.87.108.15]
Traccia completata.
C:\Users\Admin>tracert intergenia.de
Traccia instradamento verso intergenia.de [85.25.0.17]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.105.101
4 7 ms 7 ms 7 ms 172.17.104.61
5 10 ms 11 ms 11 ms 172.19.241.228
6 * * * Richiesta scaduta.
7 18 ms 18 ms 17 ms et7-3-0-50.franco71.fra.seabone.net [195.22.196.29]
8 17 ms 18 ms 17 ms be3034.rcr22.fra06.atlas.cogentco.com [130.117.15.37]
9 20 ms 20 ms 21 ms be2846.ccr42.fra03.atlas.cogentco.com [154.54.37.29]
10 21 ms 21 ms 21 ms be2477.rcr21.sxb01.atlas.cogentco.com [130.117.49.33]
11 22 ms 22 ms 21 ms be2780.nr13.b015623-2.sxb01.atlas.cogentco.com [154.25.5.242]
12 22 ms 22 ms 22 ms 149.14.12.58
13 24 ms 24 ms 24 ms ae2.sxb1-rr-1-2-f1-3.sxb1.legacy [87.230.114.162]
14 21 ms 21 ms 21 ms static-ip-85-25-0-17.inaddr.ip-pool.com [85.25.0.17]
Traccia completata.
C:\Users\Admin>tracert coreix.net
Traccia instradamento verso coreix.net [85.13.193.200]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.104.166
4 7 ms 7 ms 7 ms 172.17.104.73
5 12 ms 11 ms 11 ms 172.19.241.228
6 9 ms 9 ms * etrunk34.milano1.mil.seabone.net [195.22.192.85]
7 23 ms 15 ms 19 ms ae11.milano58.mil.seabone.net [195.22.208.79]
8 * * * Richiesta scaduta.
9 * * * Richiesta scaduta.
10 30 ms 29 ms 29 ms unknown.Level3.net [212.187.139.11]
11 30 ms 30 ms 30 ms xe-5-1.edge3.enf.lon5.coreix.net [89.187.93.8]
12 31 ms 30 ms 30 ms 85.13.193.200.reverse.coreix.net [85.13.193.200]
Traccia completata.
C:\Users\Admin>tracert bbc.co.uk
Traccia instradamento verso bbc.co.uk [212.58.246.79]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 4 ms 4 ms 172.17.105.101
4 6 ms 7 ms 7 ms 172.17.104.125
5 12 ms 11 ms 11 ms 172.19.241.226
6 10 ms 13 ms 10 ms etrunk13.milano50.mil.seabone.net [93.186.128.237]
7 24 ms 14 ms 19 ms ae10.milano58.mil.seabone.net [195.22.208.117]
8 * * * Richiesta scaduta.
9 * * 30 ms ae-21-3509.ear2.London15.Level3.net [4.69.167.154]
10 * * * Richiesta scaduta.
11 29 ms 29 ms 29 ms NIU-SOLUTIO.ear1.London15.Level3.net [212.187.173.210]
12 * * * Richiesta scaduta.
13 * * * Richiesta scaduta.
14 30 ms 29 ms 30 ms ae0.er02.cwwtf.bbc.co.uk [132.185.254.90]
15 35 ms 35 ms 35 ms 132.185.255.165
16 31 ms 31 ms 31 ms 212.58.246.79
Traccia completata.
C:\Users\Admin>tracert sl.ru
Traccia instradamento verso sl.ru [91.218.10.36]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 4 ms 172.17.104.164
4 6 ms 7 ms 7 ms 172.17.104.98
5 12 ms 9 ms 12 ms 172.19.241.228
6 * 9 ms * etrunk35.milano1.mil.seabone.net [195.22.192.33]
7 20 ms 20 ms 24 ms et4-1-5-51.franco71.fra.seabone.net [195.22.205.109]
8 20 ms 20 ms 91 ms ojsc-vimpelcom.franco71.fra.seabone.net [89.221.34.143]
9 * * * Richiesta scaduta.
10 59 ms 59 ms 59 ms 81.211.83.226
11 56 ms 56 ms 57 ms 93.88.171.254
12 59 ms 59 ms 59 ms gw-mksnet.skaditel.ru [195.191.239.206]
13 60 ms 60 ms 60 ms host212-57-99-218.msk-ibb.mksnet.ru [212.57.99.218]
14 60 ms 59 ms 58 ms 91.218.11.2
15 62 ms 62 ms 62 ms 91.218.10.37
16 59 ms 59 ms 60 ms 91.218.10.36
Traccia completata.
C:\Users\Admin>tracert world.pl
Traccia instradamento verso world.pl [212.85.96.63]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.105.225
4 8 ms 7 ms 7 ms 172.17.104.149
5 12 ms 10 ms 11 ms 172.19.241.226
6 11 ms 10 ms * etrunk14.milano50.mil.seabone.net [93.186.128.241]
7 19 ms 19 ms 19 ms ae10.milano58.mil.seabone.net [195.22.208.117]
8 * * * Richiesta scaduta.
9 83 ms 44 ms 45 ms ae-1-9.bar1.Warsaw1.Level3.net [4.69.153.70]
10 44 ms 44 ms 45 ms LWLcom-Bremen.level3.net [213.242.117.58]
11 43 ms 45 ms 44 ms world.pl [212.85.96.63]
Traccia completata.
C:\Users\Admin>tracert login.uoforever.com
Traccia instradamento verso login.uoforever.com [74.91.119.69]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.104.166
4 5 ms 7 ms 7 ms 172.17.104.57
5 10 ms 11 ms 11 ms 172.19.241.226
6 * * * Richiesta scaduta.
7 18 ms 10 ms 10 ms et8-0-2-50.milano51.mil.seabone.net [195.22.205.53]
8 11 ms 10 ms 10 ms ae8.cr1-mil2.ip4.gtt.net [46.33.83.178]
9 144 ms 126 ms 127 ms xe-10-2-2.cr2-chi1.ip4.gtt.net [89.149.143.133]
10 129 ms 128 ms 128 ms gtt-3.e9.router1.chicago.nfoservers.com [74.91.115.254]
11 125 ms 125 ms 125 ms d-74-91-119-69.ded-machine.premium-chicago.nfoservers.com [74.91.119.69]
Traccia completata.
C:\Users\Admin>tracert www.gatel.de
Traccia instradamento verso www.gatel.de [38.100.128.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 4 ms 172.17.105.101
4 7 ms 7 ms 7 ms 172.17.104.129
5 9 ms 11 ms 11 ms 172.19.241.228
6 * * * Richiesta scaduta.
7 23 ms 21 ms 20 ms et5-1-0.franco31.fra.seabone.net [195.22.214.88]
8 18 ms 18 ms 18 ms be3005.ccr42.fra03.atlas.cogentco.com [130.117.14.77]
9 18 ms 18 ms 18 ms be2589.rcr21.b023657-1.fra03.atlas.cogentco.com [154.54.56.114]
10 18 ms 18 ms 17 ms cogentco.com [38.100.128.10]
Traccia completata.
C:\Users\Admin>tracert dedibox.fr
Traccia instradamento verso dedibox.fr [62.210.16.2]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 6 ms 4 ms 172.17.105.229
4 5 ms 7 ms 7 ms 172.17.104.145
5 9 ms 11 ms 11 ms 172.19.241.228
6 9 ms 9 ms 10 ms etrunk11.milano1.mil.seabone.net [93.186.128.201]
7 9 ms 9 ms 9 ms ae11.milano58.mil.seabone.net [195.22.208.79]
8 * * * Richiesta scaduta.
9 27 ms 25 ms 25 ms ae-1-3102.ear2.Paris1.Level3.net [4.69.140.30]
10 25 ms 25 ms 25 ms 212.3.235.202
11 24 ms 26 ms 25 ms 45x-s44-2-a9k1.dc3.poneytelecom.eu [195.154.1.105]
12 25 ms 25 ms 25 ms www.as12876.net [62.210.16.2]
Traccia completata.
C:\Users\Admin>tracert easo.ea.com
Traccia instradamento verso easo.ea.com [159.153.234.54]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.105.97
4 7 ms 7 ms 7 ms 172.17.104.125
5 12 ms 12 ms 11 ms 172.19.241.226
6 10 ms 12 ms 11 ms etrunk46.milano50.mil.seabone.net [195.22.196.182]
7 9 ms 10 ms 9 ms et8-0-5-51.milano51.mil.seabone.net [195.22.205.119]
8 10 ms 10 ms 10 ms ntt-verio.milano51.mil.seabone.net [93.186.128.157]
9 25 ms 24 ms 24 ms ae-11.r01.mlanit01.it.bb.gin.ntt.net [129.250.2.40]
10 22 ms 21 ms 21 ms ae-2.r24.frnkge08.de.bb.gin.ntt.net [129.250.3.183]
11 22 ms 22 ms 23 ms ae-1.r02.frnkge03.de.bb.gin.ntt.net [129.250.4.163]
12 22 ms 22 ms 22 ms 212.119.27.178
13 21 ms 21 ms 21 ms a72-52-48-202.deploy.static.akamaitechnologies.com [72.52.48.202]
14 22 ms 22 ms 28 ms a72-52-48-205.deploy.static.akamaitechnologies.com [72.52.48.205]
15 * * * Richiesta scaduta.
16 115 ms 113 ms 114 ms a209-200-168-132.deploy.static.akamaitechnologies.com [209.200.168.132]
17 111 ms 110 ms 110 ms 159.153.93.2
18 109 ms 108 ms 110 ms 159.153.225.69
19 109 ms 110 ms 109 ms 159.153.226.67
20 109 ms 108 ms 109 ms easo.ea.com [159.153.234.54]
Traccia completata.
C:\Users\Admin>tracert vispa.net
Traccia instradamento verso vispa.net [83.217.185.26]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.104.166
4 5 ms 7 ms 7 ms 172.17.104.137
5 10 ms 11 ms 11 ms 172.19.241.228
6 * * * Richiesta scaduta.
7 18 ms 19 ms 18 ms et7-3-0-51.franco71.fra.seabone.net [195.22.196.31]
8 19 ms 19 ms 19 ms be3034.rcr22.fra06.atlas.cogentco.com [130.117.15.37]
9 29 ms 29 ms 29 ms be2846.ccr42.fra03.atlas.cogentco.com [154.54.37.29]
10 36 ms 35 ms 36 ms be2814.ccr42.ams03.atlas.cogentco.com [130.117.0.141]
11 38 ms 38 ms 38 ms be2183.ccr22.lpl01.atlas.cogentco.com [154.54.58.69]
12 38 ms 38 ms 38 ms be2191.ccr21.man01.atlas.cogentco.com [130.117.49.50]
13 38 ms 39 ms 38 ms be2739.agr11.man01.atlas.cogentco.com [154.54.58.54]
14 38 ms 38 ms 38 ms te0-0-2-0.nr11.b025515-0.man01.atlas.cogentco.com [154.25.5.106]
15 38 ms 38 ms 38 ms vispa.demarc.cogentco.com [149.11.70.218]
16 38 ms 38 ms 38 ms billing.vispa.net.uk [83.217.185.26]
Traccia completata.
C:\Users\Admin>tracert telepac.pt
Traccia instradamento verso telepac.pt [213.13.145.45]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 5 ms 4 ms 172.17.105.101
4 5 ms 7 ms 7 ms 172.17.104.57
5 10 ms 11 ms 11 ms 172.19.241.226
6 10 ms * * etrunk15.milano50.mil.seabone.net [93.186.128.245]
7 10 ms 9 ms 9 ms et8-0-2-51.milano51.mil.seabone.net [195.22.205.89]
8 9 ms 9 ms 9 ms ae8.cr1-mil2.ip4.gtt.net [46.33.83.178]
9 24 ms 24 ms 25 ms et-2-0-2.cr1-fra6.ip4.gtt.net [141.136.110.233]
10 24 ms 23 ms 24 ms portugal-telecom-gw.ip4.gtt.net [77.67.74.2]
11 73 ms 71 ms 71 ms lis2-cr1-te8-0-1.cprm.net [195.8.0.233]
12 72 ms 71 ms 79 ms 195.8.21.78
13 70 ms 70 ms 70 ms lcat1.te1-1.telepac.net [213.13.135.174]
14 70 ms 70 ms 70 ms dial-b1-169-154.telepac.pt [194.65.169.154]
15 65 ms 65 ms 65 ms tags.sapo.pt [213.13.145.45]
16 65 ms 65 ms 65 ms tags.sapo.pt [213.13.145.45]
Traccia completata.
C:\Users\Admin>tracert 109.230.199.74
Traccia instradamento verso 109.230.199.74 su un massimo di 30 punti di passaggio
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 4 ms 4 ms 4 ms 172.17.104.164
4 8 ms 7 ms 7 ms 172.17.104.153
5 9 ms 11 ms 11 ms 172.19.241.228
6 * 9 ms 9 ms etrunk39.milano1.mil.seabone.net [195.22.192.178]
7 20 ms 20 ms 21 ms et10-1-0-50.franco32.fra.seabone.net [195.22.211.42]
8 20 ms 20 ms 20 ms ffm-b4-link.telia.net [62.115.149.0]
9 20 ms 21 ms 20 ms ffm-bb4-link.telia.net [62.115.118.201]
10 45 ms 44 ms 44 ms s-bb3-link.telia.net [62.115.112.93]
11 40 ms 39 ms 39 ms s-b5-link.telia.net [62.115.119.109]
12 41 ms 41 ms 40 ms portlane-ic-316382-s-b5.c.telia.net [62.115.145.11]
13 42 ms 42 ms 43 ms po1.pe1.sto1.se.portlane.net [80.67.4.193]
14 39 ms 39 ms 40 ms 109.230.199.74
Traccia completata.
Questi con Infostrada (sempre dalla stessa locazione):
C:\Users\Admin>tracert verygames.de
Traccia instradamento verso verygames.de [51.255.33.115]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 5 ms 151.7.32.120
4 6 ms 5 ms 6 ms 151.7.32.96
5 10 ms 10 ms 11 ms 151.6.2.5
6 49 ms 50 ms 50 ms 151.6.1.182
7 * * * Richiesta scaduta.
8 18 ms 18 ms 18 ms vl110.rbx-g2-a75.fr.eu [91.121.215.220]
9 24 ms 24 ms 24 ms be99-1258.gsw-1-a9.fr.eu [91.121.215.219]
10 * * * Richiesta scaduta.
11 * * * Richiesta scaduta.
12 27 ms 27 ms 28 ms be5.gra-z1g1-a75.fr.eu [37.187.232.75]
13 * * * Richiesta scaduta.
14 27 ms 27 ms 27 ms 51.255.244.236
15 26 ms 27 ms 27 ms 149.202.255.33
16 27 ms 26 ms 26 ms web-3.verygames.net [51.255.33.115]
Traccia completata.
C:\Users\Admin>tracert fshost.de
Traccia instradamento verso fshost.de [212.224.93.2]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * 6 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.116
4 5 ms 5 ms 6 ms 151.7.32.70
5 10 ms 10 ms 10 ms 151.6.2.5
6 22 ms 22 ms 22 ms 151.6.1.90
7 53 ms 52 ms 52 ms 151.6.5.250
8 41 ms 41 ms 41 ms ae1.cr02.fra1.de.first-colo.net [80.81.194.3]
9 45 ms 44 ms 49 ms cr03.fra1.de.first-colo.net [212.224.102.133]
10 39 ms 40 ms 40 ms 212.224.93.2
Traccia completata.
C:\Users\Admin>tracert multiplay.co.uk
Traccia instradamento verso multiplay.co.uk [85.236.96.26]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 5 ms * * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.116
4 5 ms 5 ms 5 ms 151.7.32.70
5 41 ms 10 ms 17 ms 151.6.0.91
6 10 ms 10 ms 10 ms 151.6.1.229
7 10 ms 10 ms 11 ms 7-1-1.bear1.Milan2.Level3.net [213.242.65.217]
8 * * * Richiesta scaduta.
9 * * * Richiesta scaduta.
10 30 ms 30 ms 30 ms 195.50.120.99
11 29 ms 29 ms 28 ms ha01.multiplay.co.uk [85.236.96.26]
Traccia completata.
C:\Users\Admin>tracert aixit.com
Traccia instradamento verso aixit.com [82.149.224.98]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 5 ms 151.7.32.116
4 5 ms 5 ms 5 ms 151.7.32.70
5 10 ms 10 ms 10 ms 151.6.0.91
6 11 ms 10 ms 10 ms 151.6.1.229
7 19 ms 19 ms 19 ms 10GE-7-1.DECIX1.FRA.IAG.EU [80.81.194.46]
8 19 ms 19 ms 19 ms decix.cr1.of.aixit.net [83.141.0.253]
9 19 ms 19 ms 43 ms ae0-3002.er1.of.aixit.net [83.141.5.102]
10 20 ms 19 ms 19 ms www.aixit.com [82.149.224.98]
Traccia completata.
C:\Users\Admin>tracert hetzner.de
Traccia instradamento verso hetzner.de [213.133.107.227]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * 6 ms * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.120
4 5 ms 5 ms 6 ms 151.7.32.92
5 11 ms 11 ms 11 ms 151.6.2.76
6 12 ms 12 ms 12 ms 151.6.1.239
7 20 ms 19 ms 20 ms decix-gw.hetzner.de [80.81.192.164]
8 23 ms 23 ms 23 ms core11.nbg1.hetzner.com [213.239.245.249]
9 23 ms 23 ms 23 ms ex9k2.rz1.hetzner.de [213.239.203.214]
10 25 ms 25 ms 25 ms www.hetzner.de [213.133.107.227]
Traccia completata.
C:\Users\Admin>tracert 5.135.128.81
Traccia instradamento verso sbg.proof.ovh.net [5.135.128.81]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * 6 ms 5 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.118
4 5 ms 5 ms 5 ms 151.7.32.90
5 11 ms 11 ms 11 ms 151.6.2.76
6 51 ms 50 ms 50 ms 151.6.1.176
7 * * * Richiesta scaduta.
8 * * * Richiesta scaduta.
9 * * * Richiesta scaduta.
10 17 ms 18 ms 17 ms be50-5.sbg-4a-a9.routeurs.fr.eu [188.165.9.70]
11 17 ms 17 ms 17 ms sbg.proof.ovh.net [5.135.128.81]
Traccia completata.
C:\Users\Admin>tracert xs4all.nl
Traccia instradamento verso xs4all.nl [194.109.6.93]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * 5 ms * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.118
4 5 ms 5 ms 5 ms 151.7.32.74
5 11 ms 10 ms 11 ms 151.6.5.190
6 26 ms 22 ms 23 ms 151.6.0.105
7 21 ms 21 ms 26 ms 151.6.1.250
8 51 ms 51 ms 51 ms ams-ix.sara.xs4all.net [80.249.208.48]
9 50 ms 50 ms 50 ms 0.ae4.xr3.3d12.xs4all.net [194.109.5.5]
10 50 ms 51 ms 51 ms xs4all.nl [194.109.6.93]
Traccia completata.
C:\Users\Admin>tracert proserve.nl
Traccia instradamento verso proserve.nl [83.96.141.5]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 7 ms * 5 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.118
4 5 ms 5 ms 5 ms 151.7.32.94
5 11 ms 10 ms 10 ms 151.6.0.91
6 11 ms 11 ms 11 ms 151.6.1.233
7 27 ms 27 ms 27 ms 80.249.211.217
8 28 ms 27 ms 29 ms te0-14.cr1.gls.as49685.net [95.142.106.131]
9 27 ms 26 ms 27 ms be10-300.cr1.nkf.as49685.net [80.246.207.249]
10 26 ms 26 ms 26 ms www.proserve.nl [83.96.141.5]
Traccia completata.
C:\Users\Admin>tracert i3d.net
Traccia instradamento verso i3d.net [188.122.94.99]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * 5 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.120
4 5 ms 5 ms 5 ms 151.7.32.96
5 10 ms 11 ms 10 ms 151.6.2.5
6 12 ms 12 ms 12 ms 151.6.1.233
7 33 ms 33 ms 35 ms 20ge.linx-jnpr.th-n.i3d.net [195.66.225.146]
8 34 ms 34 ms 34 ms 30ge.cr1-lr0.smartdc.rtm.i3d.net [109.200.218.173]
9 33 ms 33 ms 33 ms 100ge.br2-cr1.smartdc.rtm.i3d.net [188.122.95.84]
10 33 ms 33 ms 32 ms www.i3d.net [188.122.94.99]
Traccia completata.
C:\Users\Admin>tracert surfnet.nl
Traccia instradamento verso surfnet.nl [145.100.190.243]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 5 ms * * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.120
4 7 ms 6 ms 6 ms 151.7.32.92
5 11 ms 11 ms 11 ms 151.6.2.76
6 11 ms 11 ms 10 ms 151.6.1.237
7 33 ms 33 ms 33 ms 195.66.225.24
8 35 ms 35 ms 34 ms something.surf.net [109.105.98.110]
9 33 ms 33 ms 33 ms snetlan-nikhef.customer.surf.net [145.145.19.218]
10 92 ms 35 ms 35 ms 145.97.20.249
11 35 ms 35 ms 35 ms surf.nl [145.100.190.243]
Traccia completata.
C:\Users\Admin>tracert intergenia.de
Traccia instradamento verso intergenia.de [85.25.0.17]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 5 ms 151.7.32.118
4 5 ms 4 ms 5 ms 151.7.32.16
5 10 ms 10 ms 10 ms 151.6.0.91
6 19 ms 20 ms 19 ms 151.6.1.86
7 39 ms 38 ms 39 ms 151.6.4.64
8 29 ms 29 ms 29 ms et-7-0-0.cr-polaris.fra1.core.heg.com [80.81.192.239]
9 33 ms 32 ms 32 ms ae1.cr-vega.sxb1.core.heg.com [87.230.114.9]
10 35 ms 34 ms 33 ms ae2.sxb1-rr-1-2-f1-3.sxb1.legacy [87.230.114.162]
11 32 ms 32 ms 32 ms static-ip-85-25-0-17.inaddr.ip-pool.com [85.25.0.17]
Traccia completata.
C:\Users\Admin>tracert coreix.net
Traccia instradamento verso coreix.net [85.13.193.200]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 7 ms 6 ms 5 ms 151.7.32.122
4 5 ms 5 ms 6 ms 151.7.32.76
5 11 ms 11 ms 10 ms 151.6.2.76
6 12 ms 11 ms 34 ms 151.6.1.235
7 31 ms 31 ms 31 ms ge-0-1-0-68.peering1.the.lon1.coreix.net [195.66.225.58]
8 32 ms 32 ms 32 ms xe-6-1.edge4.enf.lon5.coreix.net [89.187.93.137]
9 33 ms 33 ms 32 ms 85.13.193.200.reverse.coreix.net [85.13.193.200]
Traccia completata.
C:\Users\Admin>tracert bbc.co.uk
Traccia instradamento verso bbc.co.uk [212.58.246.79]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * 7 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.120
4 5 ms 5 ms 5 ms 151.7.32.96
5 11 ms 11 ms 13 ms 151.6.2.5
6 10 ms 12 ms 10 ms 151.6.1.231
7 32 ms 31 ms 31 ms bbc-linx.pr01.thdow.bbc.co.uk [195.66.224.103]
8 * * * Richiesta scaduta.
9 32 ms 32 ms 32 ms ae0.er02.cwwtf.bbc.co.uk [132.185.254.90]
10 34 ms 34 ms 34 ms 132.185.255.165
11 32 ms 32 ms 32 ms 212.58.246.79
Traccia completata.
C:\Users\Admin>tracert sl.ru
Traccia instradamento verso sl.ru [91.218.10.36]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * 6 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.122
4 5 ms 5 ms 5 ms 151.7.32.72
5 11 ms 12 ms 10 ms 151.6.0.91
6 10 ms 11 ms 10 ms 151.6.1.229
7 26 ms 27 ms 27 ms ams-ix-gw.gblnet.ru [80.249.209.157]
8 89 ms 93 ms 85 ms b57-a9k6-be1-806.gblnet.ru [94.124.182.41]
9 78 ms 79 ms 79 ms m9-a9k6-be4-849.gblnet.ru [94.124.181.134]
10 78 ms 78 ms 78 ms okb-telecom-gw.gblnet.ru [109.239.134.18]
11 92 ms 93 ms 92 ms host212-57-99-218.msk-ibb.mksnet.ru [212.57.99.218]
12 81 ms 82 ms 82 ms 91.218.11.2
13 79 ms 81 ms 79 ms 91.218.10.37
14 91 ms 92 ms 91 ms 91.218.10.36
Traccia completata.
C:\Users\Admin>tracert world.pl
Traccia instradamento verso world.pl [212.85.96.63]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.120
4 6 ms 6 ms 8 ms 151.7.32.92
5 28 ms 14 ms 11 ms 151.6.2.76
6 11 ms 11 ms 11 ms 151.6.1.237
7 19 ms 19 ms 20 ms fra-decix1.gtsce.net [80.81.192.81]
8 50 ms 50 ms 51 ms taro-dbp1-so-0-0-1-0.net.ipartners.pl [157.25.3.246]
9 50 ms 50 ms 50 ms taro-dbp1-so-0-0-1-0.net.ipartners.pl [157.25.3.246]
10 * * * Richiesta scaduta.
11 37 ms 37 ms 37 ms world.pl [212.85.96.63]
Traccia completata.
C:\Users\Admin>tracert login.uoforever.com
Traccia instradamento verso login.uoforever.com [74.91.119.69]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * 6 ms * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.118
4 5 ms 5 ms 5 ms 151.7.32.90
5 11 ms 11 ms 21 ms 151.6.2.76
6 49 ms 50 ms 50 ms 151.6.1.176
7 51 ms 50 ms 50 ms et-1-1-0-xcr1.mlu.cw.net [195.2.10.133]
8 50 ms 49 ms 49 ms mno-b2-link.telia.net [213.248.92.125]
9 123 ms 90 ms 124 ms prs-bb2-link.telia.net [62.115.115.30]
10 141 ms 137 ms 136 ms nyk-bb4-link.telia.net [62.115.124.150]
11 161 ms 160 ms 162 ms chi-b22-link.telia.net [62.115.118.151]
12 121 ms 121 ms 121 ms telia-1.e8.router1.chicago.nfoservers.com [74.91.113.254]
13 124 ms 125 ms 124 ms d-74-91-119-69.ded-machine.premium-chicago.nfoservers.com [74.91.119.69]
Traccia completata.
C:\Users\Admin>tracert www.gatel.de
Traccia instradamento verso www.gatel.de [38.100.128.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * 6 ms * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.116
4 6 ms 5 ms 6 ms 151.7.32.12
5 12 ms 11 ms 11 ms 151.6.5.190
6 51 ms 51 ms 51 ms 151.6.1.176
7 51 ms 51 ms 50 ms et-1-1-0-xcr1.mlu.cw.net [195.2.10.133]
8 50 ms 52 ms 51 ms as174-gw-mlu.cw.net [195.2.19.98]
9 55 ms 55 ms 54 ms be2043.ccr21.zrh01.atlas.cogentco.com [154.54.38.101]
10 67 ms 64 ms 64 ms be3072.ccr21.muc03.atlas.cogentco.com [130.117.0.18]
11 66 ms 68 ms 67 ms be2959.ccr41.fra03.atlas.cogentco.com [154.54.36.53]
12 65 ms 66 ms 67 ms be2588.rcr21.b023657-1.fra03.atlas.cogentco.com [154.54.56.86]
13 66 ms 66 ms 65 ms cogentco.com [38.100.128.10]
Traccia completata.
C:\Users\Admin>tracert dedibox.fr
Traccia instradamento verso dedibox.fr [62.210.16.2]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * * 151.7.198.72
3 5 ms 5 ms 9 ms 151.7.32.116
4 6 ms 6 ms 5 ms 151.7.32.12
5 16 ms 11 ms 14 ms 151.6.5.190
6 12 ms 12 ms 12 ms 151.6.1.239
7 28 ms 27 ms 27 ms 80.249.212.93
8 41 ms 42 ms 41 ms bb1-ams1-bb2.dc3.poneytelecom.eu [195.154.1.221]
9 40 ms 40 ms 41 ms 195.154.1.151
10 39 ms 39 ms 39 ms www.as12876.net [62.210.16.2]
Traccia completata.
Traccia instradamento verso easo.ea.com [159.153.234.54]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * 6 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.116
4 5 ms 5 ms 5 ms 151.7.32.94
5 10 ms 11 ms 11 ms 151.6.2.5
6 10 ms 10 ms 10 ms 151.6.1.229
7 33 ms 32 ms 32 ms akamai.prolexic.com [195.66.224.31]
8 34 ms 34 ms 34 ms a72-52-60-200.deploy.static.akamaitechnologies.com [72.52.60.200]
9 35 ms 35 ms 35 ms a72-52-60-205.deploy.static.akamaitechnologies.com [72.52.60.205]
10 151 ms 154 ms 152 ms 93.191.173.11
11 115 ms 114 ms 114 ms a209-200-168-132.deploy.static.akamaitechnologies.com [209.200.168.132]
12 112 ms 112 ms 112 ms 159.153.93.2
13 112 ms 112 ms 112 ms 159.153.225.69
14 113 ms 114 ms 114 ms 159.153.226.67
15 112 ms 112 ms 113 ms easo.ea.com [159.153.234.54]
Traccia completata.
C:\Users\Admin>tracert vispa.net
Traccia instradamento verso vispa.net [83.217.185.26]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * 6 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.118
4 6 ms 5 ms 5 ms 151.7.32.16
5 12 ms 17 ms 12 ms 151.6.2.5
6 52 ms 52 ms 50 ms 151.6.1.182
7 52 ms 51 ms 49 ms et-1-1-0-xcr1.mlu.cw.net [195.2.10.133]
8 48 ms 49 ms 51 ms as174-gw-mlu.cw.net [195.2.19.98]
9 68 ms 71 ms 71 ms be2314.ccr21.mrs01.atlas.cogentco.com [130.117.50.93]
10 69 ms 67 ms 67 ms be3092.ccr41.par01.atlas.cogentco.com [130.117.49.153]
11 34 ms 33 ms 33 ms be12497.ccr41.lon13.atlas.cogentco.com [154.54.56.129]
12 42 ms 42 ms 41 ms be2111.ccr21.man01.atlas.cogentco.com [130.117.50.74]
13 40 ms 40 ms 40 ms be2740.agr12.man01.atlas.cogentco.com [154.54.58.58]
14 40 ms 43 ms 40 ms te0-0-2-2.nr11.b025515-0.man01.atlas.cogentco.com [154.25.5.110]
15 40 ms 40 ms 40 ms vispa.demarc.cogentco.com [149.11.70.218]
16 39 ms 39 ms 39 ms billing.vispa.net.uk [83.217.185.26]
Traccia completata.
C:\Users\Admin>tracert telepac.pt
Traccia instradamento verso telepac.pt [213.13.145.45]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * 6 ms 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.116
4 11 ms 5 ms 5 ms 151.7.32.74
5 11 ms 11 ms 10 ms 151.6.5.190
6 12 ms 11 ms 11 ms 151.6.1.237
7 45 ms 47 ms 47 ms london1-cr1-f50.cprm.net [195.66.224.91]
8 72 ms 75 ms 75 ms lis1-cr1-be4.cprm.net [195.8.1.45]
9 77 ms 75 ms 75 ms 195.8.21.74
10 75 ms 76 ms 75 ms 213.13.135.150
11 72 ms 72 ms 71 ms dial-b1-169-190.telepac.pt [194.65.169.190]
12 78 ms 77 ms 78 ms tags.sapo.pt [213.13.145.45]
13 77 ms 78 ms 78 ms tags.sapo.pt [213.13.145.45]
Traccia completata.
C:\Users\Admin>tracert 109.230.199.74
Traccia instradamento verso 109.230.199.74 su un massimo di 30 punti di passaggio
1 <1 ms <1 ms <1 ms 192.168.1.1
2 6 ms * 6 ms 151.7.198.72
3 6 ms 5 ms 5 ms 151.7.32.118
4 6 ms 5 ms 5 ms 151.7.32.70
5 10 ms 10 ms 15 ms 151.6.0.91
6 11 ms 11 ms 12 ms 151.6.1.231
7 19 ms 19 ms 19 ms decix.fra1.de.portlane.net [80.81.194.215]
8 43 ms 43 ms 43 ms be1-521-80g.cr1.sto1.se.portlane.net [80.67.4.190]
9 45 ms 44 ms 45 ms po1.pe1.sto1.se.portlane.net [80.67.4.193]
10 44 ms 44 ms 43 ms 109.230.199.74
Traccia completata.
Traceroute fatti alla stessa ora con entrambe (intorno alle 22:00 orario abbastanza di punta) e con lo stesso IP.
In definitiva abbiamo TIM che pinga meno su questi server:
fshost - 10ms meno
xs4all - 25ms meno
intergenia - 10ms meno
sl.ru - 30ms meno - diminuito di 20ms verso mezzanotte
dedibox.fr - 10ms meno
gatel.de - 45ms meno - diminuito di 35ms verso mezzanotte
telepac -10ms meno
Mentre su world.pl pinga meglio Infostrada di 5\10ms.
Ho cambiato un pò di IP con Infostrada (4\5) ma non sono riuscito ad eguagliare TIM su nessuno di quei server segnati sopra (prima di mezzanotte).
Poi mi è cascato l'occhio...ore 22:10 con Infostrada (anche cambiando IP della connessione la situazione rimane invariata): :doh:
C:\Users\Admin>tracert www.gamesnet.it
Traccia instradamento verso www.gamesnet.it [195.36.6.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 5 ms 5 ms 5 ms 151.7.32.116
4 5 ms 5 ms 5 ms 151.7.32.74
5 10 ms 11 ms 12 ms 151.6.2.76
6 50 ms 50 ms 50 ms 151.6.1.176
7 11 ms 10 ms 11 ms telnet.mix-it.net [217.29.66.5]
8 49 ms 49 ms 49 ms www.gamesnet.it [195.36.6.10]
Traccia completata.
C:\Users\Admin>tping www.gamesnet.it
Pinging www.gamesnet.it [195.36.6.10] with 32 bytes of data from [192.168.1.13]:
Reply from 195.36.6.10: bytes=32 time 51.01 ms, TTL=57, Hop=7, Jitter=0.00 ms
Reply from 195.36.6.10: bytes=32 time 50.29 ms, TTL=57, Hop=7, Jitter=0.04 ms
Reply from 195.36.6.10: bytes=32 time 52.05 ms, TTL=57, Hop=7, Jitter=0.15 ms
Reply from 195.36.6.10: bytes=32 time 51.14 ms, TTL=57, Hop=7, Jitter=0.20 ms
Reply from 195.36.6.10: bytes=32 time 52.02 ms, TTL=57, Hop=7, Jitter=0.24 ms
Ping statistics for 195.36.6.10
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 50.29ms, Maximum = 52.05ms, Average = 51.30ms, Jitter Statistical = 0.74ms
Ore 23:55, adesso la latenza si è normalizzata: :rolleyes:
C:\Users\Admin>tracert www.gamesnet.it
Traccia instradamento verso www.gamesnet.it [195.36.6.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * 6 ms * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.118
4 5 ms 5 ms 5 ms 151.7.32.94
5 10 ms 10 ms 10 ms 151.6.0.91
6 11 ms 10 ms 10 ms 151.6.1.182
7 12 ms 10 ms 10 ms telnet.mix-it.net [217.29.66.5]
8 10 ms 11 ms 10 ms www.gamesnet.it [195.36.6.10]
Traccia completata.
C:\Users\Admin>tping www.gamesnet.it
Pinging www.gamesnet.it [195.36.6.10] with 32 bytes of data from [192.168.1.13]:
Reply from 195.36.6.10: bytes=32 time 11.05 ms, TTL=57, Hop=7, Jitter=0.00 ms
Reply from 195.36.6.10: bytes=32 time 11.36 ms, TTL=57, Hop=7, Jitter=0.02 ms
Reply from 195.36.6.10: bytes=32 time 11.30 ms, TTL=57, Hop=7, Jitter=0.02 ms
Reply from 195.36.6.10: bytes=32 time 10.97 ms, TTL=57, Hop=7, Jitter=0.04 ms
Reply from 195.36.6.10: bytes=32 time 11.41 ms, TTL=57, Hop=7, Jitter=0.07 ms
Ping statistics for 195.36.6.10
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10.97ms, Maximum = 11.41ms, Average = 11.22ms, Jitter Statistical = 0.20ms
Anche gatel.de a quest'ora è diminuito da 65ms a 27ms e come ho scritto sopra anche sl.ru è sceso un pò anche se TIM rimane più bassa :stordita:
C:\Users\Admin>tracert www.gatel.de
Traccia instradamento verso www.gatel.de [38.100.128.10]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 7 ms * * 151.7.198.72
3 5 ms 5 ms 5 ms 151.7.32.118
4 5 ms 6 ms 5 ms 151.7.32.74
5 12 ms 11 ms 11 ms 151.6.5.190
6 12 ms 12 ms 12 ms 151.6.1.176
7 11 ms 11 ms 10 ms et-1-1-0-xcr1.mlu.cw.net [195.2.10.133]
8 13 ms 12 ms 13 ms as174-gw-mlu.cw.net [195.2.19.98]
9 17 ms 17 ms 19 ms be2043.ccr21.zrh01.atlas.cogentco.com [154.54.38.101]
10 27 ms 28 ms 27 ms be3073.ccr22.muc03.atlas.cogentco.com [130.117.0.62]
11 26 ms 25 ms 26 ms be2960.ccr42.fra03.atlas.cogentco.com [154.54.36.253]
12 28 ms 29 ms 28 ms be2589.rcr21.b023657-1.fra03.atlas.cogentco.com [154.54.56.114]
13 27 ms 28 ms 27 ms cogentco.com [38.100.128.10]
Traccia completata.
Magari li faccio anche con Tiscali domani sempre verso le 22:00 per parcondicio. =)
Ieri sera c'era qualche problema su Milano in effetti. Oltre a gamesnet/telnet era aumentata la latenza anche su verygames, sempre a a partire da un nodo milanese.
EDIT
Adesso tutto normale
Esecuzione di Ping gamesnet.it [195.36.6.10] con 32 byte di dati:
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=9ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Risposta da 195.36.6.10: byte=32 durata=10ms TTL=57
Statistiche Ping per 195.36.6.10:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 9ms, Massimo = 10ms, Medio = 9ms
Esecuzione di Ping verygames.net [94.23.214.174] con 32 byte di dati:
Risposta da 94.23.214.174: byte=32 durata=26ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=26ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=25ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=25ms TTL=51
Statistiche Ping per 94.23.214.174:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 25ms, Massimo = 26ms, Medio = 25ms
vediamo stasera.
riccardi.fede
28-08-2017, 08:20
verygames.net (data center OVH, Roubaix, FR)
multiplay.co.uk
i3d.net (interactive3D, NL).
Ottimo, grazie. Allora aggiungiamo anche alla lista questi :)
Ottima analisi MiloZ!
riccardi.fede
28-08-2017, 12:37
Aggiornato. Grazie!
Bologna FTTH Wind 500mbps(dovrebbe diventare 1gbps)
216.58.205.67 ---> 16ms
172.217.22.35 ---> 24ms
216.58.198.163 ---> 25ms
172.217.12.196 ---> 106ms
216.58.200.4 ---> 293ms
Test effettuato con DNS standard e non google
@ Fede
L'unico dato di Infostrada che abbiamo su Bologna è questo, che è di una 500 (non 1000, non so se possa cambiare qualcosa) riportata senza allegare ping/tracert integrali, dunque non so quanto Infostrada possa per ora essere considerata nei vari confronti (cioè, mi ricollego al discorso dell'altro giorno sul ping di Infostrada che non ti sembrava migliore degli altri, non so se ricordi, mi è venuto in mente ora perché sto andando a cercare gli utenti che avevano già postato).
PS:
L'utente in oggetto non si logga dal 30/7, e dubito che sia l'unico a non essere tra gli assidui, dunque servirà un po' di pazienza (a proposito, i pm dopo un tot di tempo se non vengono letti, restano comunque?).
PS 2:
Prima di continuare con l'invio dei pm, facciamo la lista chiara e certa dei server, compresi quelli gaming, per non dover ricontattare tutti dopo? Meglio preparare la cosa con qualche spesa di tempo in più, ma farla bene, che dover ogni volta rendersi conto che non abbiamo dati completi. Altra cosa, seppur il livello dell'utenza sia molto alto, forse potrà tornare utile dare indicazioni sul metodo di test (dal fatto di essere cablati e quindi mai in WiFi, piuttosto che un eventuale script dedicato come postato recentemente da un volenterosissimo utente, ecc.) :)
@ Fede
L'unico dato di Infostrada che abbiamo è questo, è di una 500 (non 1000, non so se possa cambiare qualcosa) riportata senza allegare ping/tracert integrali, dunque non so quanto Infostrada possa per ora essere considerata nei confronti (cioè, mi ricollego al discorso dell'altro giorno sul ping di Infostrada che non ti sembrava migliore degli altri, non so se ricordi).
In realtà è una 1000, inizialmente attivata a 500. Da contratto, tutti, hanno che entro settembre saranno "liberati" a 1000.
Di fatto già tutti (o quasi) andiamo a 1000, ma di sicuro è una rete in fase di sviluppo e testing. Forse non sono arrivati preparati o stanno ancora studiando la situazione... spero solo si sbrighino a finire i lavori.
Inoltre ancora tutti (almeno credo) siamo bloccati a 100Mbps in upload, invece dei 200Mbps contrattuali.
Penso che possa influire più questo nella situazione Wind che il download, non che il ping sia superiore a causa di poca banda, ma che sia indice che la rete non sia ancora uscite dalla fase di "beta testing" (stile Google/Gmail con anni di "beta")
Hermann1871
28-08-2017, 17:34
Catania
TIM FTTH 1000/100
216.58.205.67 - Google Milano
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Ping statistics for 216.58.205.67:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 24ms, Average = 24ms
172.217.22.35 - Google Francoforte
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=37ms TTL=53
Reply from 172.217.22.35: bytes=32 time=37ms TTL=53
Reply from 172.217.22.35: bytes=32 time=36ms TTL=53
Reply from 172.217.22.35: bytes=32 time=37ms TTL=53
Ping statistics for 172.217.22.35:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 36ms, Maximum = 37ms, Average = 36ms
216.58.198.163 - Google Londra
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Ping statistics for 216.58.198.163:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 47ms, Maximum = 47ms, Average = 47ms
172.217.12.196 - Google Chicago
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Ping statistics for 172.217.12.196:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 125ms, Maximum = 125ms, Average = 125ms
216.58.200.4 - Google Hong Kong
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=320ms TTL=48
Reply from 216.58.200.4: bytes=32 time=320ms TTL=48
Reply from 216.58.200.4: bytes=32 time=320ms TTL=48
Reply from 216.58.200.4: bytes=32 time=319ms TTL=48
Ping statistics for 216.58.200.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 319ms, Maximum = 320ms, Average = 319ms
verygames.net - Data center OVH, Roubaix, FR
Pinging verygames.net [94.23.214.174] with 32 bytes of data:
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Ping statistics for 94.23.214.174:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 38ms, Maximum = 38ms, Average = 38ms
multiplay.co.uk
Pinging multiplay.co.uk [85.236.96.26] with 32 bytes of data:
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Ping statistics for 85.236.96.26:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 43ms, Maximum = 43ms, Average = 43ms
i3d.net - interactive3D, NL
Pinging i3d.net [188.122.94.99] with 32 bytes of data:
Reply from 188.122.94.99: bytes=32 time=50ms TTL=52
Reply from 188.122.94.99: bytes=32 time=50ms TTL=52
Reply from 188.122.94.99: bytes=32 time=51ms TTL=52
Reply from 188.122.94.99: bytes=32 time=51ms TTL=52
Ping statistics for 188.122.94.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 50ms, Maximum = 51ms, Average = 50ms
192.168.100.1 BRAS TIM
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=3ms TTL=254
Reply from 192.168.100.1: bytes=32 time=2ms TTL=254
Reply from 192.168.100.1: bytes=32 time=3ms TTL=254
Reply from 192.168.100.1: bytes=32 time=2ms TTL=254
Ping statistics for 192.168.100.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 3ms, Average = 2ms
Approfitto per chiedervi una spiegazione di alcune cose che non mi tornano.
Vorrei capire come è possibile che alcuni hostname di server speedtest TIM puntino tutti allo stesso IP.
Ad esempio
speedtestfi1.telecomitalia.it
speedtestpe1.telecomitalia.it
speedtestpg1.telecomitalia.it
speedtestrm1.telecomitalia.it
puntano tutti a 151.99.108.126.
Ovviamente, ai fini della misura del ping, non avrebbe senso fingere che un server si trovi in una città e non in quella dove realmente si trova.
L'anycast potrebbe essere una spiegazione? Ho capito che viene usato per i server DNS. Ad esempio, il DNS Google ha indirizzo 8.8.8.8 però non corrisponde ad un unico server fisico ma a più server distribuiti nei vari stati altrimenti la latenza sarebbe troppo alta e questo è ottenuto proprio tramite l'anycast.
Un meccanismo del genere potrebbe funzionare anche coi server TIM? Ad esempio, se sono a Roma 151.99.108.126 corrisponde ad un server a Roma mentre se sono a Firenze corrisponde ad un server a Firenze?
Come faccio a capire quale server viene effettivamente contattato? Vorrei capire se contatto 8.8.8.8 negli USA o in Italia, ad esempio.
Viceversa se volessi contattare 8.8.8.8 negli USA come potrei forzare la scelta di quel server. Static route?
In realtà è una 1000, inizialmente attivata a 500. Da contratto, tutti, hanno che entro settembre saranno "liberati" a 1000.
Ok grazie :)
Inoltre ancora tutti (almeno credo) siamo bloccati a 100Mbps in upload, invece dei 200Mbps contrattuali.
Si anche MisterFTTH me l'aveva scritto riguardo alla connessione dei suoi.
Penso che possa influire più questo nella situazione Wind che il download, non che il ping sia superiore a causa di poca banda, ma che sia indice che la rete non sia ancora uscite dalla fase di "beta testing" (stile Google/Gmail con anni di "beta")
Il ping e la banda non hanno nesso, premesso questo, con Psyred abbiamo fatto test specifici e tutto risulta meno che Infotrada abbia ping peggiore! Mi dava 30 ms di scarto con la mia TIM sui server gaming (confronto tra FTTC)!
Catania
TIM FTTH 1000/100
216.58.205.67 - Google Milano
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Reply from 216.58.205.67: bytes=32 time=24ms TTL=54
Ping statistics for 216.58.205.67:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 24ms, Average = 24ms
172.217.22.35 - Google Francoforte
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=37ms TTL=53
Reply from 172.217.22.35: bytes=32 time=37ms TTL=53
Reply from 172.217.22.35: bytes=32 time=36ms TTL=53
Reply from 172.217.22.35: bytes=32 time=37ms TTL=53
Ping statistics for 172.217.22.35:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 36ms, Maximum = 37ms, Average = 36ms
216.58.198.163 - Google Londra
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Reply from 216.58.198.163: bytes=32 time=47ms TTL=49
Ping statistics for 216.58.198.163:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 47ms, Maximum = 47ms, Average = 47ms
172.217.12.196 - Google Chicago
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Reply from 172.217.12.196: bytes=32 time=125ms TTL=50
Ping statistics for 172.217.12.196:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 125ms, Maximum = 125ms, Average = 125ms
216.58.200.4 - Google Hong Kong
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=320ms TTL=48
Reply from 216.58.200.4: bytes=32 time=320ms TTL=48
Reply from 216.58.200.4: bytes=32 time=320ms TTL=48
Reply from 216.58.200.4: bytes=32 time=319ms TTL=48
Ping statistics for 216.58.200.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 319ms, Maximum = 320ms, Average = 319ms
verygames.net - Data center OVH, Roubaix, FR
Pinging verygames.net [94.23.214.174] with 32 bytes of data:
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Reply from 94.23.214.174: bytes=32 time=38ms TTL=50
Ping statistics for 94.23.214.174:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 38ms, Maximum = 38ms, Average = 38ms
multiplay.co.uk
Pinging multiplay.co.uk [85.236.96.26] with 32 bytes of data:
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Reply from 85.236.96.26: bytes=32 time=43ms TTL=50
Ping statistics for 85.236.96.26:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 43ms, Maximum = 43ms, Average = 43ms
i3d.net - interactive3D, NL
Pinging i3d.net [188.122.94.99] with 32 bytes of data:
Reply from 188.122.94.99: bytes=32 time=50ms TTL=52
Reply from 188.122.94.99: bytes=32 time=50ms TTL=52
Reply from 188.122.94.99: bytes=32 time=51ms TTL=52
Reply from 188.122.94.99: bytes=32 time=51ms TTL=52
Ping statistics for 188.122.94.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 50ms, Maximum = 51ms, Average = 50ms
192.168.100.1 BRAS TIM
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=3ms TTL=254
Reply from 192.168.100.1: bytes=32 time=2ms TTL=254
Reply from 192.168.100.1: bytes=32 time=3ms TTL=254
Reply from 192.168.100.1: bytes=32 time=2ms TTL=254
Ping statistics for 192.168.100.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 3ms, Average = 2ms
Ping alti per una FTTH, mi spiace.
Approfitto per chiedervi una spiegazione di alcune cose che non mi tornano.
Vorrei capire come è possibile che alcuni hostname di server speedtest TIM puntino tutti allo stesso IP.
Ad esempio
speedtestfi1.telecomitalia.it
speedtestpe1.telecomitalia.it
speedtestpg1.telecomitalia.it
speedtestrm1.telecomitalia.it
puntano tutti a 151.99.108.126.
Ovviamente, ai fini della misura del ping, non avrebbe senso fingere che un server si trovi in una città e non in quella dove realmente si trova.
L'anycast potrebbe essere una spiegazione? Ho capito che viene usato per i server DNS. Ad esempio, il DNS Google ha indirizzo 8.8.8.8 però non corrisponde ad un unico server fisico ma a più server distribuiti nei vari stati altrimenti la latenza sarebbe troppo alta e questo è ottenuto proprio tramite l'anycast.
Un meccanismo del genere potrebbe funzionare anche coi server TIM? Ad esempio, se sono a Roma 151.99.108.126 corrisponde ad un server a Roma mentre se sono a Firenze corrisponde ad un server a Firenze?
Come faccio a capire quale server viene effettivamente contattato? Vorrei capire se contatto 8.8.8.8 negli USA o in Italia, ad esempio.
Viceversa se volessi contattare 8.8.8.8 negli USA come potrei forzare la scelta di quel server. Static route?
Io non sono in grado di risponderti, ma vedrai che qualcuno qui ci sarà senz'altro in grado di poterlo fare :)
Sul sito Fastweb pubblicizzano la 1000/200 "ottimizzata per il gaming": il caso vuole che da me sia disponibile qualunque provider tranne Fastweb (o meglio, per quest'ultimo mi da la copertura fino alla 100/20, quindi presumo FTTC), dunque non sono in grado di testare di persona, ma comunque indicano che vi sia un'ottimizzazione per il ping, purché sia su "rete Fastweb"... cosa intendono?! Che se gira su Open Fiber non va bene? Quindi Fastweb stende ancora linea FTTH propria come in passato (qui a Bologna tanti anni fa lo fecero un po', ma non da me)? Sarebbe molto interessante testare una FTTH Fastweb settata per il gaming, qualcuno sa se ci sia chi abbia questa connessione qui sul forum? Grazie!
Edit:
Ho appena scoperto che Fastweb gira su Open Fiber solo a Milano, bensì in nessuna altra città, e che ha fondato insieme a TIM la joint venture "Flash Fiber", una rete FTTH condivisa tra loro, anche se non ho inteso se si tratti degli apparti FTTH TIM che da me hanno già posizionato, cioè dal momento che da me ci sono sia gli apparati TIM che quelli Open Fiber questo significhi che sui primi girino TIM e Fastweb, mentre sui secondi Infostrada, Tiscali e Vodafone. Il fatto che sul sito Open Fiber risulto coperto, così come sui rispettivi siti di Infostrada/Tiscali/Vodafone per le rispettive 1000/200-300, ma che sui siti TIM e Fastweb risulto coperto solo dalle loro 100/20 (quindi FTTC), mi fa sperare che non sia solo stata ancora data la commerciabilità dell'apparato TIM montato (da 9 mesi...). Comunque è un bel pollaio con ste FTTH eh! :D
Il ping e la banda non hanno nesso, premesso questo, con Psyred abbiamo fatto test specifici e tutto risulta meno che Infotrada abbia ping peggiore! Mi dava 30 ms di scarto con la mia TIM sui server gaming (confronto tra FTTC)!
Proprio per questo ho specificato ;)
E comunque si, Wind ha dei problemi di ping in alcune città (soprattutto). Per questo dicevo che il discorso della banda non è relativo al ping, ma alla rete non completa. D'altro canto il ping alto (in alcune città) potrebbe essere indice di una rete non completamente ottimizzata/finita/rattoppata/con qualche problema da sistemare.
Proprio per questo ho specificato ;)
E comunque si, Wind ha dei problemi di ping in alcune città (soprattutto). Per questo dicevo che il discorso della banda non è relativo al ping, ma alla rete non completa. D'altro canto il ping alto (in alcune città) potrebbe essere indice di una rete non completamente ottimizzata/finita/rattoppata/con qualche problema da sistemare.
Capisco :) Quali sono queste città? Grazie :)
Il ping e la banda non hanno nesso
Parlando di FTTH diciamo che i vari tagli commercializzati sono ininfluenti (a livello macroscopico) sui tempi di ping.
Alias tra un 500/30 (un taglio di Tiscali) ed un 1000/400 i tempi di ping saranno più o meno identici.
Però la banda (quando è poca) influenza eccome i tempi di ping (ed ancora di più la latenza di applicazioni che non fanno semplici ping tra loro).
Prova a fare un upload che ti saturi la banda in upload, riservando un 0.2Mb (che poi era l'upload di alcune adsl 7Mb tempo fa) via QoS sul tuo router.
La linea non è 100% satura (hai un canale preferenziale), però il tuo ping al primo Hop vedrai (se hai una FTTH) che più che quadruplica (diciamo ad occhio da 0.8ms a 3.4ms).
Parlando di FTTH diciamo che i vari tagli commercializzati sono ininfluenti (a livello macroscopico) sui tempi di ping.
Alias tra un 500/30 (un taglio di Tiscali) ed un 1000/400 i tempi di ping saranno più o meno identici.
Però la banda (quando è poca) influenza eccome i tempi di ping (ed ancora di più la latenza di applicazioni che non fanno semplici ping tra loro).
Prova a fare un upload che ti saturi la banda in upload, riservando un 0.2Mb (che poi era l'upload di alcune adsl 7Mb tempo fa) via QoS sul tuo router.
La linea non è 100% satura (hai un canale preferenziale), però il tuo ping al primo Hop vedrai (se hai una FTTH) che più che quadruplica (diciamo ad occhio da 0.8ms a 3.4ms).
Molto interessante non lo sapevo! Io feci esperienza su ADSL, e su quella il ping non aveva nesso con la banda (facemmo moltissime prove), invece mi par di capire che così non sia con FTTH. Domanda: avere poca banda, o averne ma saturarne gran parte, da lo stesso risultato in termini di ping su FTTH?
Capisco :) Quali sono queste città? Grazie :)
Penso si riferisca ai +5-6 ms sperimentati dalle utenze FTTH perugine. Finora non ci sono state testimonianze circa problematiche analoghe in altre città.
Ok grazie Psyred! :)
Sai qualcosa della 1000/200 "gaming" di Fastweb (dedicata propriamente al ping)?
http://www.fastweb.it/adsl-fibra-ottica/internet/?from=home
"L'offerta Internet è configurata da Fastweb in modo da offrirti le migliori prestazioni possibili per il gaming online con tempi di latenza (ping) molto bassi, elevata velocità e stabilità di linea. La configurazione ottimizzata per il gioco online è disponibile solo su rete Fastweb*"
*"Fastweb si riserva di riportare il profilo per il gioco online a quello standard, qualora si riveli di qualità insufficiente o interferisca con altri servizi. La Fibra Ottica, sia fino a casa del Cliente che fino all'armadio di strada, offre già le migliori prestazioni per il gioco online. La configurazione ottimizzata per il gioco online non è disponibile fuori rete Fastweb."
Per rete "Fastweb" penso intendano Flash Fiber, cioè nell'80% dei casi rete TIM, giusto? Ed oltre a questo si qualcosa di specifico di questa connessione? Qualche esperienza diretta magari? Grazie :)
Molto interessante non lo sapevo! Io feci esperienza su ADSL, e su quella il ping non aveva nesso con la banda (facemmo moltissime prove)
No non è vero in adsl è dove si vede ben di più la dipedenza dalla banda del ping.
Prova una Adsl 7/0.25 e poi una 20/1 e vedrai che la 20Mb pinga meglio a parità di impostazioni (ovvio che non devi confrontare una 7Mb interleaved con una 20Mb in Fast, ma entrambe in interleaved, e con stessa profondità di interleave, o entrambe in fast).
invece mi par di capire che così non sia con FTTH. Domanda: avere poca banda, o averne ma saturarne gran parte, da lo stesso risultato in termini di ping su FTTH?
Per non vedere differenze di ping su Windows ti serve una linea che abbia almeno 10Mb di down e 10Mb di up liberi mentre pinghi.
In realtà può bastare anche una 1.2/1.2 dato che al più tra 10/10 e 1.2/1.2 quello che vedi di differenza è 1ms
Con Linux (o con un comando ping ad alta risoluzione per Win, es. HR-Ping) che invece ti mostra anche i microsec, per non vedere nulla dovuto alla banda dovresti avere dovresti avere una 10Gb simmetrica :D
Si avere poca banda o averne tanta ma satura (con la parte che rimane libera pari al caso della poca banda) a grandi linee darà gli stessi ping (a pari tecnologia sottostante, ergo che una FTTC a 200/20Mb pingherà comunque leggermente peggio di una FTTH a 20/1Mb e pure di una FTTH 7/0.25).
Solito marketing a mio avviso. La dicitura ottimizzata per il gaming online c'è anche per le FTTC/VDSL, che non hanno niente di diverso dalle altre VDSL italiane.
Oltretutto, da quanto dicono gli stessi clienti Fastweb, il loro routing non è esattamente il massimo.
riccardi.fede
29-08-2017, 12:41
Sai qualcosa della 1000/200 "gaming" di Fastweb (dedicata propriamente al ping)?
E' marketing. Anche per le ADSL dicono "gaming" perchè settano in Fast.
Per la fibra invece non ci sono differenze di prestazioni (a parte instradamento).
No non è vero in adsl è dove si vede ben di più la dipedenza dalla banda del ping.
Prova una Adsl 7/0.25 e poi una 20/1 e vedrai che la 20Mb pinga meglio a parità di impostazioni (ovvio che non devi confrontare una 7Mb interleaved con una 20Mb in Fast, ma entrambe in interleaved, e con stessa profondità di interleave, o entrambe in fast).
Ne confrontammo moltissime, settate in fastpath, interleaved o interleaved legegero (TIM "internet play") e non c'erano differenze legate alla banda.
Per non vedere differenze di ping su Windows ti serve una linea che abbia almeno 10Mb di down e 10Mb di up liberi mentre pinghi.
In realtà può bastare anche una 1.2/1.2 dato che al più tra 10/10 e 1.2/1.2 quello che vedi di differenza è 1ms
Con Linux (o con un comando ping ad alta risoluzione per Win, es. HR-Ping) che invece ti mostra anche i microsec, per non vedere nulla dovuto alla banda dovresti avere dovresti avere una 10Gb simmetrica :D
Allora si vede che ricordo male.
Si avere poca banda o averne tanta ma satura (con la parte che rimane libera pari al caso della poca banda) a grandi linee darà gli stessi ping (a pari tecnologia sottostante, ergo che una FTTC a 200/20Mb pingherà comunque leggermente peggio di una FTTH a 20/1Mb e pure di una FTTH 7/0.25).
Ok grazie.
Solito marketing a mio avviso. La dicitura ottimizzata per il gaming online c'è anche per le FTTC/VDSL, che non hanno niente di diverso dalle altre VDSL italiane.
Oltretutto, da quanto dicono gli stessi clienti Fastweb, il loro routing non è esattamente il massimo.
Capisco, quindi roba da AGCOM, perché se sanno già a priori che non hanno modo di garantire ping migliore di quello standard, ma pubblicizzano la cosa, è una truffa, c'è poco da fare,
Conosci qualcuno con la 1000/200 Fastweb attiva? Ho provato nel topic Fastweb, ma è dedicato alla FTTH 100/50, dunque forse di Fastweb FTTH 1000/200 ancora non ce n'è?
E' marketing. Anche per le ADSL dicono "gaming" perchè settano in Fast.
Per la fibra invece non ci sono differenze di prestazioni (a parte instradamento).
Si Fede, non c'è differenza con fast ed annessi, però abbiamo visto che gli instradamenti contano moltissimo, quindi se garantiscono davvero determinati instradamenti vorrebbe dire garantire un ping sempre migliore di quello standard. Bisognerebbe avere la possibilità di testare direttamente con il metodo del topic, e magari parlarne con qualche tecnico Fastweb (a proposito, ce ne sono qui sul Forum? di altri provider ne son capitati più di una volta).
Conosci qualcuno con la 1000/200 Fastweb attiva? Ho provato nel topic Fastweb, ma è dedicato alla FTTH 100/50, dunque forse di Fastweb FTTH 1000/200 ancora non ce n'è?
Su questo forum mi pare non si sia ancora visto nessuno.
Su questo forum mi pare non si sia ancora visto nessuno.
Si hai ragione, infatti nel topic della FTTH 100/50 si scrive che manco ancora hanno passato loro su 1000/200, e si conferma la vostra versione della "genuinità" del lato gaming promesso :D
PS:
Ho trovato una lista di server di COD :read:
https://www.gametracker.com/search/cod/
riccardi.fede
29-08-2017, 13:45
Conosci qualcuno con la 1000/200 Fastweb attiva? Ho provato nel topic Fastweb, ma è dedicato alla FTTH 100/50, dunque forse di Fastweb FTTH 1000/200 ancora non ce n'è?
Si c'è un utente sotto rete GPON. Ci sono i risultati sul foglio excel di Torino.
Si Fede, non c'è differenza con fast ed annessi, però abbiamo visto che gli instradamenti contano moltissimo, quindi se garantiscono davvero determinati instradamenti vorrebbe dire garantire un ping sempre migliore di quello standard. Bisognerebbe avere la possibilità di testare direttamente con il metodo del topic, e magari parlarne con qualche tecnico Fastweb (a proposito, ce ne sono qui sul Forum? di altri provider ne son capitati più di una volta).
Guarda avevo chiesto ad un tecnico per l'ADSL e mi aveva detto che non cambia niente per gli instradamenti. Soltanto Fast anzichè Interleaved. Questo confronto l'hanno fatto apposta, visto che con TIM le linee ADSL di default sono interleaved.
Inoltre avevo una volta una linea Fastweb SuperJet, passata da qualche mese a Joy, sempre ADSL e non è cambiato il ping...
Si c'è un utente sotto rete GPON. Ci sono i risultati sul foglio excel di Torino.
Sicuro che fosse già una 1000/200? Seppur probabilmente non vi sia differenza per il ping.
Guarda avevo chiesto ad un tecnico per l'ADSL e mi aveva detto che non cambia niente per gli instradamenti. Soltanto Fast anzichè Interleaved. Questo confronto l'hanno fatto apposta, visto che con TIM le linee ADSL di default sono interleaved.
No Fede, volevo intendere che per il ping rispettivamente contano:
ADSL: fastpath Vs interleaved
FTTH: instradamenti
Inoltre avevo una volta una linea Fastweb SuperJet, passata da qualche mese a Joy, sempre ADSL e non è cambiato il ping...
Capisco, ma sempre di ADSL si tratta, io vorrei vedere un po' di test su FTTH 1000/200 con i tracert (ndr: sto mettendo mano allo script, tra poco lo posto, così mi dite se valga la pena aggiungere altri server o no).
riccardi.fede
29-08-2017, 14:10
Sicuro che fosse già una 1000/200? Seppur probabilmente non vi sia differenza per il ping.
Yes, per nuovi clienti le attivano.
Link: http://www.hwupgrade.it/forum/showpost.php?p=44939693&postcount=73 Avevi pure risposto :p
No Fede, volevo intendere che per il ping rispettivamente contano:
ADSL: fastpath Vs interleaved
FTTH: instradamenti
Sorry, non avevo capito :)
shaft271
29-08-2017, 14:11
Città: Napoli
IPS: Vodafone FTTH 300 mega
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=17ms TTL=54
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 16ms, Massimo = 17ms, Medio = 16ms
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=51
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=51
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 25ms, Massimo = 26ms, Medio = 25ms
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=40ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Risposta da 216.58.198.163: byte=32 durata=39ms TTL=51
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 39ms, Massimo = 40ms, Medio = 39ms
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=110ms TTL=51
Risposta da 172.217.12.196: byte=32 durata=109ms TTL=51
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 109ms, Massimo = 110ms, Medio = 109ms
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=301ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=301ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=300ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=300ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=315ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=301ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=300ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=300ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=301ms TTL=43
Risposta da 216.58.200.4: byte=32 durata=300ms TTL=43
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 300ms, Massimo = 315ms, Medio = 301ms
@ shaft271 e chiunque altro volesse provare
Testate lo script seguente per favore ("sgru® modded version" (http://www.hwupgrade.it/forum/showpost.php?p=44974372&postcount=156)) :D
@ECHO OFF
echo *** Google Milano ***>> risultati-ping.txt
ping 216.58.205.67 -n 10 >> risultati-ping.txt
echo. >> risultati-ping.txt
echo. >> risultati-ping.txt
echo *** Google Francoforte ***>> risultati-ping.txt
ping 172.217.22.35 -n 10 >> risultati-ping.txt
echo. >> risultati-ping.txt
echo. >> risultati-ping.txt
echo *** Google Londra ***>> risultati-ping.txt
ping 216.58.198.163 -n 10 >> risultati-ping.txt
echo. >> risultati-ping.txt
echo. >> risultati-ping.txt
echo *** Google New York ***>> risultati-ping.txt
ping 172.217.12.196 -n 10 >> risultati-ping.txt
echo. >> risultati-ping.txt
echo. >> risultati-ping.txt
echo *** Google Hong Kong ***>> risultati-ping.txt
ping 216.58.200.4 -n 10 >> risultati-ping.txt
echo. >> risultati-ping.txt
echo. >> risultati-ping.txt
echo *** data center OVH, Roubaix, Francoforte (gaming) ***>> risultati-ping.txt
ping verygames.net -n 10 >> risultati-ping.txt
echo. >> risultati-ping.txt
echo. >> risultati-ping.txt
echo *** multiplay.co.uk - Inghilterra (gaming) ***>> risultati-ping.txt
ping multiplay.co.uk -n 10 >> risultati-ping.txt
echo. >> risultati-ping.txt
echo. >> risultati-ping.txt
echo *** Interactive3D - Olanda (gaming) ***>> risultati-ping.txt
ping i3d.net -n 10 >> risultati-ping.txt
pause
@ Fede
Ho scritto una mini guida (da confermare) :)
Lanciare DOS (esegui --> cmd.exe);
Copiare ed incollare su DOS il codice così com'è qui riportato (la procedura si avvierà automaticamente);
Attendere che la procedura abbia termine (viene mostrato "pause", servirà un po' di tempo);
Accedere alla cartella "C:\Documents and Settings\NOMEUTENTE" per poter aprire il file denominato automaticamente "risultati-ping.txt";
Copiare ed incollare il contenuto del file in un post qui sul forum (i nomi dei server saranno già in grassetto, ma indicare inoltre "PROVIDER/PROFILO/CITTÀ" a parte).
NB: Su Mac non so quale sia la procedura (ho sempre avuto solo Windows)! :D
@ sgru
Grazie mille per l'dea! :)
@ Psyred
Dici che potrebbe tornare utile inserire altri server gaming? Se si quali? Magari in USA/ecc.?
Grazie a tutti :)
EDIT:
Non siamo sicuri che il file appaia a tutti nella stessa destinazione (stiamo verificando se sia possibile destinarlo per tutti sul desktop di default).
riccardi.fede
29-08-2017, 14:32
@ Fede
Ho scritto una mini guida (da confermare) :)
Accedere alla cartella "C:\Documents and Settings\NOMEUTENTE" per poter aprire il file denominato automaticamente "risultati-ping.txt";
Grande! Precisazione, a me lo salva in "C:\Users\NomeUtente"..
Grande!
Se non fosse stato per sgru mai avrei saputo di poterci semplificare la life così :D
Precisazione, a me lo salva in "C:\Users\NomeUtente"..
Ci sarà un modo per far si che salti fuori a tutti sul desktop? Forse sarebbe il top! Altrimenti potremmo indicare nella mini guida di utilizzare la funzione "cerca" per trovarlo (io, da "grande esperto" di ste cose, ho fatto così! :ciapet:)?
Un'altra cosa utile potrebbe essere quella di far inserire in tutti i topic delle FTTH dei vari provider, al rispettivo primo post di ognuna, il link a questo topic del ping su FTTH, con annesso il "gentile invito a parteciparvi numerosi" :)
216.58.205.67 - 13ms
172.217.22.35 - 22ms
216.58.198.163 - 35ms
172.217.12.196 - 106ms
216.58.200.4 - 293ms
verygames.net - 29ms
multiplay.co.uk - 38ms
i3d.net - 35ms
Tiscali FTTH Gigabit a Perugia.
@ Psyred
Dici che potrebbe tornare utile inserire altri server gaming? Se si quali? Magari in USA/ecc.?
Mah ce ne sarebbero tanti... Io per ora mi limiterei a questi 3 data center. Oltretutto la cosa migliore rimane pingare direttamente l'IP del/dei server dove si gioca.
216.58.205.67 - 13ms
172.217.22.35 - 22ms
216.58.198.163 - 35ms
172.217.12.196 - 106ms
216.58.200.4 - 293ms
verygames.net - 29ms
multiplay.co.uk - 38ms
i3d.net - 35ms
Tiscali FTTH Gigabit a Perugia.
FTTC TIM 100/20 (Bologna):
216.58.205.67 - 21ms
172.217.22.35 - 19ms
216.58.198.163 - 40ms
172.217.12.196 - 110ms
216.58.200.4 - 305ms
verygames.net (gaming) - 25ms
multiplay.co.uk (gaming) - 29ms
i3d.net (gaming) - 31ms
Possibile che la FTTH Tiscali vada peggio della mia FTTC TIM sui server gaming?! :help: Ok che è a Perugia, ma non è manco a "Pechino" da motivare in un caso 9 ms di differenza!
Mah ce ne sarebbero tanti... Io per ora mi limiterei a questi 3 data center. Oltretutto la cosa migliore rimane pingare direttamente l'IP del/dei server dove si gioca.
Ok, se per caso cambi idea aggiornami! :)
Esecuzione di Ping verygames.net [94.23.214.174] con 32 byte di dati:
Risposta da 94.23.214.174: byte=32 durata=26ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=25ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=25ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=26ms TTL=51
Statistiche Ping per 94.23.214.174:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 25ms, Massimo = 26ms, Medio = 25ms
Esecuzione di Ping multiplay.co.uk [85.236.96.26] con 32 byte di dati:
Risposta da 85.236.96.26: byte=32 durata=29ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=29ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=29ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=29ms TTL=54
Statistiche Ping per 85.236.96.26:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 29ms, Massimo = 29ms, Medio = 29ms
Esecuzione di Ping i3d.net [188.122.94.99] con 32 byte di dati:
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=54
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=54
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=54
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=54
Statistiche Ping per 188.122.94.99:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 41ms, Massimo = 41ms, Medio = 41ms
In effetti ottengo risultati migliori anche con la mia FTTC Infostrada (dalla Toscana). Tranne per i3d, dove l'instradamento nel mio caso è Milano - Londra - Rotterdam.
A quanto pare Perugia non è una zona particolarmente fortunata per il routing....
Speriamo che quelli di Tiscali rientrino in blocco dalle ferie e comincino a connettere le FTTH richieste (da maggio/giugno!) così riusciremo a fare confronti su varie città, ma se si confermerà che va così, non mi avranno mai.
PS:
Io sono curioso di Fastweb! :D
Comunque su pacchetti di piccole dimensioni come abbiamo appurato la latenza varia di pochi ms al gateway (tipo 2\4ms) tra FTTC con G.INP\ADSL con Fastpath e FTTH, quindi più che altro sarebbe interessante un confronto tra i vari ISP a livello di routing\rete di trasporto a seconda della città indipendentemente dalla tecnologia di accesso che appunto influisce minimamente su questo tipo di test.
O per lo meno, io passando da ADSL a FTTC non ho notato differenze di routing e presuppongo anche per la FTTH sia uguale.
Oltretutto aggiunerei un dettaglio; con la maggior di ISP (almeno con TIM, Tiscali ed Infostrada succede avendole sotto mano, ma presumo anche con altri) a seconda dell'IP della connessione possono variare leggermente le latenze (tipo 10\20ms soprattutto all'estero) quindi i paragoni fatti al volo potrebbero non essere proprio affidabilissimi per stabilire se un ISP pinga meglio o peggio di un'altro in termini assoluti.
P.S: Pure io sono curioso di vedere un pò di traceroute con Fastweb ad oggi. :fagiano:
Se non fosse stato per sgru mai avrei saputo di poterci semplificare la life così :D
Ci sarà un modo per far si che salti fuori a tutti sul desktop? Forse sarebbe il top! Altrimenti potremmo indicare nella mini guida di utilizzare la funzione "cerca" per trovarlo (io, da "grande esperto" di ste cose, ho fatto così! :ciapet:)?
usa le variabili di sistema
%USERPROFILE%\Desktop
Invece di
c:\users\ecceteraeccetera
blademaster988
30-08-2017, 10:39
Città: Bari
ISP: Telecom Italia aka TIM ftth 1000/100
*** Google Italia (Milano) ***
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 15ms, Massimo = 16ms, Medio = 15ms
*** Google Germania (Francoforte) ***
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=27ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=27ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 25ms, Massimo = 27ms, Medio = 26ms
*** Google UK (Londra) ***
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=33ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=33ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 33ms, Massimo = 35ms, Medio = 34ms
*** Google USA (New York) ***
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=116ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=114ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=116ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=114ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=114ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=116ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 114ms, Massimo = 116ms, Medio = 115ms
*** Google Hong Kong (HK) ***
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=314ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=315ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=315ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=315ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 314ms, Massimo = 316ms, Medio = 315ms
*** verygames.net - Data center OVH, Roubaix, FR ***
Esecuzione di Ping verygames.net [94.23.214.174] con 32 byte di dati:
Risposta da 94.23.214.174: byte=32 durata=32ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=30ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=32ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=30ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=30ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=32ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Statistiche Ping per 94.23.214.174:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 30ms, Massimo = 32ms, Medio = 31ms
*** multiplay.co.uk ***
Esecuzione di Ping multiplay.co.uk [85.236.96.26] con 32 byte di dati:
Risposta da 85.236.96.26: byte=32 durata=35ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=37ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=34ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=35ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=34ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Statistiche Ping per 85.236.96.26:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 34ms, Massimo = 37ms, Medio = 35ms
*** i3d.net - interactive3D, NL ***
Esecuzione di Ping i3d.net [188.122.94.99] con 32 byte di dati:
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=43ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=43ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=43ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Statistiche Ping per 188.122.94.99:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 41ms, Massimo = 43ms, Medio = 42ms
riccardi.fede
30-08-2017, 11:01
usa le variabili di sistema
%USERPROFILE%\Desktop
Hai ragione, grazie!
Aereo, la versione aggiornata dovrebbe essere così, prova un po':
@ECHO OFF
echo *** Google Milano ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.205.67 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Francoforte ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 172.217.22.35 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Londra ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.198.163 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Chicago ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 172.217.12.196 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Hong Kong ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.200.4 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Vergames, OVH, Roubaix, Francoforte (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping verygames.net -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** multiplay.co.uk - Inghilterra (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping multiplay.co.uk -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Interactive3D - Olanda (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping i3d.net -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
pause
Aggiornato anche Bari. Grazie
Raga, se volete che i nomi delle destinazioni del ping vengano automaticamente scritte in grassetto per chi copia ed incolla il codice, quando scrivete il codice da eseguire dovete anteporre [noparse] al tag , esempio:
- scritta in grassetto, senza il tag [noparse].
- [b]scritta che deve essere in grassetto per chi copierà ed incollerà il codice, col tag [noparse], come vedete il tag [B] non è visto come un vero tag grazie al tag [noparse]
Per un esempio pratico provate a quotare il mio post #156 (http://www.hwupgrade.it/forum/showpost.php?p=44974372&postcount=156) per capire meglio.
Scusate l'assenza, ho un po' di problemi purtroppo.
Yes, per nuovi clienti le attivano.
Link: http://www.hwupgrade.it/forum/showpost.php?p=44939693&postcount=73 Avevi pure risposto :p
Scusa Fede si vede che ho dormito in piedi :muro:
Sorry, non avevo capito :)
Figurati :)
Oltretutto aggiungerei un dettaglio; con la maggior di ISP (almeno con TIM, Tiscali ed Infostrada succede avendole sotto mano, ma presumo anche con altri) a seconda dell'IP della connessione possono variare leggermente le latenze (tipo 10\20ms soprattutto all'estero) quindi i paragoni fatti al volo potrebbero non essere proprio affidabilissimi per stabilire se un ISP pinga meglio o peggio di un'altro in termini assoluti.
Non so su FTTH, ma su FTTC TIM sicuramente si, tant'è che scrissi una lista dei vari ip (primi numeri) migliori in base i risultati (sia del ping che della banda).
P.S: Pure io sono curioso di vedere un pò di traceroute con Fastweb ad oggi. :fagiano:
:cool:
usa le variabili di sistema
%USERPROFILE%\Desktop
Invece di
c:\users\ecceteraeccetera
Ti ringrazio, ma perdona la mia ignoranza: devo solo scrivere propriamente così e si risolve? Grazie :)
Città: Bari
ISP: Telecom Italia aka TIM ftth 1000/100
*** Google Italia (Milano) ***
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=16ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=15ms TTL=54
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 15ms, Massimo = 16ms, Medio = 15ms
*** Google Germania (Francoforte) ***
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=27ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=27ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=25ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Risposta da 172.217.22.35: byte=32 durata=26ms TTL=53
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 25ms, Massimo = 27ms, Medio = 26ms
*** Google UK (Londra) ***
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=33ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=33ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=35ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Risposta da 216.58.198.163: byte=32 durata=34ms TTL=49
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 33ms, Massimo = 35ms, Medio = 34ms
*** Google USA (New York) ***
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=116ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=114ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=116ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=114ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=114ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=116ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=115ms TTL=50
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 114ms, Massimo = 116ms, Medio = 115ms
*** Google Hong Kong (HK) ***
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=314ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=315ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=315ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=315ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Risposta da 216.58.200.4: byte=32 durata=316ms TTL=48
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 314ms, Massimo = 316ms, Medio = 315ms
*** verygames.net - Data center OVH, Roubaix, FR ***
Esecuzione di Ping verygames.net [94.23.214.174] con 32 byte di dati:
Risposta da 94.23.214.174: byte=32 durata=32ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=30ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=32ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=30ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=30ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=32ms TTL=50
Risposta da 94.23.214.174: byte=32 durata=31ms TTL=50
Statistiche Ping per 94.23.214.174:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 30ms, Massimo = 32ms, Medio = 31ms
*** multiplay.co.uk ***
Esecuzione di Ping multiplay.co.uk [85.236.96.26] con 32 byte di dati:
Risposta da 85.236.96.26: byte=32 durata=35ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=37ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=34ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=35ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=34ms TTL=50
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=36ms TTL=53
Statistiche Ping per 85.236.96.26:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 34ms, Massimo = 37ms, Medio = 35ms
*** i3d.net - interactive3D, NL ***
Esecuzione di Ping i3d.net [188.122.94.99] con 32 byte di dati:
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=43ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=43ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=41ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=43ms TTL=52
Risposta da 188.122.94.99: byte=32 durata=42ms TTL=52
Statistiche Ping per 188.122.94.99:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 41ms, Massimo = 43ms, Medio = 42ms
Comincio ad essere molto sfiduciato sinceramente :cry: Forse, in Italia, passare ad FTTH per il ping non ha proprio senso, bensì lo ha solo per la banda (ma tanti già non sanno cosa farsene di 100 Mb/sec in down, figurarsi di 1000 Mb/sec)! Forse qualcuno comincerà a sottoscrivere abbonamenti da dividere tra più appartamenti dei medesimi condomini, un po' come ai tempi antichi della teleselezione (https://youtu.be/NFaZVcGX89M?t=52s) in SIP (si, so cosa sia grazie agli insegnamenti by Lino + Wiki...) :D :D :D
Comunque:
FTTC TIM 100/20 (Bologna):
216.58.205.67: 21ms
172.217.22.35: 19ms
216.58.198.163: 40ms
172.217.12.196: 110ms
216.58.200.4: 305ms
verygames.net (gaming): 25ms (TIM FTTH Bari 31 ms; +6 ms)
multiplay.co.uk (gaming): 29ms (TIM FTTH Bari 35 ms;+6 ms)
i3d.net (gaming): 31ms (TIM FTTH Bari 42 ms; +11 ms)
Ok che è a Bari, ma non giustifica secondo me un aumento del genere, manco fossimo stati in FTTC entrambi.
Aereo, la versione aggiornata dovrebbe essere così, prova un po':
@ECHO OFF
echo *** Google Milano ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.205.67 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Francoforte ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 172.217.22.35 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Londra ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.198.163 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Chicago ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 172.217.12.196 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Google Hong Kong ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping 216.58.200.4 -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Vergames, OVH, Roubaix, Francoforte (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping verygames.net -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** multiplay.co.uk - Inghilterra (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping multiplay.co.uk -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo. >> %USERPROFILE%\Desktop\risultati-ping.txt
echo *** Interactive3D - Olanda (gaming) ***>> %USERPROFILE%\Desktop\risultati-ping.txt
ping i3d.net -n 10 >> %USERPROFILE%\Desktop\risultati-ping.txt
pause
A me non funziona Fede, provo a metterci mano e tra un po' aggiorno il post :)
EDIT: niente Fede non ci salto fuori, cioè a me fa un percorso diverso, forse cambia in base all'OS. Se i ragazzi esperti di codice qui non troveranno una soluzione che dia per qualunque OS una risposta automatica senza necessità di modifiche da parte degli utenti, inseriremo nella guida l'indicazione della questione, non c'è altro da fare purtroppo.
Raga, se volete che i nomi delle destinazioni del ping vengano automaticamente scritte in grassetto per chi copia ed incolla il codice, quando scrivete il codice da eseguire dovete anteporre [noparse] al tag , esempio:
- scritta in grassetto, senza il tag [noparse].
- [b]scritta che deve essere in grassetto per chi copierà ed incollerà il codice, col tag [noparse], come vedete il tag [B] non è visto come un vero tag grazie al tag [noparse]
Per un esempio pratico provate a quotare il mio post #156 (http://www.hwupgrade.it/forum/showpost.php?p=44974372&postcount=156) per capire meglio.
Leggere questi post dopo una notte insonne da una sensazione tipo allucinogeno :D Comunque grazie sgru :)
Città: Milano Centro
Connessione: FTTH P2P dedicata Fastweb Grande Azienda (c'è un rack alto 2 metri di apparati Fastweb in azienda) 100 Mbps simmetrica
*** Google Milano ***
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Risposta da 216.58.205.67: byte=32 durata=1ms TTL=54
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 1ms, Massimo = 1ms, Medio = 1ms
*** Google Francoforte ***
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=11ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=10ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=10ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=10ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=10ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=11ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=10ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=11ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=10ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=10ms TTL=52
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 10ms, Massimo = 11ms, Medio = 10ms
*** Google Londra ***
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=29ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Risposta da 216.58.198.163: byte=32 durata=22ms TTL=50
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 22ms, Massimo = 29ms, Medio = 22ms
*** Google Chicago ***
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=122ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Risposta da 172.217.12.196: byte=32 durata=94ms TTL=50
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 94ms, Massimo = 122ms, Medio = 96ms
*** Google Hong Kong ***
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=283ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=283ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=283ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=283ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=283ms TTL=45
Risposta da 216.58.200.4: byte=32 durata=282ms TTL=45
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 282ms, Massimo = 283ms, Medio = 282ms
*** Vergames, OVH, Roubaix, Francoforte (gaming) ***
Esecuzione di Ping verygames.net [94.23.214.174] con 32 byte di dati:
Risposta da 94.23.214.174: byte=32 durata=18ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=17ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=17ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=17ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=18ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=17ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=17ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=25ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=30ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=17ms TTL=51
Statistiche Ping per 94.23.214.174:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 17ms, Massimo = 30ms, Medio = 19ms
*** multiplay.co.uk - Inghilterra (gaming) ***
Esecuzione di Ping multiplay.co.uk [85.236.96.26] con 32 byte di dati:
Risposta da 85.236.96.26: byte=32 durata=40ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=28ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=28ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=28ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=28ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=28ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=31ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=29ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=28ms TTL=54
Risposta da 85.236.96.26: byte=32 durata=28ms TTL=54
Statistiche Ping per 85.236.96.26:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 28ms, Massimo = 40ms, Medio = 29ms
*** Interactive3D - Olanda (gaming) ***
Esecuzione di Ping i3d.net [188.122.94.99] con 32 byte di dati:
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=26ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Risposta da 188.122.94.99: byte=32 durata=25ms TTL=55
Statistiche Ping per 188.122.94.99:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 25ms, Massimo = 26ms, Medio = 25ms
Quindi diciamo che questa è una "business", se si, forse è meglio non includerla tra le statistiche delle residenziali? Intendo per mantenere un dato uniforme, comunque grazie :)
@ Fede
Questa è la lista di tutti gli utenti che hanno postato i test (FTTH) fino ad ora:
cartmanland - FTTH Vodafone 1000/200 - Torino (http://www.hwupgrade.it/forum/member.php?u=419780)
peronedj - FTTH Vodafone 1000/200 - Palermo (http://www.hwupgrade.it/forum/member.php?u=147536)
whatever - FTTH Fastweb 100/50 - Torino (http://www.hwupgrade.it/forum/member.php?u=509327)
kkaarlo - FTTH Vodafone 1000/200 - Bologna (http://www.hwupgrade.it/forum/member.php?u=280513)
MisterFTTH - FTTH TIM 1000/200 ed FTTH Vodafone 1000/200 Bologna (http://www.hwupgrade.it/forum/member.php?u=514753)
aeroxdefocu - FTTH Vodafone 500 Bologna (http://www.hwupgrade.it/forum/member.php?u=205874)
sergio.pg - FTTH Vodafone 500 - Perugia (http://www.hwupgrade.it/forum/member.php?u=511963)
LuE76 - FTTH TIM 300 - Bari (http://www.hwupgrade.it/forum/member.php?u=501159)
apollo0 - FTTH Fastweb 100/50 - Milano (http://www.hwupgrade.it/forum/member.php?u=457270)
furiaceka87 - FTTH Vodafone 1000/200 - Torino (http://www.hwupgrade.it/forum/member.php?u=108015)
gerry722 - FTTH Fastweb 1000/200 - Torino (http://www.hwupgrade.it/forum/member.php?u=37828)
HyundaiBenz - FTTH Infostrada 1000/200 - Bari (http://www.hwupgrade.it/forum/member.php?u=505579)
Kjow - Infostrada 1000/200 - Perugia (http://www.hwupgrade.it/forum/member.php?u=24307)
fra8888 - Infostrada 1000/200 - Perugia (http://www.hwupgrade.it/forum/member.php?u=466063)
lion83 - Tiscali 1000/300 - Cagliari (http://www.hwupgrade.it/forum/member.php?u=496617)
MiloZ - FTTH TIM 1000/100 e FTTH Infostrada 1000/200 - ? (http://www.hwupgrade.it/forum/member.php?u=69970)
marcolino81 - FTTH Tiscali 1000/300 - Cagliari (http://www.hwupgrade.it/forum/member.php?u=458857)
Hermann1871 - FTTH TIM 1000/100 - Catania (http://www.hwupgrade.it/forum/member.php?u=413837)
JoLong - FTTH Tiscali 1000/300 - Perugia (http://www.hwupgrade.it/forum/member.php?u=512629)
blademaster988 - FTTH TIM 1000/100 - Bari (http://www.hwupgrade.it/forum/member.php?u=365633)
gandalf2016 - FTTH Fastweb BUSINESS 100 simmetrica - Milano (http://www.hwupgrade.it/forum/member.php?u=505576)
Appena avremo definitivamente confermato lo script ed i server (quest'ultimi mi pare che ormai siano consolidati, ma, in caso di ripensamenti, abbiamo ancora la possibilità di aggiungerne/toglierne) li contatterò per pm uno per uno (la lista intanto l'ho già fatta per accelerare i tempi*) :)
*vedi che Squadra che siamo!? :D Vado a letto Bros, ci leggiamo dopo :D
riccardi.fede
01-09-2017, 18:08
@Aereo, scusa ho letto solo ora.
Ah non va? A me sì :D Ho Win 10.
Ottimo!! I server direi vanno bene questi!
@Aereo, scusa ho letto solo ora.
Figurati :)
Ah non va? A me sì :D Ho Win 10.
Ok, risponderemo così allora :D :D :D
Ottimo!! I server direi vanno bene questi!
Sui server, come per lo script, sai che abbiamo i nostri ingegneri informatici, lasciamogli esprimere la propria fantasia :ciapet:
riccardi.fede
01-09-2017, 20:33
1) ti prego non citare per intero i lunghi messaggi con i risultati dei ping :read: anzi perché non li raccogliete tutti in un pastebin e d'ora in poi aggiornate direttamente quello ed inserite il link nel primo messaggio della discussione?
Sottoscrivo diventa lunghissimo Aereo :fagiano: Piuttosto fai soltanto [...]
Per Pastebin in effetti, ogni utente che fa il ping potrebbe mostrare il suo risultato direttamente su pastebin. Poi io li copio sul foglio excel, quindi alla fine sono salvati lì... Grazie
EDIT: Ho modificato il primo post. D'ora in poi l'utente salva il file txt del ping su textuploader, così almeno non appesantisce il thread.
Angelonero87
02-09-2017, 18:11
Città: Roma
ISP: FastWeb Gigabit
*** Google Milano ***
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=10ms TTL=54
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=11ms TTL=54
Reply from 216.58.205.67: bytes=32 time=10ms TTL=54
Ping statistics for 216.58.205.67:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 11ms, Average = 10ms
*** Google Francoforte ***
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Reply from 172.217.22.35: bytes=32 time=19ms TTL=52
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Reply from 172.217.22.35: bytes=32 time=19ms TTL=52
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Reply from 172.217.22.35: bytes=32 time=20ms TTL=52
Ping statistics for 172.217.22.35:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 20ms, Average = 19ms
*** Google Londra ***
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=32ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Reply from 216.58.198.163: bytes=32 time=32ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Reply from 216.58.198.163: bytes=32 time=31ms TTL=50
Ping statistics for 216.58.198.163:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 31ms, Maximum = 32ms, Average = 31ms
*** Google Chicago ***
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=103ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Reply from 172.217.12.196: bytes=32 time=104ms TTL=50
Ping statistics for 172.217.12.196:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 103ms, Maximum = 104ms, Average = 103ms
*** Google Hong Kong ***
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Reply from 216.58.200.4: bytes=32 time=289ms TTL=45
Reply from 216.58.200.4: bytes=32 time=289ms TTL=45
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Reply from 216.58.200.4: bytes=32 time=290ms TTL=45
Ping statistics for 216.58.200.4:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 289ms, Maximum = 290ms, Average = 289ms
*** Vergames, OVH, Roubaix, Francoforte (gaming) ***
Pinging verygames.net [94.23.214.174] with 32 bytes of data:
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=29ms TTL=50
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=28ms TTL=50
Reply from 94.23.214.174: bytes=32 time=29ms TTL=50
Ping statistics for 94.23.214.174:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 29ms, Average = 28ms
*** multiplay.co.uk - Inghilterra (gaming) ***
Pinging multiplay.co.uk [85.236.96.26] with 32 bytes of data:
Reply from 85.236.96.26: bytes=32 time=29ms TTL=55
Reply from 85.236.96.26: bytes=32 time=30ms TTL=55
Reply from 85.236.96.26: bytes=32 time=30ms TTL=55
Reply from 85.236.96.26: bytes=32 time=30ms TTL=55
Reply from 85.236.96.26: bytes=32 time=30ms TTL=55
Reply from 85.236.96.26: bytes=32 time=29ms TTL=55
Reply from 85.236.96.26: bytes=32 time=29ms TTL=55
Reply from 85.236.96.26: bytes=32 time=30ms TTL=55
Reply from 85.236.96.26: bytes=32 time=31ms TTL=55
Reply from 85.236.96.26: bytes=32 time=30ms TTL=55
Ping statistics for 85.236.96.26:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 31ms, Average = 29ms
*** Interactive3D - Olanda (gaming) ***
Pinging i3d.net [188.122.94.99] with 32 bytes of data:
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Reply from 188.122.94.99: bytes=32 time=29ms TTL=54
Ping statistics for 188.122.94.99:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 29ms, Average = 29ms
Aereo due cose al volo:
1) ti prego non citare per intero i lunghi messaggi con i risultati dei ping :read: anzi perché non li raccogliete tutti in un pastebin e d'ora in poi aggiornate direttamente quello ed inserite il link nel primo messaggio della discussione?
Ok mi spiace, vedrò di non farlo più :doh:
Riguardo al pastebin dicci cosa/come fare, e noi lo faremo :read:
2) che versione di Windows utilizzi? Mi pare strano che quella variabile d'ambiente non ti funzioni come previsto..
Indovina! :cool:
Sottoscrivo diventa lunghissimo Aereo :fagiano: Piuttosto fai soltanto [...]
Ok promesso, altrimenti :banned: :D
Per Pastebin in effetti, ogni utente che fa il ping potrebbe mostrare il suo risultato direttamente su pastebin. Poi io li copio sul foglio excel, quindi alla fine sono salvati lì... Grazie
EDIT: Ho modificato il primo post. D'ora in poi l'utente salva il file txt del ping su textuploader, così almeno non appesantisce il thread.
Questo è un passaggio semplice/certo/per tutti? Perché ok che vuoi semplificare, ma occhio che non diventi un deterrente per la partecipazione al topic :) Cioè, quando non diventa una cosa troppo easy, tanta gente gliela da su, è matematico :)
Città: Roma ISP: FastWeb Gigabit
*** Google Milano *** 10ms
*** Google Francoforte *** 19ms
*** Google Londra *** 31ms
*** Google Chicago *** 103ms
*** Google Hong Kong *** 289ms
*** Vergames, OVH, Roubaix, Francoforte (gaming) *** 28ms
*** multiplay.co.uk - Inghilterra (gaming) *** 29ms
*** Interactive3D - Olanda (gaming) *** 29ms
Anche con FTTH Fastweb prestazioni da FTTC :cry:
riccardi.fede
03-09-2017, 10:03
Questo è un passaggio semplice/certo/per tutti? Perché ok che vuoi semplificare, ma occhio che non diventi un deterrente per la partecipazione al topic :) Cioè, quando non diventa una cosa troppo easy, tanta gente gliela da su, è matematico :)
Guarda io ho consigliato così e lo trovo semplice, copia e incolla. Poi vedremo come andiamo :)
Aggiornato grafico Roma!
Guarda io ho consigliato così e lo trovo semplice, copia e incolla. Poi vedremo come andiamo :)
Aggiornato grafico Roma!
Ok :)
Pensavo al fatto che su TextUploader, sotto "EXPIRATION", è impostato "1 Year", dunque forse sarebbe bene selezionare "NEVER", o dopo 1 anno andrebbe tutto perso: oppure, una volta che hai aggiornato i file di excel, il problema non si pone più? Se si allora non c'è problema, al contrario se i file caricati servissero sempre spero che sto sito non farà la fine di imageshack, o ci troveremmo senza dati all'improvviso, come fu per le immagini caricate su quel sito di hosting :doh:
PS:
Aggiungi al titolo del topic "--> LEGGERE IL PRIMO POST!!! <---", torna sempre molto utile :)
@ Fede
Questa è la lista di tutti gli utenti che hanno postato i test (FTTH) fino ad ora:
cartmanland - FTTH Vodafone 1000/200 - Torino (http://www.hwupgrade.it/forum/member.php?u=419780)
peronedj - FTTH Vodafone 1000/200 - Palermo (http://www.hwupgrade.it/forum/member.php?u=147536)
whatever - FTTH Fastweb 100/50 - Torino (http://www.hwupgrade.it/forum/member.php?u=509327)
kkaarlo - FTTH Vodafone 1000/200 - Bologna (http://www.hwupgrade.it/forum/member.php?u=280513)
MisterFTTH - FTTH TIM 1000/200 ed FTTH Vodafone 1000/200 Bologna (http://www.hwupgrade.it/forum/member.php?u=514753)
aeroxdefocu - FTTH Vodafone 500 Bologna (http://www.hwupgrade.it/forum/member.php?u=205874)
sergio.pg - FTTH Vodafone 500 - Perugia (http://www.hwupgrade.it/forum/member.php?u=511963)
LuE76 - FTTH TIM 300 - Bari (http://www.hwupgrade.it/forum/member.php?u=501159)
apollo0 - FTTH Fastweb 100/50 - Milano (http://www.hwupgrade.it/forum/member.php?u=457270)
furiaceka87 - FTTH Vodafone 1000/200 - Torino (http://www.hwupgrade.it/forum/member.php?u=108015)
gerry722 - FTTH Fastweb 1000/200 - Torino (http://www.hwupgrade.it/forum/member.php?u=37828)
HyundaiBenz - FTTH Infostrada 1000/200 - Bari (http://www.hwupgrade.it/forum/member.php?u=505579)
Kjow - Infostrada 1000/200 - Perugia (http://www.hwupgrade.it/forum/member.php?u=24307)
fra8888 - Infostrada 1000/200 - Perugia (http://www.hwupgrade.it/forum/member.php?u=466063)
lion83 - Tiscali 1000/300 - Cagliari (http://www.hwupgrade.it/forum/member.php?u=496617)
MiloZ - FTTH TIM 1000/100 e FTTH Infostrada 1000/200 - ? (http://www.hwupgrade.it/forum/member.php?u=69970)
marcolino81 - FTTH Tiscali 1000/300 - Cagliari (http://www.hwupgrade.it/forum/member.php?u=458857)
Hermann1871 - FTTH TIM 1000/100 - Catania (http://www.hwupgrade.it/forum/member.php?u=413837)
JoLong - FTTH Tiscali 1000/300 - Perugia (http://www.hwupgrade.it/forum/member.php?u=512629)
blademaster988 - FTTH TIM 1000/100 - Bari (http://www.hwupgrade.it/forum/member.php?u=365633)
gandalf2016 - FTTH Fastweb BUSINESS 100 simmetrica - Milano (http://www.hwupgrade.it/forum/member.php?u=505576)
PM inviati :)
PS:
Ho contattato anche l'ultimo utente della lista (quello con la Business), ma non so se dovremo aggiungere i dati alle altre.
cartmanland
03-09-2017, 12:15
FTTH Vodafone 1000/200 - Torino
http://textuploader.com/d6zxr
*** Google Milano ***
Pinging 216.58.205.67 with 32 bytes of data:
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Reply from 216.58.205.67: bytes=32 time=5ms TTL=54
Reply from 216.58.205.67: bytes=32 time=6ms TTL=54
Ping statistics for 216.58.205.67:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 6ms, Average = 5ms
*** Google Francoforte ***
Pinging 172.217.22.35 with 32 bytes of data:
Reply from 172.217.22.35: bytes=32 time=15ms TTL=54
Reply from 172.217.22.35: bytes=32 time=15ms TTL=54
Reply from 172.217.22.35: bytes=32 time=15ms TTL=54
Reply from 172.217.22.35: bytes=32 time=14ms TTL=54
Reply from 172.217.22.35: bytes=32 time=14ms TTL=54
Reply from 172.217.22.35: bytes=32 time=14ms TTL=54
Reply from 172.217.22.35: bytes=32 time=14ms TTL=54
Reply from 172.217.22.35: bytes=32 time=14ms TTL=54
Reply from 172.217.22.35: bytes=32 time=14ms TTL=54
Reply from 172.217.22.35: bytes=32 time=14ms TTL=54
Ping statistics for 172.217.22.35:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 15ms, Average = 14ms
*** Google Londra ***
Pinging 216.58.198.163 with 32 bytes of data:
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=26ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Reply from 216.58.198.163: bytes=32 time=26ms TTL=52
Reply from 216.58.198.163: bytes=32 time=27ms TTL=52
Ping statistics for 216.58.198.163:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 27ms, Average = 26ms
*** Google Chicago ***
Pinging 172.217.12.196 with 32 bytes of data:
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=96ms TTL=52
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Reply from 172.217.12.196: bytes=32 time=95ms TTL=52
Ping statistics for 172.217.12.196:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 95ms, Maximum = 96ms, Average = 95ms
*** Google Hong Kong ***
Pinging 216.58.200.4 with 32 bytes of data:
Reply from 216.58.200.4: bytes=32 time=286ms TTL=44
Reply from 216.58.200.4: bytes=32 time=286ms TTL=44
Reply from 216.58.200.4: bytes=32 time=287ms TTL=44
Reply from 216.58.200.4: bytes=32 time=287ms TTL=44
Reply from 216.58.200.4: bytes=32 time=286ms TTL=44
Reply from 216.58.200.4: bytes=32 time=286ms TTL=44
Reply from 216.58.200.4: bytes=32 time=287ms TTL=44
Reply from 216.58.200.4: bytes=32 time=286ms TTL=44
Reply from 216.58.200.4: bytes=32 time=286ms TTL=44
Reply from 216.58.200.4: bytes=32 time=287ms TTL=44
Ping statistics for 216.58.200.4:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 286ms, Maximum = 287ms, Average = 286ms
*** Vergames, OVH, Roubaix, Francoforte (gaming) ***
Pinging verygames.net [94.23.214.174] with 32 bytes of data:
Reply from 94.23.214.174: bytes=32 time=22ms TTL=52
Reply from 94.23.214.174: bytes=32 time=21ms TTL=52
Reply from 94.23.214.174: bytes=32 time=24ms TTL=52
Reply from 94.23.214.174: bytes=32 time=22ms TTL=52
Reply from 94.23.214.174: bytes=32 time=21ms TTL=52
Reply from 94.23.214.174: bytes=32 time=21ms TTL=52
Reply from 94.23.214.174: bytes=32 time=21ms TTL=52
Reply from 94.23.214.174: bytes=32 time=21ms TTL=52
Reply from 94.23.214.174: bytes=32 time=22ms TTL=52
Reply from 94.23.214.174: bytes=32 time=22ms TTL=52
Ping statistics for 94.23.214.174:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 24ms, Average = 21ms
*** multiplay.co.uk - Inghilterra (gaming) ***
Pinging multiplay.co.uk [85.236.96.26] with 32 bytes of data:
Reply from 85.236.96.26: bytes=32 time=26ms TTL=52
Reply from 85.236.96.26: bytes=32 time=27ms TTL=52
Reply from 85.236.96.26: bytes=32 time=27ms TTL=52
Reply from 85.236.96.26: bytes=32 time=26ms TTL=53
Reply from 85.236.96.26: bytes=32 time=26ms TTL=52
Reply from 85.236.96.26: bytes=32 time=26ms TTL=52
Reply from 85.236.96.26: bytes=32 time=26ms TTL=52
Reply from 85.236.96.26: bytes=32 time=26ms TTL=52
Reply from 85.236.96.26: bytes=32 time=25ms TTL=53
Reply from 85.236.96.26: bytes=32 time=25ms TTL=53
Ping statistics for 85.236.96.26:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 27ms, Average = 26ms
*** Interactive3D - Olanda (gaming) ***
Pinging i3d.net [188.122.94.99] with 32 bytes of data:
Reply from 188.122.94.99: bytes=32 time=28ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Reply from 188.122.94.99: bytes=32 time=28ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Reply from 188.122.94.99: bytes=32 time=27ms TTL=52
Ping statistics for 188.122.94.99:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 28ms, Average = 27ms
FTTH Vodafone 1000/200 - Torino
http://textuploader.com/d6zxr
*** Google Milano *** 5ms
*** Google Francoforte *** 14ms
*** Google Londra *** 26ms
*** Google Chicago *** 95ms
*** Google Hong Kong *** 286ms
*** Vergames, OVH, Roubaix, Francoforte (gaming) *** 21ms
*** multiplay.co.uk - Inghilterra (gaming) *** 26ms
*** Interactive3D - Olanda (gaming) *** 27ms
Non sembra ci siano grandi differenze tra i vari provider purtroppo, ma aspettiamo di avere molti più dati chiaramente.
whatever
03-09-2017, 13:18
Risultati con i server aggiuntivi come richiesto
FTTH Fastweb 100/50 Torino
http://textuploader.com/d6zue
FTTH Tiscali Perugia, aggiornata con il .txt
http://textuploader.com/d6zpa
Città: Bologna Quartiere:S.Ruffillo Gestore: Vodafone Contratto: FTTH 1000/200
http://textuploader.com/d6zpt
(N.B. Scusate, ho dovuto leggermente modificare lo script per adattarlo a macOS High Sierra Beta 17a360a, ma alcuni echo mi creavano un problema in output)
Grazie a tutti :)
(N.B. Scusate, ho dovuto leggermente modificare lo script per adattarlo a macOS High Sierra Beta 17a360a, ma alcuni echo mi creavano un problema in output)
Se vuoi condividere quanto hai modificato potremo aggiungerlo al primo post del topic con l'indicazione di utilizzarlo su Mac :)
blademaster988
03-09-2017, 14:58
nuovi test come richiesto
città: Bari
isp: TIM ftth 1000/100
http://textuploader.com/d6z21
Proposta di form preconfezionato per la scrittura del post contenente il proprio test:
Provider - profilo - città
"link.txt"
Google Milano: - ms
Google Francoforte: - ms
Google Londra: - ms
Google Chicago: - ms
Google Hong Kong: - ms
Vergames, OVH, Roubaix, Francoforte (gaming): - ms
multiplay.co.uk - Inghilterra (gaming): - ms
Interactive3D - Olanda (gaming): - ms
Il codice è il seguente:
Provider - profilo - città
"link.txt"
Google Milano: - ms
Google Francoforte: - ms
Google Londra: - ms
Google Chicago: - ms
Google Hong Kong: - ms
Vergames, OVH, Roubaix, Francoforte (gaming): - ms
multiplay.co.uk - Inghilterra (gaming): - ms
Interactive3D - Olanda (gaming): - ms
Cosa ne pensate? :)
TIM FTTH 300 , BARI
http://textuploader.com/d6z3w
(Quando ho eseguito il test avevo un IP di classe 95.XXX...)
Quella dell'ip è una questione la quale potrebbe rivelarsi interessante (fu così su FTTC). Se per caso fai altri test con ip diversi postali, grazie :)
@ Fede
Di seguito lo script per Mac by kkarlo (grazie!):
cd Desktop
echo ‘*** Google Milano ***’ > risultati-ping.txt
ping 216.58.205.67 -c 10 >> risultati-ping.txt
echo >> risultati-ping.txt
echo >> risultati-ping.txt
echo ‘*** Google Francoforte ***’ >> risultati-ping.txt
ping 172.217.22.35 -c 10 >> risultati-ping.txt
echo >> risultati-ping.txt
echo >> risultati-ping.txt
echo ‘*** Google Londra ***’ >> risultati-ping.txt
ping 216.58.198.163 -c 10 >> risultati-ping.txt
echo >> risultati-ping.txt
echo >> risultati-ping.txt
echo ‘*** Google Chicago ***’ >> risultati-ping.txt
ping 172.217.12.196 -c 10 >> risultati-ping.txt
echo >> risultati-ping.txt
echo >> risultati-ping.txt
echo ‘*** Google Hong Kong ***’ >> risultati-ping.txt
ping 216.58.200.4 -c 10 >> risultati-ping.txt
echo >> risultati-ping.txt
echo >> risultati-ping.txt
echo ‘*** Vergames, OVH, Roubaix, Francoforte gaming ***’ >> risultati-ping.txt
ping verygames.net -c 10 >> risultati-ping.txt
echo >> risultati-ping.txt
echo >> risultati-ping.txt
echo ‘*** multiplay.co.uk - Inghilterra gaming ***’ >> risultati-ping.txt
ping multiplay.co.uk -c 10 >> risultati-ping.txt
echo >> risultati-ping.txt
echo >> risultati-ping.txt
echo ‘*** Interactive3D - Olanda gaming ***’ >> risultati-ping.txt
ping i3d.net -c 10 >> risultati-ping.txt
Lo aggiungerei al primo post del topic :)
PS 2:
Scrivimi cosa ne pensi riguardo a quanto ho scritto due post sopra :)
Quella dell'ip è una questione la quale potrebbe rivelarsi interessante (fu così su FTTC). Se per caso fai altri test con ip diversi postali, grazie :)
OK , comunque posso già antiparti che nel mio caso i migliori risultati li ho sempre avuti con IP di classe 79 , da test che ho fatto da quando avevo FTTC e con tutti gli upgrade di profilo rilasciati . Inserendo i DNS di Google su un router in cascata in PPPOE . Adesso sto utilizzando il Sercomm come router principale e l Asus come semplice AP quindi i dns sono quelli assegnati da TIM, sto aspettando l attivazione della 1000
aeroxdefocu
03-09-2017, 19:55
Operatore Infostrada - linea 500/100
Città: Bologna
http://txt.do/d6753
OK , comunque posso già antiparti che nel mio caso i migliori risultati li ho sempre avuti con IP di classe 79 , da test che ho fatto da quando avevo FTTC e con tutti gli upgrade di profilo rilasciati . Inserendo i DNS di Google su un router in cascata in PPPOE . Adesso sto utilizzando il Sercomm come router principale e l Asus come semplice AP quindi i dns sono quelli assegnati da TIM, sto aspettando l attivazione della 1000
Sono andato a cercare siccome non mi ricordavo bene, ed il motivo era che alla fine non fu chiaro il perchè della questione ip-prestazioni (edit n° 3 del primo post del topic seguente):
https://www.tomshw.it/forum/threads/fttc-tim-100-20-mb-sec.545034/
Però la cosa strana è che dalle rilevazioni risultava che il 79 invece fosse tra i negativi, ma non ricordo perché, mi spiace.
peronedj
04-09-2017, 07:45
Operatore Vodafone - linea 1000/200
Città: Palermo
http://textuploader.com/d67wi
Valori altissimi! :( Scrivimi che eri in WiFi per favore :help:
peronedj
04-09-2017, 07:54
Valori altissimi! :( Scrivimi che eri in WiFi per favore :help:
purtroppo no, cavo eth diretto...
perché da Palermo c'è qualcuno che fa meglio?
più si è distanti dai server e più si pinga alto, non è una novità
Hermann1871
04-09-2017, 12:09
TIM 1000/100
Catania
http://txt.do/d621y - Router TIM - IP 79.41.199.138
http://txt.do/d621s - Router Asus - IP 87.18.103.75
purtroppo no, cavo eth diretto...
Mi dispiace perone! :(
TIM 1000/100
Catania
http://txt.do/d621y - Router TIM - IP 79.41.199.138
http://txt.do/d621s - Router Asus - IP 87.18.103.75
Interessante il confronto tra i due :) Peccato per i valori, speriamo che queste FTTH verranno davvero migliorate, perché ad oggi abbiamo le FTTC che vanno meglio, cosa incredibile ma vera!
25 ms tra CT e MI è un buon ping. I confronti tra FTTC e FTTH vanno fatti nell'ambito della stessa zona, altrimenti non hanno alcun senso.
Concordo sulla seconda parte senz'altro, mentre sulla prima molto meno: in particolare i tre server gaming hanno valori alti rispetto ad altri della stessa zona in FTTC (hanno esattamente la metà rispetto ai suoi 41-44-53 ms), ed anche su Google MI (il quale, come gli altri server Google, mi interessa molto relativamente) sono ben più bassi (15 ms Vs i suoi 27 ms) :) Personalmente, finché la situazione sarà questa, non passerà in FTTH, anche se so di essere tra i pochi ben più interessato al ping che alla banda. È a mio avviso evidente che nessun provider offra FTTH davvero performanti a livello di latenza, vuoi perché debbano "ottimizzare", vuoi per altri motivi, questo nessuno di noi lo sa con certezza, ma sicuramente abbiamo le FTTH con latenze più alte rispetto a quelle delle altre nazioni :(
Scusa eh, ma se un utente siciliano pinga 25-30 ms Milano come può ottenerne di meno su host europei? Anche in considerazione del fatto che il traffico passa quasi sempre da MI.
Le latenze sugli host europei non le ho neppure guardate in quanto dipendono dal routing in quella zona, e non certo dalla tecnologia di accesso.
Quoto, non capisco come ci si possa lamentare... come se con altri provider non è lo stesso!
Scusa eh, ma se un utente siciliano pinga 25-30 ms Milano come può ottenerne di meno su host europei? Anche in considerazione del fatto che il traffico passa quasi sempre da MI.
Non mi sono spiegato a dovere: utenti siciliani con FTTC vanno meglio di quella FTTH verso i medesimi server. Il fatto che io abbia precisato che mi riferisca in particolare ai 3 server "gaming" è solo perché a me interessano più dei server Google, ma il discorso è senz'altro il medesimo.
Le latenze sugli host europei non le ho neppure guardate in quanto dipendono dal routing in quella zona, e non certo dalla tecnologia di accesso.
Perché le FTTC, dalla medesima zona, vanno meglio?
Quoto, non capisco come ci si possa lamentare... come se con altri provider non è lo stesso!
Come scritto più e più volte, sono tutte le FTTH italiane che hanno latenze al di sopra di quanto dovrebbero, a prescindere dal provider.
Non mi sono spiegato a dovere: utenti siciliani con FTTC vanno meglio di quella FTTH verso i medesimi server.
i confronti vanno fatti dalla stessa zona, città!
I confronti tra FTTC e FTTH vanno fatti nell'ambito della stessa zona, altrimenti non hanno alcun senso.
i confronti vanno fatti dalla stessa zona, città!
Come scritto a più riprese, e scorrendo i post a ritroso ne avrai prova, ho sempre specificato che tutti i confronti ai quali mi riferisco sono sempre basati sulla stessa zona/città di partenza, e verso lo stesso server.
Nel primo post del topic trovi i grafici aggiornati dei test riportati in questo topic (inerenti alle sole FTTH).
Non mi sono spiegato a dovere: utenti siciliani con FTTC vanno meglio di quella FTTH verso i medesimi server. Il fatto che io abbia precisato che mi riferisca in particolare ai 3 server "gaming" è solo perché a me interessano più dei server Google, ma il discorso è senz'altro il medesimo.
Dove sono gli utenti siciliani che pingano molto meglio di 25 ms su Milano in FTTC? Tra la Sicilia e Milano ci sono almeno 15-20 ms solo di routing. Aggiungici quei 4-6 ms (ALMENO) introdotti dalla VDSL, e se ti va di lusso otterrai 20 ms. Ma devo ancora vedere latenze del genere in FTTC da quella regione.
Perché le FTTC, dalla medesima zona, vanno meglio?
Abbiamo visto troppo pochi test per arrivare a conclusioni simili. A parità di routing (perchè è quello che fa la differenza) è improbabile che una VDSL pinghi meno di una FTTH, anche se la differenza è comunque minima (si parla di 3-5 ms appena).
P.S.
Qualche post sopra ho visto pure un utente di Bari pingare Milano 16 ms. Mai viste latenze del genere in xDSL da quella zona (minimo 20-22).
Ogni tanto evidenziamo anche i risultati positivi :read:
Joeboost
08-09-2017, 10:55
http://textuploader.com/d63h0
Rimini, Fastweb 200/30 FTTC.
EliGabriRock44
08-09-2017, 11:03
ma il thread non è solo per le FTTH?
No, ci hanno messo pure la FTTC "tanto per"...
Ri- posto i miei risultati, Wind Perugia:
http://txt.do/dj5kn
Finalmente stanno risolvendo i problemi di ping a Perugia con Wind, ora verso aruba il ping è a 7ms e i famosi hop che sballavano i risultati sono rientrati nella norma, più o meno:
tracert aruba.it
Traccia instradamento verso aruba.it [62.149.188.200]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.100.1
2 5 ms 5 ms 4 ms 151.7.198.15
3 5 ms 5 ms 5 ms 151.7.32.24
4 5 ms 5 ms 6 ms 151.7.32.92
5 5 ms 5 ms 5 ms 151.6.68.29
6 5 ms 5 ms 6 ms 151.6.64.41
7 7 ms 7 ms 6 ms 151.5.150.2
8 10 ms 7 ms 6 ms 62.149.185.28
9 7 ms 7 ms 6 ms 62.149.191.68
10 7 ms 7 ms 7 ms 62.149.188.200
Traccia completata.
_______
ping telnet.it
Esecuzione di Ping telnet.it [195.36.1.104] con 32 byte di dati:
Risposta da 195.36.1.104: byte=32 durata=12ms TTL=57
Risposta da 195.36.1.104: byte=32 durata=11ms TTL=57
Risposta da 195.36.1.104: byte=32 durata=11ms TTL=57
Risposta da 195.36.1.104: byte=32 durata=11ms TTL=57
Statistiche Ping per 195.36.1.104:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 11ms, Massimo = 12ms, Medio = 11ms
_______
tracert telnet.it
Traccia instradamento verso telnet.it [195.36.1.104]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.100.1
2 5 ms 5 ms 4 ms 151.7.198.15
3 5 ms 5 ms 5 ms 151.7.32.24
4 10 ms 5 ms 5 ms 151.7.32.14
5 12 ms 11 ms 11 ms 151.6.5.190
6 14 ms 11 ms 11 ms 151.6.1.178
7 11 ms 11 ms 11 ms telnet.mix-it.net [217.29.66.5]
8 12 ms 11 ms 11 ms itaca.telnetwork.it [195.36.1.104]
Traccia completata.
C'è ancora qualche cosa da sistemare, ma intanto la situazione sta progredendo.
Tim Fttc 200 in provincia di Catania
*** Google Milano ***
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=26ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=25ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=26ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=25ms TTL=53
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 25ms, Massimo = 26ms, Medio = 25ms
Finalmente stanno risolvendo i problemi di ping a Perugia con Wind, ora verso aruba il ping è a 7ms e i famosi hop che sballavano i risultati sono rientrati nella norma, più o meno:
tracert aruba.it
Traccia instradamento verso aruba.it [62.149.188.200]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.100.1
2 5 ms 5 ms 4 ms 151.7.198.15
3 5 ms 5 ms 5 ms 151.7.32.24
4 5 ms 5 ms 6 ms 151.7.32.92
5 5 ms 5 ms 5 ms 151.6.68.29
6 5 ms 5 ms 6 ms 151.6.64.41
7 7 ms 7 ms 6 ms 151.5.150.2
8 10 ms 7 ms 6 ms 62.149.185.28
9 7 ms 7 ms 6 ms 62.149.191.68
10 7 ms 7 ms 7 ms 62.149.188.200
Traccia completata.
_______
ping telnet.it
Esecuzione di Ping telnet.it [195.36.1.104] con 32 byte di dati:
Risposta da 195.36.1.104: byte=32 durata=12ms TTL=57
Risposta da 195.36.1.104: byte=32 durata=11ms TTL=57
Risposta da 195.36.1.104: byte=32 durata=11ms TTL=57
Risposta da 195.36.1.104: byte=32 durata=11ms TTL=57
Statistiche Ping per 195.36.1.104:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 11ms, Massimo = 12ms, Medio = 11ms
_______
tracert telnet.it
Traccia instradamento verso telnet.it [195.36.1.104]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.100.1
2 5 ms 5 ms 4 ms 151.7.198.15
3 5 ms 5 ms 5 ms 151.7.32.24
4 10 ms 5 ms 5 ms 151.7.32.14
5 12 ms 11 ms 11 ms 151.6.5.190
6 14 ms 11 ms 11 ms 151.6.1.178
7 11 ms 11 ms 11 ms telnet.mix-it.net [217.29.66.5]
8 12 ms 11 ms 11 ms itaca.telnetwork.it [195.36.1.104]
Traccia completata.
C'è ancora qualche cosa da sistemare, ma intanto la situazione sta progredendo.
Bene... Infostrada sembra prestare attenzione ai problemi di ping :cool:
Ciao a tutti! Sono stato assente per motivi di forza maggiore, novità? :) Vedo che qui vi siete fermati completamente, nessuna nuova attivazione?? :cool:
Ciao
questi (http://txt.do/d4smq) i risultati, che fanno abbastanza schifo, della mia linea Vodafone FTTH 1000/200 da Cagliari.
Riporto oltre il link del .txt anche il testo per una facile consultazione:
*** Google Milano ***
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 22ms, Massimo = 23ms, Medio = 22ms
*** Google Francoforte ***
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=32ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 31ms, Massimo = 32ms, Medio = 31ms
*** Google Londra ***
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=52ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=52ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 51ms, Massimo = 52ms, Medio = 51ms
*** Google Chicago ***
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=119ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=122ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=119ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=121ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=119ms TTL=52
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 119ms, Massimo = 122ms, Medio = 120ms
*** Google Hong Kong ***
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 310ms, Massimo = 311ms, Medio = 310ms
*** Verygames, OVH, Roubaix, Francoforte (gaming) ***
Esecuzione di Ping verygames.net [94.23.214.174] con 32 byte di dati:
Risposta da 94.23.214.174: byte=32 durata=39ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=39ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=39ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Statistiche Ping per 94.23.214.174:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 38ms, Massimo = 39ms, Medio = 38ms
*** multiplay.co.uk - Inghilterra (gaming) ***
Esecuzione di Ping multiplay.co.uk [85.236.96.26] con 32 byte di dati:
Risposta da 85.236.96.26: byte=32 durata=51ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=49ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=49ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=49ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Statistiche Ping per 85.236.96.26:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 49ms, Massimo = 51ms, Medio = 49ms
*** Interactive3D - Olanda (gaming) ***
Esecuzione di Ping i3d.net [188.122.94.99] con 32 byte di dati:
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=48ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=49ms TTL=51
Statistiche Ping per 188.122.94.99:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 45ms, Massimo = 49ms, Medio = 46ms
EliGabriRock44
03-10-2017, 21:05
Ciao
questi (http://txt.do/d4smq) i risultati, che fanno abbastanza schifo, della mia linea Vodafone FTTH 1000/200 da Cagliari.
Riporto oltre il link del .txt anche il testo per una facile consultazione:
*** Google Milano ***
Esecuzione di Ping 216.58.205.67 con 32 byte di dati:
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=22ms TTL=53
Risposta da 216.58.205.67: byte=32 durata=23ms TTL=53
Statistiche Ping per 216.58.205.67:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 22ms, Massimo = 23ms, Medio = 22ms
*** Google Francoforte ***
Esecuzione di Ping 172.217.22.35 con 32 byte di dati:
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=32ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Risposta da 172.217.22.35: byte=32 durata=31ms TTL=52
Statistiche Ping per 172.217.22.35:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 31ms, Massimo = 32ms, Medio = 31ms
*** Google Londra ***
Esecuzione di Ping 216.58.198.163 con 32 byte di dati:
Risposta da 216.58.198.163: byte=32 durata=52ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=52ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Risposta da 216.58.198.163: byte=32 durata=51ms TTL=52
Statistiche Ping per 216.58.198.163:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 51ms, Massimo = 52ms, Medio = 51ms
*** Google Chicago ***
Esecuzione di Ping 172.217.12.196 con 32 byte di dati:
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=119ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=122ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=119ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=120ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=121ms TTL=52
Risposta da 172.217.12.196: byte=32 durata=119ms TTL=52
Statistiche Ping per 172.217.12.196:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 119ms, Massimo = 122ms, Medio = 120ms
*** Google Hong Kong ***
Esecuzione di Ping 216.58.200.4 con 32 byte di dati:
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=311ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Risposta da 216.58.200.4: byte=32 durata=310ms TTL=44
Statistiche Ping per 216.58.200.4:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 310ms, Massimo = 311ms, Medio = 310ms
*** Verygames, OVH, Roubaix, Francoforte (gaming) ***
Esecuzione di Ping verygames.net [94.23.214.174] con 32 byte di dati:
Risposta da 94.23.214.174: byte=32 durata=39ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=39ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=39ms TTL=51
Risposta da 94.23.214.174: byte=32 durata=38ms TTL=51
Statistiche Ping per 94.23.214.174:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 38ms, Massimo = 39ms, Medio = 38ms
*** multiplay.co.uk - Inghilterra (gaming) ***
Esecuzione di Ping multiplay.co.uk [85.236.96.26] con 32 byte di dati:
Risposta da 85.236.96.26: byte=32 durata=51ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=49ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=49ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=49ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Risposta da 85.236.96.26: byte=32 durata=50ms TTL=53
Statistiche Ping per 85.236.96.26:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 49ms, Massimo = 51ms, Medio = 49ms
*** Interactive3D - Olanda (gaming) ***
Esecuzione di Ping i3d.net [188.122.94.99] con 32 byte di dati:
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=48ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=46ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=45ms TTL=51
Risposta da 188.122.94.99: byte=32 durata=49ms TTL=51
Statistiche Ping per 188.122.94.99:
Pacchetti: Trasmessi = 10, Ricevuti = 10,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 45ms, Massimo = 49ms, Medio = 46ms
Schifo? Tiscali fa 19/20ms su Milano :D
E comunque Vodafone sta lavorando proprio in questi mesi per migliorare il ping al sud/centro e nord est italia.
:) vabbè comunque per adesso sono in wi-fi col pc pc collegato tramite cavo ad un netgear Nighthawk 7000 che fa da ripetitore sulla 5 Ghz e a 8 metri la Vodafone Station. Domani provo collegando il cavo cat 7 pc-Vodafone Station
Un cagliaritano non può non scegliere Tiscali!!! :D
ho avuto tiscali fino a due anni fa, poi vodafone ha passato la fibra ed ha offerto la FTTC ad un prezzo conveniente e considerando la mia velocità in adsl che era gradualmente scesa dai 12 a 6 Mb/s ho fatto il salto :)
Col passaggio alla FTTH ho pensato di tornare in Tiscali, che tra le altre cose risulta più conveniente fra sconto primo anno e fatturazione mensile, ma per adesso ho preferito aspettare ;)
riccardi.fede
18-10-2017, 18:34
Un mio amico ha attivato Wind FTTH a Torino stamattina e mi ha fatto al volo un tracert vs google. (https://s1.postimg.org/8zwpc2a9j3/Immagine.png)
Ovviamente fatto via cavo e soltanto il pc collegato. Non proprio buonissimo direi...
C'è una cosa che non capisco: l'hop TelecomItalia-p01.wind.it che cos'è esattamente e perchè TIM?
Grande Fede :)
Io ho seguito di recente l'attivazione Infostrada FTTH di un amico, ed i ragazzi che lavoravano mi hanno detto che "le linee" alla fine della fiera le gestisce Telecom, seppur non totalmente come fa con le proprie. Così mi è stato detto e così riferisco, "ambasciator non porta pena" come si suol dire :D
PS:
Il tracert del tuo amico è nella media, cioè non entusiasmante, ma tanto qui si accontentano.. :Prrr: :Prrr: :Prrr:
Ma veramente su FTTH Telecom non ha proprio niente a che fare, dato che l'infrastruttura di accesso è di Open Fiber.
http://textuploader.com/d4vet
Genova, Vodafone FTTH 1000/200 Mb
riccardi.fede
22-10-2017, 17:35
PS:
Il tracert del tuo amico è nella media, cioè non entusiasmante, ma tanto qui si accontentano.. :Prrr: :Prrr: :Prrr:
Si nella media delle FTTC :D per il ping della FTTH non è proprio il massimo ma magari è soltanto un caso. Gli farò fare poi test più approfonditi.
paolo.plp
22-10-2017, 18:14
Padova
FTTH Vodafone con Open Fiber
http://txt.do/d4yol
amd-novello
23-10-2017, 13:04
Si nella media delle FTTC :D per il ping della FTTH non è proprio il massimo ma magari è soltanto un caso. Gli farò fare poi test più approfonditi.
infatti. io fttc wind
https://snag.gy/MX1HCG.jpg
riccardi.fede
23-10-2017, 13:36
infatti. io fttc wind
https://snag.gy/MX1HCG.jpg
Ecco. E nel tuo tracert c'è "Fastweb-p01.wind.it", in quello del mio amico "Telecom..."
Boh non capisco :D
Quegli hostname con Telecomitalia e Fastweb nel nome mi comparivano a volte in ADSL. In FTTC non li ho più visti.
Suppongo siano punti dove avviene il peering tra i due operatori, oppure router Wind ospitati in data center FW o TIM.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.