Quelle est la latence réseau "typique" entre la côte est et la côte ouest des États-Unis ?

Tout le monde ici a des points très valables et a raison dans leur propre point de vue.

Et tout se résume au fait qu'il n'y a pas de réponse exacte ici, car il y a tellement de variables que toute réponse donnée peut toujours être prouvée fausse en changeant simplement l'une des centaines de variables.

Comme les 72 ms de latence de NY à SF est la latence d'un point de présence à un autre d'un transporteur d'un paquet. Cela ne prend pas en compte tous les autres points importants que certains ont soulignés ici concernant la congestion, la perte de paquets, la qualité de service, les paquets hors séquence, la taille des paquets, ou le routage du réseau juste entre le monde parfait du point de présence à un autre.

Et ensuite, lorsque vous ajoutez le dernier kilomètre (généralement plusieurs kilomètres) du point de présence à votre emplacement réel dans les deux villes où toutes ces variables deviennent une chose beaucoup plus fluide, les choses commencent à se développer de manière exponentielle au-delà de toute estimation raisonnable !

Par exemple, j'ai effectué un test entre la ville de New York et San Francisco sur une journée normale de travail. J'ai fait cela un jour où il n'y avait pas de "grands incidents" majeurs se produisant dans le monde qui pourraient entraîner une augmentation du trafic. Donc peut-être que ce n'était pas la moyenne dans le monde d'aujourd'hui! Mais néanmoins, c'était mon test. J'ai effectivement mesuré d'un emplacement commercial à un autre au cours de cette période, et pendant les heures normales de travail de chaque côte.

En même temps, j'ai surveillé les chiffres des fournisseurs de services sur le web.

Les résultats étaient des chiffres de latence compris entre 88 et 100 ms de porte à porte des emplacements commerciaux. Cela n'incluait pas les chiffres de latence du réseau interne.

La latence des réseaux des fournisseurs de services variait entre 70 et 80 ms. Cela signifie que la latence du dernier kilomètre aurait pu varier entre 18 et 30 ms. Je n'ai pas corréler les pics et les baisses exacts entre les deux environnements.

Je constate environ 80-90ms de latence sur des liens bien gérés et bien mesurés entre les côtes Est et Ouest.

Il serait intéressant de voir où vous accumulez de la latence - essayez un outil comme le traceroute de la couche quatre (lft). Il y a de fortes chances que la majeure partie de la latence soit accumulée sur le "dernier kilomètre" (c'est-à-dire chez votre fournisseur local d'accès à Internet).

Il est normal que le temps de transfert soit à peine impacté - la perte de paquets et le jitter sont des mesures plus utiles à examiner lors de l'investigation des différences de temps de transfert entre deux endroits.

Juste pour le plaisir, quand j'ai joué au jeu en ligne Lineage 2 NA depuis l'Europe :

Temps de réponse aux serveurs de la côte Est : ~110-120ms
Temps de réponse aux serveurs de la côte Ouest : ~190-220ms

La différence semble indiquer qu'une marge de jusqu'à 100ms est raisonnable, compte tenu de la nature imprévisible d'Internet.

En utilisant le test de rafraîchissement acclamé de Chrome, j'obtiens un temps de chargement du document qui diffère d'environ 130ms.

Horaires de NYC :

NY     OU
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

En utilisant Chrome, sur une connexion résidentielle.

En utilisant lft depuis un VPS dans un datacenter à Newark, New Jersey :

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Utilisation du périphérique eth0, members.linode.com (97.107.139.108):53
Trace LFT TTL vers 64.34.80.176:80/tcp
 1  207.192.75.2 0,4/0,5ms
 2  vlan804.tbr2.mmu.nac.net (209.123.10.13) 0,4/0,3ms
 3  0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1,3/1,5ms
 4  nyiix.Peer1.net (198.32.160.65) 1,4/1,4ms
 5  oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1,6/1,5ms
 6  216.187.115.145 2,7/2,2ms
 7  64.34.60.28 2,3/1,8ms
 8  [cible ouverte] 64.34.80.176:80 2,5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Utilisation du périphérique eth0, members.linode.com (97.107.139.108):53
Trace LFT TTL vers stackoverflow.com (69.59.196.212):80/tcp
 1  207.192.75.2 36,4/0,6ms
 2  vlan803.tbr1.mmu.nac.net (209.123.10.29) 0,4/0,4ms
 3  0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1,3/1,4ms
 4  nyk-b3-link.telia.net (213.248.99.89) 1,6/1,4ms
 5  nyk-bb2-link.telia.net (80.91.250.94) 1,9/84,8ms
 6  nyk-b5-link.telia.net (80.91.253.106) 1,7/1,7ms
 7  192.205.34.53 2,1/2,1ms
 8  cr1.n54ny.ip.att.net (12.122.81.106) 83,5/83,6ms
 9  cr2.cgcil.ip.att.net (12.122.1.2) 82,7/83,1ms
10  cr2.st6wa.ip.att.net (12.122.31.130) 83,4/83,5ms
11  cr2.ptdor.ip.att.net (12.122.30.149) 82,7/82,7ms
12  gar1.ptdor.ip.att.net (12.123.157.65) 82,2/82,3ms
13  12.118.177.74 82,9/82,8ms
14  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84,1/84,0ms
15  sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83,3/83,4ms
16  ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86,3/86,2ms
**  [negligé] pas de paquets de réponse reçus des TTL 17 à 18
19  [cible fermée] stackoverflow.com (69.59.196.212):80 86,3/86,3ms