Combien de latence réseau est "typique" pour la côte est - côte ouest des États-Unis ?

Tout le monde ici a des points vraiment bons et a raison de son 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 de PoP à PoP d'un transporteur d'un paquet. Cela ne prend pas en compte tous les autres points importants que certains ont soulignés ici sur la congestion, la perte de paquets, la qualité de service, les paquets hors séquence, la taille des paquets, ou le reroutage du réseau juste entre le monde parfait du PoP à PoP.

Et ensuite, lorsque vous ajoutez le dernier mile (généralement de nombreux miles) du PoP à votre emplacement réel au sein des deux villes, où toutes ces variables deviennent une chose beaucoup plus fluide, les choses commencent à s'escalader de manière exponentielle hors de la possibilité de deviner raisonnablement !

À titre d'exemple, j'ai effectué un test entre la ville de NY et SF pendant une journée de travail. J'ai fait cela un jour où il n'y avait pas d'importants "incidents" se produisant dans le monde qui pourraient causer une augmentation du trafic. Peut-être que ce n'était pas une moyenne dans le monde d'aujourd'hui ! Mais c'était quand même mon test. J'ai réellement mesuré d'un lieu de travail à un autre pendant 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 entre 88 et 100 ms de porte à porte des lieux de travail. Cela n'incluait pas les chiffres de latence du réseau entre les bureaux.

La latence des réseaux des fournisseurs de services variait entre 70 et 80 ms. Ce qui signifie que la latence du dernier mile pouvait varier entre 18 et 30 ms. Je n'ai pas fait de corrélation exacte entre les pics et les creux des deux environnements.

Je vois environ 80 à 90 ms 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 gagnez en 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 acquise sur le "dernier kilomètre" (c'est-à-dire chez votre fournisseur de services Internet local).

Il est normal que le temps de transfert ait été légèrement 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 emplacements.

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 de Chrome acclamé, j'obtiens un temps de chargement du document qui diffère d'environ 130ms.

Horaires de NYC :

NY     OR
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 de l'appareil eth0, members.linode.com (97.107.139.108):53
TTL LFT trace 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 de l'appareil eth0, members.linode.com (97.107.139.108):53
TTL LFT trace 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
**  [négligé] aucun paquet de réponse reçu des TTL 17 à 18
19  [cible fermée] stackoverflow.com (69.59.196.212):80 86.3/86.3ms