Ping Impossibile

[bandit]

Posto qui un quesito tecnico per i traders

Ho eseguito il classico comando “ping 8.8.8.8” e mi ha dato 42ms, mi chiedo come sia possibile.

La distanza tra Milano e Palo Alto (sede di Google che si dice avere come IP 8.8.8.8) e' 9593 km, ora la velocita della luce e' 299.792.458 m/s, cioe circa 300k km al secondo come tutti sappiamo, il che significa circa 300 km per millisecondo.

Facendo un piccolo calcolo otteniamo 9593 km / 299792 km / s = 0.032
Quindi ci vogliono 32 millisecondi perche la luce arrivi da Milano a Palo Alto, per tornare il doppio e cioe 64 ms, come faccio ad avere un ping di 42ms?

Chi mi sta rispondendo in realta?

Ora qui su google non mi importa piu di tanto ma se pingate il sito del cme la situazione non cambia ma questo significa che forse c'e' un sito che replica (evidentemente in ritardo) i dati del sito originario.

Vi chiedo se c'e' qualcosa di sbagliato o che mi sfugge, grazie per l'attenzione.

 

[risparmio1]

semplicemente una trasmissione su internet non avviene mai in linea retta.
Ogni volta segue un percorso diretto.
Come se da Milano volessi andare ovunque nel mondo: a volte bisogna fare degli scali..

Prova
tracert 8.8.8.8

ci sono anche dei siti che mostrano il percorso sulla mappa

 

[FogOnLine]

Con il ping 8.8.8.8 stai misurando solo la latenza di un server DNS resolver.

Puoi provare un comando traceoute per verificare il percorso e, eventualmente, la locazione del DNS resolver.

 

[bandit]

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

1 3 ms 5 ms 3 ms ########
2 9 ms 2 ms 3 ms ########
3 1 ms 2 ms 1 ms ########
4 6 ms 9 ms 5 ms ########
5 18 ms 17 ms 19 ms ########
6 15 ms 17 ms 12 ms ########
7 18 ms 18 ms 19 ms ########
8 21 ms 14 ms 14 ms ########
9 48 ms 49 ms 49 ms ########
10 40 ms 42 ms 41 ms ########
11 31 ms 31 ms 31 ms ########
12 34 ms 34 ms 34 ms dns.google [8.8.8.8]
---------------------------------------
244 240 231

Trace complete.
-------------------------------

Grazie mille per la dritta!!!

Ci sono tre colonne immagino che ognuna rappresenti un tentativo, alla fine se ben intendo per arrivare a google ci ha messo 240 ms (le somme le ho messe io), oppure 240 ms e' il tempo in cui e' anche tornato?

Grazie ancora, gentilissimi.

 

[ido]

a parte che 8.8.8.8 è un DNS di Google e non un server che si trova chissà dove, tu parti dal presupposto sbagliato, immagini che ci sia solo un server in tutta internet che risponde a 8.8.8.8
lo stesso (non esattamente, esempio per far capire) succede quando tu digiti facebook punto com, se sei in Italia risponderà un indirizzo IP, se sei in un'altra parte del mondo un IP diverso

 

[bandit]

a parte che 8.8.8.8 è un DNS di Google e non un server che si trova chissà dove, tu parti dal presupposto sbagliato, immagini che ci sia solo un server in tutta internet che risponde a 8.8.8.8
lo stesso (non esattamente, esempio per far capire) succede quando tu digiti facebook punto com, se sei in Italia risponderà un indirizzo IP, se sei in un'altra parte del mondo un IP diverso

I risultati di tracert scopro sono progressivi e non devono essere sommati quindi alla fine il “ping” risultante e’ di soli 34 ms il che significa che non mi sto collegando ad un server in California.
---------
Io vorrei soltanto sapere se esiste un metodo per sapere in quanto tempo mi arriva per esempio il segnale da The New York Stock Exchange | NYSE ed intendo proprio il server di NY che essendo un mercato e non un motore di ricerca deve necessariamente avere un punto comune dove si incrociano le proposte (immagino), in modo da farmi un idea su quanto i dati siano in ritardo e quanto ritardo accumuleranno a questo i miei ordini.

 

[ido]

I risultati di tracert scopro sono progressivi e non devono essere sommati quindi alla fine il “ping” risultante e’ di soli 34 ms il che significa che non mi sto collegando ad un server in California.
---------
Io vorrei soltanto sapere se esiste un metodo per sapere in quanto tempo mi arriva per esempio il segnale da The New York Stock Exchange | NYSE ed intendo proprio il server di NY che essendo un mercato e non un motore di ricerca deve necessariamente avere un punto comune dove si incrociano le proposte (immagino), in modo da farmi un idea su quanto i dati siano in ritardo e quanto ritardo accumuleranno a questo i miei ordini.

visto che il disegnino non te lo posso fare, cerco di spiegarlo in modo più semplice possibile.
nel mondo hai un sito che a caso manda lettere dell'alfabeto (D, H, B, Z, K, ...) e tu ti colleghi al sito.
caso 1: c'è un unico server, il server ha un tot max di connessioni che riesce a reggere (esempio: 500 utenti connessi) e tu avrai un delay sulla ricezione in base alla tua posizione, chi è a 100m dal server riceve i dati prima di chi sta a 100km dal server
caso 2: il sito è "distribuito" (ed è una cosa normalissima, anche se è un sito che gira su un solo server, chi ospita il server ha di solito una struttura che gestisce in trasparenza questa logica (esempio banale: sito su azure e vedi il cookie/token ARRAffinity), per farla semplice, metti ad esempio che il segnale di NYSE viene distribuito prima a 5 server per ogni continente e se tu sei in europa ti collegherai al server europeo, tu non puoi scegliere il tragitto perché è la struttura internet su cui ti appoggi che lo sceglie per te (guardati l'algoritmo di Dijkstra per capire il concetto).
L'unica cosa che tu utente puoi fare è scegliere il server DNS, che è quello che ti calcola il tragitto, magari con i DNS di google hai un ping alto verso NYSE, con quelli di cloudflare avrai un valore diverso, etc etc

 

[bandit]

visto che il disegnino non te lo posso fare, cerco di spiegarlo in modo più semplice possibile.
nel mondo hai un sito che a caso manda lettere dell'alfabeto (D, H, B, Z, K, ...) e tu ti colleghi al sito.
caso 1: c'è un unico server, il server ha un tot max di connessioni che riesce a reggere (esempio: 500 utenti connessi) e tu avrai un delay sulla ricezione in base alla tua posizione, chi è a 100m dal server riceve i dati prima di chi sta a 100km dal server
caso 2: il sito è "distribuito" (ed è una cosa normalissima, anche se è un sito che gira su un solo server, chi ospita il server ha di solito una struttura che gestisce in trasparenza questa logica (esempio banale: sito su azure e vedi il cookie/token ARRAffinity), per farla semplice, metti ad esempio che il segnale di NYSE viene distribuito prima a 5 server per ogni continente e se tu sei in europa ti collegherai al server europeo, tu non puoi scegliere il tragitto perché è la struttura internet su cui ti appoggi che lo sceglie per te (guardati l'algoritmo di Dijkstra per capire il concetto).
L'unica cosa che tu utente puoi fare è scegliere il server DNS, che è quello che ti calcola il tragitto, magari con i DNS di google hai un ping alto verso NYSE, con quelli di cloudflare avrai un valore diverso, etc etc

Grazie della spiegazione,

Alla fine mi sembra di capire che posso solo sapere il tempo tra me e il server “europeo”, il ritardo tra il NY e il server che mi distribuisce il segnale non posso conoscerlo (anche se essendo oltre oceano posso immaginare minimo 25 ms).

 

[ido]

Grazie della spiegazione,

Alla fine mi sembra di capire che posso solo sapere il tempo tra me e il server “europeo”, il ritardo tra il NY e il server che mi distribuisce il segnale non posso conoscerlo (anche se essendo oltre oceano posso immaginare minimo 25 ms).

esatto, ma oltre al discorso della connessione, a te secondo me importano più i tempi sul dato grezzo che ti deve arrivare (o inviare).
Qui hai una distinzione tra dati su cui può essere sfruttata la cache e dati su cui non è possibile farla direttamente.
esempio: il server ha una pagina che restituisce la data con l'ora di inizio effettiva, oggi può essere 8:10, domani 9:00, dopodomani 8:15, ...
questo è un dato che sapendo già a prescindere che durerà X ore senza essere cambiato verrà restituito a te dal server "europeo" senza che il server "europeo" vada a chiedere al server di NY il valore, diverso il caso di un valore di una azione nel momento X, magari il server "europeo" ha una cache che dura 5 secondi, e ogni 5 secondi va a prendersi il nuovo valore (e quindi se chiedi adesso e tra 4 secondi riceverai lo stesso valore), poi hai cache variabili, diversi modi di aggiornare la cache, etc etc.
inoltre il dato dovrà stare da qualche parte (disco, ram) per essere trasmesso a te, resta il fatto che dal lato tuo puoi solo gestire due cose, il provider che ti dà internet (es: openfiber con fibra oppure tim con rame) e il server dns. Poi se lato tuo hai altri colli di bottiglia (es: hai la gigabit ma la scheda di rete nel tuo pc va a 100mbit) sono altre questioni, ma dal punto A al punto B è solo infrastruttura di rete e il percorso scelto dal server dns

 

[bandit]

esatto, ma oltre al discorso della connessione, a te secondo me importano più i tempi sul dato grezzo che ti deve arrivare (o inviare).
Qui hai una distinzione tra dati su cui può essere sfruttata la cache e dati su cui non è possibile farla direttamente.
esempio: il server ha una pagina che restituisce la data con l'ora di inizio effettiva, oggi può essere 8:10, domani 9:00, dopodomani 8:15, ...
questo è un dato che sapendo già a prescindere che durerà X ore senza essere cambiato verrà restituito a te dal server "europeo" senza che il server "europeo" vada a chiedere al server di NY il valore, diverso il caso di un valore di una azione nel momento X, magari il server "europeo" ha una cache che dura 5 secondi, e ogni 5 secondi va a prendersi il nuovo valore (e quindi se chiedi adesso e tra 4 secondi riceverai lo stesso valore), poi hai cache variabili, diversi modi di aggiornare la cache, etc etc.
inoltre il dato dovrà stare da qualche parte (disco, ram) per essere trasmesso a te, resta il fatto che dal lato tuo puoi solo gestire due cose, il provider che ti dà internet (es: openfiber con fibra oppure tim con rame) e il server dns. Poi se lato tuo hai altri colli di bottiglia (es: hai la gigabit ma la scheda di rete nel tuo pc va a 100mbit) sono altre questioni, ma dal punto A al punto B è solo infrastruttura di rete e il percorso scelto dal server dns

Spero proprio che un fornitore di dati di mercato non li mandi a pacchetti ogni 5 sec, sarebbe assurdo, sto provando svariati dsn e per il momento “comodo dsn” mi da un risultato migliore sia di google che di cloudflare, devo provare a fare il tracert dei vari dsn per vedere se alcuni di loro utilizzano meno nodi per arrivare a dama, scheda, cavo (per non sbagliare ho messo un CAT8) credo siano ok, del wifi non mi fido.

Intanto grazie per le spiegazioni e il tempo.