Question Combien de temps de latence du réseau est «typique» pour la côte est-ouest des États-Unis?


Pour le moment, nous essayons de décider de déplacer notre centre de données de la côte ouest vers la côte est.

Cependant, je vois des chiffres de latence inquiétants de ma côte ouest à la côte est. Voici un exemple de résultat: récupérer un petit fichier du logo .png dans Google Chrome et utiliser les outils de développement pour voir la durée de la requête:

  • Côte ouest à côte est:
    215 ms de latence, 46 ms de temps de transfert, 261 ms au total
  • Côte ouest à côte ouest:
    114 ms de latence, 41 ms de temps de transfert, 155 ms au total

Il est logique que Corvallis, OR soit géographiquement plus proche de mon emplacement à Berkeley, en Californie, donc je m'attends à ce que la connexion soit un peu plus rapide .. mais je constate une augmentation de la latence de + 100 ms lorsque j'effectue le même test pour NYC serveur. Cela me semble excessif. Particulièrement depuis le temps passé à transférer les données réelles n'a augmenté que de 10%, mais le temps de latence a augmenté de 100%!

Cela me semble… faux… pour moi.

J'ai trouvé ici quelques liens utiles (via Google, pas moins!) ...

... mais rien d'autorité.

Alors, est-ce normal? Cela ne semble pas normal. Quelle est la latence "typique" à laquelle je devrais m'attendre lors du déplacement de paquets réseau de la côte est <-> côte ouest des États-Unis?


99
2018-04-30 11:26


origine


Toute mesure sur des réseaux que vous ne contrôlez pas semble presque inutile. Trop souvent, dans ces types de discussions sur le réseau, il semble que nous oublions qu’un composant temporel est associé à chaque paquet. Si vous avez couru le test à plusieurs reprises 24 heures sur 24, 7 jours sur 7 et que vous en êtes arrivé à une conclusion, c'est une chose. Si vous avez exécuté le test deux fois, je vous suggère de le lancer un peu plus. Et à ceux qui préconisent l'utilisation de ping comme mesure de performance, ne le faites pas. Sur chaque réseau majeur sur lequel j'ai jamais travaillé, nous avons défini le trafic ICMP sur la priorité la plus basse. Ping ne signifie qu'une chose, et ce n'est pas;) des performances. - dbasnett
De là où je vis, à Jefferson City, dans le Missouri, les temps sont similaires. - dbasnett
Comme note latérale: la lumière elle-même prend environ 14 ms pour voyager de NY à SF en ligne droite (en tenant entièrement compte de la fibre). - Shadok
La lumière dans les fibres se déplace avec un facteur de vitesse de 0,67 (équivalent à l'indice de réfraction) ~ 201 000 km / s, donc au moins 20 ms. - Zac67


Réponses:


Vitesse de la lumière:
  Vous n'allez pas battre la vitesse de la lumière en tant que point académique intéressant. Ce lien travaille de Stanford à Boston à environ 40ms du meilleur temps possible. Lorsque cette personne a effectué le calcul, il a décidé qu'Internet fonctionnait environ "dans un facteur de deux de la vitesse de la lumière", ce qui donne un temps de transfert d'environ 85 ms.

Taille de la fenêtre TCP:
Si vous rencontrez des problèmes de vitesse de transfert, vous devrez peut-être augmenter la taille de la fenêtre de réception. Vous devrez peut-être également activer la mise à l'échelle des fenêtres s'il s'agit d'une connexion à bande passante élevée avec une latence élevée (appelée "tuyau long et épais"). Ainsi, si vous transférez un fichier volumineux, vous devez disposer d’une fenêtre de réception suffisamment grande pour remplir le tuyau sans attendre les mises à jour de la fenêtre. Je suis allé dans quelques détails sur la façon de calculer cela dans ma réponse Accorder un éléphant.

Géographie et latence:
Certains points faibles de certains CDN (Content Distribtuion Networks) sont qu’ils associent latence et géographie. Google a effectué de nombreuses recherches sur son réseau et a découvert des failles dans ce domaine. Les résultats ont été publiés dans le livre blanc. Aller au-delà des informations de chemin de bout en bout pour optimiser les performances CDN:

Premièrement, même si la plupart des clients sont   desservi par un CDN géographiquement proche   noeud, une fraction non négligeable de clients   expérimenter des latences plusieurs dizaines de   millisecondes plus élevé que les autres clients   dans la même région. Deuxièmement, nous trouvons   que les retards dans la file d'attente remplacent souvent   les avantages d'un client en interaction   avec un serveur à proximité.

Peerings BGP:
De plus, si vous commencez à étudier le protocole de routage Internet de base (BGP) et la façon dont les fournisseurs de services Internet choisissent les peerings, vous constaterez qu'il s'agit souvent davantage d'une question de finances et de politique. Par conséquent, il se peut que vous n'obteniez pas toujours le "meilleur" chemin vers certaines zones géographiques en fonction de votre fournisseur d'accès . Vous pouvez voir comment votre IP est connectée à d’autres FAI (systèmes autonomes) à l’aide d’un Routeur en verre. Vous pouvez également utiliser un service whois spécial:

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

C’est aussi amusant d’explorer ces liens en tant que peerings avec un outil graphique comme linkrank, il vous donne une image de l’internet autour de vous.


108
2018-04-30 12:03



d’accord, la vitesse de la lumière à vol d'oiseau est ce que vous pouvez faire de mieux. Vraiment excellente réponse d'ailleurs, c'est exactement ce que je cherchais. Je vous remercie. - Jeff Atwood
Pour les curieux, le calcul actuel est: 3000 mi / c = 16.1ms - tylerl
Dans le vide, un photon peut parcourir l'équateur en environ 134 ms. Le même photon dans le verre prend environ 200 ms. Un morceau de fibre de 3 000 km a 24 ms. de délai sans aucun appareil. - dbasnett
Cela me rappelle de L'affaire du courrier électronique à 500 milles. - bahamat


Ce site suggérerait environ 70 à 80 ms de latence entre la côte est / ouest des États-Unis est typique (San Francisco à New York par exemple).

Sentier transatlantique
NY 78 London
Wash 87 Frankfurt
Sentier transpacifique
SF 147 Hong Kong
Chemin trans-américain
SF 72 NY

network latency by world city pairs

Voici mes horaires (je suis à Londres, en Angleterre, donc mes temps sur la côte Ouest sont plus élevés que ceux de l'Est). J'obtiens une différence de latence de 74 ms, ce qui semble confirmer la valeur de ce site.

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

Celles-ci ont été mesurées à l'aide des outils de développement de Google Chrome.


41
2018-04-30 11:45



graphique cool! NY à SF est actuellement 71 ms vous avez raison, nous ne pouvons pas espérer faire mieux que cela. - Jeff Atwood
Merci. Cela m'a beaucoup aidé. C’est une autre source pour rechercher la latence du réseau entre différents endroits du monde - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


Mesurez d'abord avec ICMP, si possible. Les tests ICMP utilisent généralement une très petite charge utile par défaut, n'utilisent pas de négociation à trois voies et ne doivent pas interagir avec une autre application en amont de la pile, contrairement à HTTP. Quoi qu'il en soit, il est de la plus haute importance que les résultats HTTP ne soient pas mêlés aux résultats ICMP. Ce sont des pommes et des oranges.

Aller par le réponse de Rich Adams et en utilisant le site Il a recommandé que, sur le réseau principal d’AT & T, il faut 72 ms pour que le trafic ICMP se déplace entre leurs points de terminaison SF et NY. C'est un chiffre raisonnable, mais vous devez garder à l'esprit qu'il s'agit d'un réseau entièrement contrôlé par AT & T. Il ne tient pas compte de la transition vers votre réseau domestique ou professionnel.

Si vous faites un ping contre careers.stackoverflow.com depuis votre réseau source, vous devriez voir quelque chose qui n’est pas trop éloigné de 72 ms (peut-être +/- 20 ms). Si tel est le cas, vous pouvez probablement supposer que le chemin réseau entre vous deux est correct et qu'il fonctionne dans les limites de la normale. Sinon, ne paniquez pas et mesurez à partir de quelques autres endroits. Ce pourrait être votre fournisseur de services Internet.

En supposant que cela soit fait, votre prochaine étape consiste à aborder la couche d'application et à déterminer s'il y a un problème avec la surcharge supplémentaire que vous constatez avec vos demandes HTTP. Cela peut varier d’une application à l’autre en raison du matériel, du système d’exploitation et de la pile d’applications, mais comme vous disposez d’un équipement à peu près identique sur les côtes est et ouest, les utilisateurs de la côte est pourraient s’approcher des serveurs de la côte ouest et ceux de la côte ouest de l’est. côte. Si les deux sites sont correctement configurés, je m'attendrais à ce que tous les chiffres soient moins égaux et démontrent par conséquent que ce que vous voyez est à peu près équivalent à ce qui est grossier.

Si les temps HTTP varient beaucoup, je ne serais pas surpris qu'il y ait un problème de configuration sur le site dont la performance est la plus lente.

Maintenant, une fois que vous en êtes à ce stade, vous pouvez essayer de faire une optimisation plus agressive du côté de l’application afin de voir si ces chiffres peuvent être réduits du tout. Par exemple, si vous utilisez IIS 7, tirez-vous parti de ses fonctionnalités de mise en cache, etc.? Peut-être que vous pourriez gagner quelque chose là-bas, peut-être pas. En ce qui concerne les éléments de bas niveau tels que les fenêtres TCP, je suis très sceptique sur le fait que cela aurait un impact considérable sur quelque chose comme Stack Overflow. Mais bon, vous ne saurez pas tant que vous n’avez pas essayé et n’avez pas mesuré.


10
2018-04-30 17:34





Plusieurs des réponses ici utilisent ping et traceroute pour leurs explications. Ces outils ont leur place, mais ils ne sont pas fiables pour mesurer les performances du réseau.

En particulier, certains routeurs Juniper (au moins certains) envoient le traitement des événements ICMP au plan de commande du routeur. C'est BEAUCOUP plus lent que le plan de transfert, en particulier dans un routeur de réseau fédérateur.

Dans d'autres circonstances, la réponse ICMP peut être beaucoup plus lente que les performances de transfert réelles d'un routeur. Par exemple, imaginons un routeur entièrement logiciel (sans matériel de transfert spécialisé) représentant 99% de la capacité de la CPU, mais le trafic est néanmoins maintenu dans de bonnes conditions. Voulez-vous qu'il passe de nombreux cycles à traiter les réponses de traceroute ou à transférer le trafic? Le traitement de la réponse est donc une priorité super faible.

En conséquence, ping / traceroute vous donne un prix raisonnable limite supérieure - les choses vont au moins aussi vite - mais ils ne vous disent pas à quelle vitesse le vrai trafic va.

En tout cas -

Voici un exemple de traceroute de l’Université du Michigan (centre des États-Unis) à Stanford (côte ouest des États-Unis). (Il se trouve que vous passez par Washington, DC (côte est des États-Unis), qui se trouve à 500 milles dans la "mauvaise" direction.)

% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130)  3.808 ms  4.225 ms  2.223 ms
 4  l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131)  1.372 ms  1.281 ms  1.485 ms
 5  l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8)  1.784 ms  0.874 ms  0.900 ms
 6  v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69)  2.443 ms  2.412 ms  2.957 ms
 7  v0x1004.rtr.wash.net.internet2.edu (192.122.183.10)  107.269 ms  61.849 ms  47.859 ms
 8  ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6)  28.267 ms  28.756 ms  28.938 ms
 9  xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  52.075 ms  52.156 ms  88.596 ms
10  * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  496.838 ms
11  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133)  76.537 ms  78.948 ms  75.010 ms
12  svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38)  82.151 ms  82.304 ms  82.208 ms
13  hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62)  82.504 ms  82.295 ms  82.884 ms
14  boundarya-rtr.stanford.edu (171.66.0.34)  82.859 ms  82.888 ms  82.930 ms
15  * * *
16  * * *
17  www-v6.stanford.edu (171.67.215.200)  83.136 ms  83.288 ms  83.089 ms

Notez en particulier la différence de temps entre les résultats de traceroute et le lavage routeur et le Atla routeur (sauts 7 et 8). le chemin du réseau va d'abord laver puis atla. le lavage prend entre 50 et 100 ms pour répondre, Atla prend environ 28 ms. Clairement, atla est plus loin, mais ses résultats en matière de traçage suggèrent qu’il est plus proche.

Voir http://www.internet2.edu/performance/ pour beaucoup d'informations sur la mesure du réseau. (disclaimer, je travaillais pour internet2). Regarde aussi: https://fasterdata.es.net/

Pour ajouter une pertinence particulière à la question initiale ... Comme vous pouvez le constater, j’avais un temps de transfert aller-retour de 83 ms pour stanford. Nous savons donc que le réseau peut au moins aller aussi vite.

Notez que le chemin de réseau de recherche et d’éducation que j’ai emprunté sur ce traceroute sera probablement plus rapide qu’un chemin d’internet de base. En règle générale, les réseaux de R & E surapprovisionnent leurs connexions, ce qui rend peu probable la mise en tampon de chaque routeur. Notez également le long chemin physique, plus long d'un océan à l'autre, bien qu'il soit clairement représentatif du trafic réel.

michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford


7
2017-08-15 15:46





Je vois des différences constantes et je suis assis en Norvège:

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

Cela a été mesuré avec la méthode scientifique précise et éprouvée d'utilisation de la vue ressources de Google Chrome et d'actualisation répétée de chaque lien.

Traceroute to serverfault

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

Traceroute aux carrières

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

Malheureusement, il commence maintenant à entrer dans une boucle ou quoi, et continue à donner des étoiles et un délai d’attente jusqu’à 30 sauts, puis se termine.

Remarque, les traceroutes proviennent d'un hôte différent de celui du début. J'ai dû utiliser RDP sur mon serveur hébergé pour les exécuter.


6
2018-04-30 11:43



À droite, on s’attend à ce que le centre de données de la côte Est soit plus convivial pour notre public européen - vous voyez qu’il faut environ 200 ms pour parcourir la largeur des États-Unis. Devrait être seulement ~ 80ms par les autres réponses cependant? - Jeff Atwood
il semble qu'il soit cohérent à environ 200 ms. J'ai cliqué sur l'actualisation environ 20-30 fois maintenant (mais pas en même temps), et le site serverfault semble survoler environ 200 ms +/- de plus que l'autre. . J'ai essayé un traceroute, mais il y a des étoiles sur tout, alors peut-être que nos administrateurs informatiques ont bloqué quelque chose. - Lasse Vågsæther Karlsen


Je vois une latence d’environ 80 à 90 ms sur des liaisons bien gérées et bien mesurées entre les côtes est et ouest.

Il serait intéressant de voir où vous gagnez du temps de latence - essayez un outil tel que le calque quatre traceroute (lft). Il y a de fortes chances que cela soit gagné sur le "dernier kilomètre" (c'est-à-dire chez votre fournisseur de haut débit local).

Il faut s’attendre à ce que le temps de transfert n’ait que très peu été affecté - la perte de paquets et la gigue sont des mesures plus utiles à prendre en compte lors de l’étude des différences de temps de transfert entre deux sites.


2
2018-04-30 11:42





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

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

La différence semble confirmer qu’il est raisonnable de considérer jusqu’à 100 ms, compte tenu de la nature imprévisible de l’Internet.

À l’aide du célèbre test d’actualisation de Google Chrome, le temps de chargement des documents est d’environ 130 ms.


2
2018-04-30 12:52





tout le monde ici a un très bon point. et sont corrects dans leur propre POV.

Et tout se résume à dire qu’il n’ya pas de réponse exacte ici, car il ya tellement de variables que toute réponse donnée peut toujours être fausse simplement en modifiant l’une des cent variables.

Tout comme la latence de 72 ms entre NY et SF, la latence entre PoP et PoP d’une porteuse d’un paquet. Cela ne prend en compte aucun des autres points importants que certains ont mis en avant ici concernant l'encombrement, la perte de paquets, la qualité de service, les paquets en désordre, la taille des paquets ou le réacheminement du réseau entre le monde parfait du PoP à PoP. .

Et ensuite, lorsque vous ajoutez le dernier kilomètre (généralement plusieurs kilomètres) entre le point de présence et votre position actuelle dans les deux villes, toutes ces variables deviennent beaucoup plus fluides et commencent à dégénérer de façon exponentielle en raison d'une capacité de devinette raisonnable!

À titre d’exemple, j’ai effectué un test d’un jour ouvrable entre la ville de New York et SF. Je l'ai fait un jour s'il n'y a pas eu d '"incidents" majeurs dans le monde qui pourraient causer une pointe du trafic. Alors peut-être que ce n'était pas moyen dans le monde d'aujourd'hui! Mais néanmoins c'était mon test. En fait, j'ai mesuré d'un lieu d'affaires à un autre au cours de cette période et pendant les heures normales de bureau de chaque côte.

Dans le même temps, j'ai surveillé les numéros des fournisseurs de circuits sur le Web.

Les résultats ont été des nombres de latence entre 88 et 100 ms de porte à porte des emplacements commerciaux. Cela n'inclut pas les numéros de latence du réseau inter-bureaux.

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


2
2017-09-09 15:43





NYC Timings:

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

Utilisation de Chrome sur une connexion résidentielle.

Utiliser lft depuis un VPS dans un centre de données à Newark, New Jersey:

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 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  [target open] 64.34.80.176:80 2.5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 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
**  [neglected] no reply packets received from TTLs 17 through 18
19  [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms

1
2018-04-30 12:10