Per curiosita', la latenza verso 8.8.8.8 ti e' salita in questi giorni?
Puoi postare un tracert?
Grazie
Esperienza positiva con Dimensione e consegna al Namex
marco89ct Se intendi dal punto di raccolta a Roma... no, è rimasta invariata per me. Dunque, se noti variazioni, sono sicuramente dovute al 'giro' casa tua <-> Roma (competenza Open Fiber).
Potresti postare un tracert verso 8.8.8.8 lo stesso?
A me e' aumentata la latenza verso 8.8.8.8 ma il tratto casa mia <-> Roma e' rimasta invariata.
Grazie
marco89ct traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 100.64.255.255 (100.64.255.255) 14.142 ms 13.717 ms 13.690 ms
2 host13-110-32-195.dimensionesrl.eu (195.32.110.13) 12.816 ms 12.790 ms 12.766 ms
3 google.rom.namex.it (193.201.28.86) 23.048 ms 23.349 ms 24.127 ms
4 74.125.245.241 (74.125.245.241) 23.803 ms 74.125.245.225 (74.125.245.225) 23.259 ms 108.170.245.81 (108.170.245.81) 23.235 ms
5 108.170.232.181 (108.170.232.181) 22.029 ms 108.170.232.169 (108.170.232.169) 23.704 ms 142.251.235.179 (142.251.235.179) 21.979 ms
6 dns.google (8.8.8.8) 21.638 ms 22.072 ms 21.562 ms
- Modificato
Anche io prima pingavo esattamente come te. Arrivavo al primo step in 13ms e a Milano in 22ms con gli stessi tuoi server.
Ma ora faccio questo percorso
Traccia instradamento verso dns.google [8.8.8.8]
su un massimo di 30 punti di passaggio:
1 1 ms 1 ms 1 ms 192.168.1.1
2 16 ms 15 ms 16 ms 100.64.255.255
3 20 ms 42 ms 21 ms host13-110-32-195.dimensionesrl.eu [195.32.110.13]
4 24 ms 29 ms 24 ms 193.201.28.86
5 30 ms 30 ms 29 ms 108.170.245.65
6 25 ms 24 ms 26 ms 142.250.211.21
7 33 ms 29 ms 29 ms dns.google [8.8.8.8]
Giuseppe mi ha spiegato che e' Google a modificare il percorso del peering (tra Roma e Milano). Non sapevo onestamente che potesse accadere.
Inoltre, cosi' come 8.8.8.8, anche altri server hanno subito lo stesso aumento ed e' indipendente da Dimensione.
In base a cosa Google decide che percorso assegnare? Magari siamo anche con la stessa classe di IP.
E' per bilanciare il traffico?
marco89ct leggermente diminuito. dai 21 +- 19
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.2.1 - 0 | 21 | 21 | 0 | 0 | 0 | 0 |
| 100.64.255.255 - 0 | 21 | 21 | 10 | 11 | 12 | 11 |
| host17-110-32-195.dimensionesrl.eu - 0 | 21 | 21 | 10 | 10 | 12 | 11 |
| No response from host - 100 | 4 | 0 | 0 | 0 | 0 | 0 |
| 108.170.245.81 - 0 | 21 | 21 | 19 | 20 | 22 | 22 |
| 142.251.235.175 - 0 | 21 | 21 | 18 | 19 | 20 | 19 |
| dns.google - 0 | 21 | 21 | 19 | 19 | 20 | 20 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider- Modificato
Nel mio caso invece la latenza da Roma a Milano e' salita da 10ms a 16ms (piu' 12ms dalla mia abitazione a Roma che sono invariati) per un totale di 28ms.
Onestamente alle condizioni attuali non mi conviene il passaggio al BRAS di Roma visto che prima col trasporto Open fiber fino a Milano pingavo 22ms. Vediamo Se cambia qualcosa nei prossimi giorni.
- Modificato
Traccia instradamento verso dns.opendns.com [208.67.220.220]
su un massimo di 30 punti di passaggio:
1 1 ms 1 ms 1 ms 192.168.1.1
2 15 ms 15 ms 14 ms 100.64.255.255
3 14 ms 24 ms 17 ms host17-110-32-195.dimensionesrl.eu [195.32.110.17]
4 15 ms 14 ms 14 ms host10-110-32-195.dimensionesrl.eu [195.32.110.10]
5 20 ms 21 ms 21 ms et-0-0-69-2.edge1.Italy2.Level3.net [212.73.241.17]
6 26 ms 23 ms 40 ms ae2.3201.edge1.Milan2.level3.net [4.69.143.114]
7 24 ms 23 ms 24 ms 195.122.183.62
8 29 ms 28 ms 28 ms dns.opendns.com [208.67.220.220]
Traccia completata.
Traccia instradamento verso gamesnet.it [195.36.6.232]
su un massimo di 30 punti di passaggio:
1 1 ms 1 ms 1 ms 192.168.1.1
2 15 ms 15 ms 14 ms 100.64.255.255
3 22 ms 16 ms 14 ms host17-110-32-195.dimensionesrl.eu [195.32.110.17]
4 30 ms 23 ms 26 ms airbeam.rom.namex.it [193.201.28.150]
5 29 ms 30 ms 29 ms telnet.minap.it [185.1.114.4]
6 26 ms 22 ms 22 ms gamesnet.it [195.36.6.232]
Traccia completata.
Traccia instradamento verso gw-noc.uli.it [62.212.3.34]
su un massimo di 30 punti di passaggio:
1 2 ms 1 ms 2 ms 192.168.1.1
2 15 ms 14 ms 14 ms 100.64.255.255
3 17 ms 15 ms 15 ms host17-110-32-195.dimensionesrl.eu [195.32.110.17]
4 15 ms 15 ms 14 ms as5398.rom.namex.it [193.201.28.62]
5 30 ms 30 ms 30 ms 193.221.216.130
6 Ip-77-220-85-78.internetone.it [77.220.85.78] rapporti: Rete di destinazione non raggiungibile.
Come vedi nel secondo tracert arrivo a Milano in 22ms. Mentre negli altri in 28-30ms.
Senza un criterio preciso per alcune destinazioni faccio Roma Milano in 10ms mentre per altre destinazioni sempre a Milano faccio Roma Milano in 16ms. Ma cosa può essere?
marco89ct cosa può essere?
Il giro che fa il percorso inverso.
E perchè solo io prendo il percorso più lungo mentre altri prendono quello più corto?
marco89ct
Sembri nuovamente affetto da una stranezza tipo l'altra volta. 
I traceroute li hai fatti in Wifi? Vedo che sono un pò traballanti e l'hop del router segna 1-2ms.
Comunque senza girarci troppo intorno, se la cosa ti infastidisce particolarmente potresti provare chiedere a Dimensione se gentilmente ti cambiano IP come l'altra volta.
Ma può essere causato del fatto che il mio router manda ping su google per il controllo della latenza ogni 10ms?
marco89ct Va un po' a fortuna in base al proprio indirizzo IP (alcuni AS applicano dei meccanismi di load balancing basati su hash degli IP). In buona sostanza, succederà che su altri AS il percorso più "lungo" al ritorno lo farà qualcun altro, e tu farai magari quello più corto; insomma, stai sereno che questo problema ce l'hanno tutti. Purtroppo, Dimensione non può controllare come e dove gli AS mandano il traffico di ritorno.
Poi potrebbe anche esserci altro, per carità, per questo meglio sentire il buon @gandalf2016 o altri esperti che ci lavorano in prima persona.
- Modificato
marco89ct per il load balancing si usano parametri vari come IP, porte etc... esempio assurdo potrebbe capitare che gli IP dispari si fanno il ritorno da Milano e quelli pari il ritorno da Roma, è una cosa normalissima quando hai "più porte".
Fare un mtr TCP (mtr -T) può farti vedere alcuni di questi percorsi "alternativi" (perché usa src port sempre diverse), ma vedi sempre solo un lato.
- Modificato
Purtroppo non ho altri router
Mi son fatto cambiare l'IP ed ora la situazione è migliorata. Non è ancora perfetta perchè sembra che nel tratto OF a seconda di cosa pingo, arrivo al bras con 3ms di differenza.
Non so come sia possibile ma alcune volte arrivo al bras in 12ms ed altre in 15ms.
Lasciando stare questo ora va meglio.
Esecuzione di Ping 208.67.220.220 con 32 byte di dati:
Risposta da 208.67.220.220: byte=32 durata=24ms TTL=58
Risposta da 208.67.220.220: byte=32 durata=24ms TTL=58
Risposta da 208.67.220.220: byte=32 durata=24ms TTL=58
Risposta da 208.67.220.220: byte=32 durata=24ms TTL=58
Esecuzione di Ping 195.36.6.232 con 32 byte di dati:
Risposta da 195.36.6.232: byte=32 durata=21ms TTL=59
Risposta da 195.36.6.232: byte=32 durata=21ms TTL=59
Risposta da 195.36.6.232: byte=32 durata=21ms TTL=59
Risposta da 195.36.6.232: byte=32 durata=21ms TTL=59
Ad esempio qui si vede anche la differenza
Esecuzione di Ping 1.0.0.1 con 32 byte di dati:
Risposta da 1.0.0.1: byte=32 durata=15ms TTL=60
Risposta da 1.0.0.1: byte=32 durata=15ms TTL=60
Risposta da 1.0.0.1: byte=32 durata=16ms TTL=60
Risposta da 1.0.0.1: byte=32 durata=15ms TTL=60
Esecuzione di Ping 1.1.1.1 con 32 byte di dati:
Risposta da 1.1.1.1: byte=32 durata=12ms TTL=60
Risposta da 1.1.1.1: byte=32 durata=12ms TTL=60
Risposta da 1.1.1.1: byte=32 durata=12ms TTL=60
Risposta da 1.1.1.1: byte=32 durata=12ms TTL=60