Strano aumento di ping

tnvir06

Ci sono degli errori in quel topic. Da Catania non si puo' arrivare a Milano in meno di 20ms. Generalmente ci vogliono dai 25-30ms sia con OF che Telecom.

@MiloZ
Questo era un test che avevo postato quando con Dimensione ero su loro BRAS di Milano.

Esecuzione di Ping xs4all.nl [99.83.136.155] con 32 byte di dati:
Risposta da 99.83.136.155: byte=32 durata=30ms TTL=250
Risposta da 99.83.136.155: byte=32 durata=27ms TTL=250
Risposta da 99.83.136.155: byte=32 durata=28ms TTL=250
Risposta da 99.83.136.155: byte=32 durata=28ms TTL=250

Esecuzione di Ping xs4all.nl [75.2.72.204] con 32 byte di dati:
Risposta da 75.2.72.204: byte=32 durata=23ms TTL=250
Risposta da 75.2.72.204: byte=32 durata=23ms TTL=250
Risposta da 75.2.72.204: byte=32 durata=23ms TTL=250
Risposta da 75.2.72.204: byte=32 durata=22ms TTL=250

Come vedi pingavo i due server localizzati al Mix di Milano in modo diverso. Ma dal LG di Dimensione selezionando server 1 e 2 a Milano le latenze erano vicino allo zero. Questo conferma che entrambi i server 99.83.136.155 e 75.2.72.204 sono a Milano ma per qualche motivo arrivavo a Milano su percorsi diversi dovuti a Open Fiber.

Lo stesso avviene con altri ISP ed altri router. L'unica variabile quindi rimane Open Fiber.

marco89ct
In questi traceroute la tratta OF è identica:
Cambiano i carrier ed i server e quindi cambia la latenza. Uno lo raggiungi via peering, l’altro via transito.

In un caso vai su MIX ,nell’altro su Sparkle, prese anche presumibilmente in PoP diversi

Hai sotto mano la linea FT ora per fare test?

Anche nel test post modifica sulla linea dimensione, sono IP diversi.
Serve il routing anche dall’altro lato, verso il tuo di IP, come ha fatto notare @MiloZ… altrimenti è impossibile capirci qualcosa

@gandalf2016

Hai dei server su Roma che posso testare?

Visto che ora ho il BRAS a Roma meglio testare un server subito dopo il BRAS cosi' si evita impatti dovuti alla tratta successiva.

Guardate questo test che avevo postato quando ero con Dimensione BRAS Milano

Esecuzione di Ping 100.64.255.255 con 32 byte di dati:
Risposta da 100.64.255.255: byte=32 durata=28ms TTL=118
Risposta da 100.64.255.255: byte=32 durata=27ms TTL=118
Risposta da 100.64.255.255: byte=32 durata=28ms TTL=118
Risposta da 100.64.255.255: byte=32 durata=28ms TTL=118

Esecuzione di Ping 8.8.8.8 con 32 byte di dati:
Risposta da 8.8.8.8: byte=32 durata=23ms TTL=118
Risposta da 8.8.8.8: byte=32 durata=22ms TTL=118
Risposta da 8.8.8.8: byte=32 durata=22ms TTL=118
Risposta da 8.8.8.8: byte=32 durata=22ms TTL=118

Pingavo il BRAS di Milano piu' del DNS google che sta DOPO il bras.

marco89ct se sei su fibertelecom il loro server di Speedtest.
Idem per dimensione. Prova prima con roba locale nell’operatore

Così togliamo le variabili peering e transito

speed-rm.dimensione.com per dimensione Roma
speed-mix.dimensione.com Milano

Per fibertelecom prendi Milano:
test2.fibertelecom.it

gandalf2016

Allora, sia dal Looking Glass di Dimensione e FT usando i loro server di Roma mi pingo circa in 20ms.

Mentre se io faccio un ping su:
1.1.1.1 (Roma) pingo 12ms
8.8.4.4 (Milano) pingo 20ms.
8.8.8.8 (Milano) pingo 28ms
Se pingo il mio BRAS a Roma faccio 20ms

Visto che e' tutto incoerente?

Stessa cosa di quando era con Dimensione sul BRAS di Milano e Roma.

marco89ct

Mentre con IPv6 la situazione è differente?

marco89ct Come vedi pingavo i due server localizzati al Mix di Milano in modo diverso. Ma dal LG di Dimensione selezionando server 1 e 2 a Milano le latenze erano vicino allo zero. Questo conferma che entrambi i server 99.83.136.155 e 75.2.72.204 sono a Milano ma per qualche motivo arrivavo a Milano su percorsi diversi dovuti a Open Fiber.

Se li pinghi usando una VPN come hai scritto prima le latenze sono uguali?
Non è che se due server sono a Milano devi pingarli necessariamente identici, devi vedere anche il percorso di ritorno. Anche io a volte ho delle latenze che differiscono leggermente dal LG.

Quando avevo una Openinternet ad esempio pingavo i DNS di google in maniera diversa perchè uno rientrava dal NAMEX (solo al ritorno) invece che dal MIX e la cosa si alternava al cambiare dell'IP della linea.
Stessa cosa succede con Air2bite che rientra dal NAMEX per molti server AWS\Google anche per gli utenti attestati su Milano.

Comunque, non voglio escludere che nel tuo caso le motivazioni di quel comportamento possano essere dovute ad altro, prima però vorrei visionare qualche traceroute inverso, cioè verso la tua linea, ma non dal Looking Glass ma da qualche server che puoi pure pingare direttamente.

Per i server sui quali registri una latenza maggiore di qualche ms puoi provare a farci un ping -n 100 per verificare se di tanto in tanto arrivassero delle richieste con un valore più basso

MiloZ

SENZA VPN

Esecuzione di Ping 8.8.8.8 con 32 byte di dati:
Risposta da 8.8.8.8: byte=32 durata=28ms TTL=59
Risposta da 8.8.8.8: byte=32 durata=27ms TTL=59
Risposta da 8.8.8.8: byte=32 durata=26ms TTL=59
Risposta da 8.8.8.8: byte=32 durata=26ms TTL=59

Esecuzione di Ping 8.8.4.4 con 32 byte di dati:
Risposta da 8.8.4.4: byte=32 durata=20ms TTL=117
Risposta da 8.8.4.4: byte=32 durata=21ms TTL=117
Risposta da 8.8.4.4: byte=32 durata=20ms TTL=117
Risposta da 8.8.4.4: byte=32 durata=21ms TTL=117

Esecuzione di Ping 208.67.222.222 con 32 byte di dati:
Risposta da 208.67.222.222: byte=32 durata=27ms TTL=59
Risposta da 208.67.222.222: byte=32 durata=27ms TTL=59
Risposta da 208.67.222.222: byte=32 durata=26ms TTL=59
Risposta da 208.67.222.222: byte=32 durata=26ms TTL=59

CON VPN (Express VPN server Milano)

Esecuzione di Ping 8.8.8.8 con 32 byte di dati:
Risposta da 8.8.8.8: byte=32 durata=23ms TTL=116
Risposta da 8.8.8.8: byte=32 durata=23ms TTL=116
Risposta da 8.8.8.8: byte=32 durata=22ms TTL=116
Risposta da 8.8.8.8: byte=32 durata=22ms TTL=116

Esecuzione di Ping 8.8.4.4 con 32 byte di dati:
Risposta da 8.8.4.4: byte=32 durata=22ms TTL=117
Risposta da 8.8.4.4: byte=32 durata=23ms TTL=117
Risposta da 8.8.4.4: byte=32 durata=23ms TTL=117
Risposta da 8.8.4.4: byte=32 durata=22ms TTL=117

Esecuzione di Ping 208.67.222.222 con 32 byte di dati:
Risposta da 208.67.222.222: byte=32 durata=23ms TTL=58
Risposta da 208.67.222.222: byte=32 durata=23ms TTL=58
Risposta da 208.67.222.222: byte=32 durata=23ms TTL=58
Risposta da 208.67.222.222: byte=32 durata=23ms TTL=58

Tutti i problemi con la VPN spariscono e pingo in modo coerente tutti i server a Milano (circa 22ms).

Lenn anche io ho avuto un aumento di circa di 2ms

Ma questo messaggio è una presa in giro giusto?!

Lo spero perché sennò è da mandato di cattura da parte del RIPE o dell'ICANN perdonami

Tralascio la questione di quanto possano essere empirici o realistici (cosa non comune eh) i test di misura RTT e velocità di navigazione per via delle impostazioni che riservano più o meno priorità e accuratezza (e quindi risorse) a questi servizi

Avete la vaga idea di quanto siano 2/5/10/20ms? Molto meno della durata del suono che si produce schioccando le dita in un ambiente domestico, ma soprattutto, di quanto effettivamente influiscano sull'esperienza giornaliera di connessione (gaming compreso)?

Nulla...solo in alcuni giochi online molto competitivi oltre i 30-40ms inizia ad essere fastidioso per le persone che sono particolarmente più sensibili della media, specie se il valore non è abbastanza stabile.

(Negli E-Sports professionali è usato anche come variabile per il calcolo difficoltà sia in modo direttamente controllato che involontariamente e naturalmente presente)

Nella navigazione web però è quasi impercettibile anche a 150-200ms a patto che la reattività sia sempre stabile intorno a tale valore. Il rapporto di misura ms/fluidità è diverso qui come lo è ancora in altra misura nel VoIP

Questo discorso non c'entra nulla con Dimensione direttamente sia in senso positivo che negativo ma è un concetto molto generico su come funziona effettivamente la commutazione di pacchetti e l'impatto che ne deriva dalla sua reattività nonché il ping

gandalf2016

C’è una cosa che mi perplime: il primo hop di dimensione ha sempre latenza costante e cambiano tutti gli altri?

Non ha sempre latenza costante il primo hop sia con Dimensione che con Fiber telecom. Ogni volta che chiedevo cambio di IP con entrambi operatori il primo hop pingava 12ms oppure 20ms.

Potrebbe essere però anche lato provider, semplicemente sugli hashing degli IP.

Con Dimensione BRAS Roma si. Essendo Level3 a trasportare il traffico da Roma a Milano ho notato che anche loro usano 2 instradamenti con latenze diverse. E quando ho beccato sia OF con l'instradamento lungo che Level3 con l'instradamento lungo pingavo da Catania a Milano in 34ms. Esattamente per questo motivo sono passato con FT con BRAS Roma perchè il tratto Roma-Milano avviene sempre in 8-9ms. Forse hanno due linee di fibre con non molta differenza a livello di instradamento. In questo modo quando becco l'instradamento corto di OF pingo Milano in 20ms. Valore incredibilmente basso per la mia posizione geografica (in area bianca).

Torna che con un balancing del genere la VPN sia sempre instradata su percorso con latenza minore o maggiore e non cambi.

Esatto. Ho riprovato di nuovo la VPN ed ora pingavo tutti i server che riportavo sopra non più 22ms ma 28ms.
Ma sono tutti ugualmente 28ms. Quindi ho beccato solo l'instradamento più lungo.

Tecnicamente è possibile Openfiber bilanci su coppie ip sorgente e destinazione e relativi MAC. Nel percorso che ti collega al provider.

Credo che hai risolto l'arcano