Vraag Hoeveel netwerklatentie is "typisch" voor oost - westkust de VS?


Op dit moment proberen we te beslissen of we ons datacenter van de westkust naar de oostkust willen verplaatsen.

Ik zie echter enkele verontrustende latency-nummers van mijn westkustlocatie naar de oostkust. Hier is een voorbeeldresultaat, een klein .png-logobestand ophalen in Google Chrome en de dev-gereedschappen gebruiken om te zien hoe lang het verzoek duurt:

  • Westkust tot oostkust:
    215 ms latentie, 46 ms overdrachttijd, 261 ms totaal
  • Westkust naar westkust:
    114 ms latentie, overdrachtstijd van 41 ms, 155 ms totaal

Het is logisch dat Corvallis, OR geografisch dichter bij mijn locatie in Berkeley, Californië ligt, dus ik verwacht dat de verbinding een beetje sneller is .. maar ik zie een toename in latency van + 100ms wanneer ik dezelfde test naar de NYC voer server. Dat lijkt mij overdreven. Vooral sindsdien de tijd besteed aan het overdragen van de feitelijke gegevens steeg slechts met 10%, maar de latentie steeg met 100%!

Dat voelt ... verkeerd ... voor mij.

Ik vond hier een paar links die nuttig waren (via Google niet minder!) ...

... maar niets gezaghebbends.

Dus, is dit normaal? Het voelt niet normaal. Wat is de "typische" latentie die ik mag verwachten bij het verplaatsen van netwerkpakketten van de oostkust <-> westkust van de VS?


99
2018-04-30 11:26


oorsprong


Elke meting in netwerken die u niet beheert lijkt bijna zinloos. Te vaak in dit soort netwerkdiscussies lijkt het erop dat we vergeten dat er een tijdscomponent is verbonden aan elk pakket. Als je de test herhaaldelijk 24 x 7 hebt uitgevoerd en tot een conclusie bent gekomen, is dat één ding. Als je de test twee keer hebt uitgevoerd, raad ik aan dat je de test nog een keer uitvoert. En degenen die pleiten voor het gebruik van ping als een maat voor de prestaties, doe het niet. Op elk groot netwerk waar ik ooit aan heb gewerkt, stellen we ICMP-verkeer op de laagste prioriteit. Ping betekent maar één ding, en het is niet;) over prestaties. - dbasnett
Van waar ik woon, Jefferson City, MO, zijn de tijden vergelijkbaar. - dbasnett
Als een kanttekening: het licht zelf neemt ~ 14ms om in rechte lijn van New York naar SF te reizen (denk aan fiber helemaal). - Shadok
Licht in vezel reist met een snelheidsfactor van 0,67 (equivalent aan de brekingsindex) ~ 201.000 km / s, dus het is ten minste 20 ms. - Zac67


antwoorden:


Lichtsnelheid:
  Je gaat niet de snelheid van het licht verslaan als een interessant academisch punt. Deze link werkt Stanford naar Boston op ~ 40ms best mogelijke tijd. Toen deze persoon de berekening deed, besloot hij dat het internet ongeveer "binnen een factor twee van de snelheid van het licht" werkte, dus er is ongeveer overdrachtstijd van ~ 85ms.

TCP Window Size:
Als u problemen hebt met de overdrachtsnelheid, moet u mogelijk de ontvangst-tcp-grootte van het ontvangstvenster vergroten. Mogelijk moet u ook vensterafstemming inschakelen als dit een hoge bandbreedteverbinding is met hoge latency (een "Long Fat Pipe" genoemd). Dus als u een groot bestand overdraagt, moet u een groot genoeg ontvangend venster hebben om de pijp te vullen zonder te wachten op vensterupdates. Ik ging in detail in hoe ik dat in mijn antwoord moest berekenen Een olifant afstemmen.

Geografie en Latency:
Een tekortkoming van sommige CDN's (Content Distribtuion Networks) is dat ze latentie en geografie gelijkstellen. Google deed veel onderzoek met hun netwerk en ontdekte daarin tekortkomingen, ze publiceerden de resultaten in het witboek Verder gaan dan end-to-end padinformatie om CDN-prestaties te optimaliseren:

Ten eerste, ook al zijn de meeste klanten   geserveerd door een geografisch nabijgelegen CDN   knooppunt, een aanzienlijk deel van de klanten   ervaar latencies enkele tientallen   milliseconden hoger dan andere clients   in dezelfde regio. Ten tweede vinden we   die vertragingen in de wachtrij hebben vaak voorrang   de voordelen van interactie tussen een klant   met een server in de buurt.

BGP Peerings:
Ook als u begint met het bestuderen van BGP (core internet routing protocol) en hoe ISP's kiezen voor peerings, zult u merken dat het vaak meer om financiën en politiek gaat, waardoor u niet altijd de 'beste' route naar bepaalde geografische locaties krijgt, afhankelijk van uw ISP . U kunt kijken hoe uw IP is verbonden met andere ISP's (Autonomous Systems) met behulp van een op zoek naar glasrouter. U kunt ook een speciale whois-service:

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

Het is ook leuk om deze te verkennen als peerings met een gui-tool zoals linkrank, het geeft je een beeld van het internet om je heen.


108
2018-04-30 12:03



akkoord, lichtsnelheid in vogelvlucht is het beste wat je mogelijk kunt doen. Echt een uitstekend antwoord trouwens, dit is precies wat ik zocht. Dank je. - Jeff Atwood
Voor nieuwsgierigen is de werkelijke wiskunde: 3000 mi / c = 16,1 ms - tylerl
In een vacuüm kan een foton in ongeveer 134 ms de evenaar passeren. Hetzelfde foton in glas zou ongeveer 200 ms duren. Een 3.000 mijl stuk vezel heeft 24 ms. van vertraging zonder apparaten. - dbasnett
Dit doet me denken aan De zaak van de 500 mijl e-mail. - bahamat


Deze site zou suggereren dat de latentie tussen 70-80ms tussen oost / westkust de VS typisch is (bijvoorbeeld San Francisco tot New York).

Trans-Atlantische pad
NY 78 Londen
Was 87 Frankfurt
Trans-Pacific Path
SF 147 Hong Kong
Trans-VS-pad
SF 72 NY

network latency by world city pairs

Dit zijn mijn timings (ik ben in Londen, Engeland, dus mijn tijden aan de westkust zijn hoger dan in het oosten). Ik krijg een vertragingsverschil van 74 ms, wat de waarde van die site lijkt te ondersteunen.

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

Deze werden gemeten met behulp van Google Chrome dev-tools.


41
2018-04-30 11:45



coole kaart! NY naar SF is momenteel 71 ms erop, dus je hebt gelijk - we kunnen niet verwachten dat het beter zal doen. - Jeff Atwood
Bedankt. Het heeft me veel geholpen. Dit is een andere bron om te zoeken naar netwerklatentie tussen verschillende plaatsen in de wereld - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


Meet eerst met ICMP als dat enigszins mogelijk is. ICMP-tests gebruiken standaard standaard een zeer kleine payload, maken geen gebruik van een drieweg-handshake en hoeven niet te interageren met een andere applicatie in de stack zoals HTTP doet. Hoe dan ook, het is van het grootste belang dat HTTP-resultaten niet worden vermengd met ICMP-resultaten. Het zijn appels en sinaasappels.

Gaan bij de antwoord van Rich Adams en gebruiken de website die hij aanraadde, dat zie je aan de backbone van AT & T, het duurt 72 ms voor ICMP-verkeer om tussen hun SF- en NY-eindpunten te bewegen. Dat is een redelijk aantal om voorbij te gaan, maar u moet in gedachten houden dat dit zich op een netwerk bevindt dat volledig wordt beheerd door AT & T. Er wordt geen rekening gehouden met de overgang naar uw thuis- of kantoornetwerk.

Als u vanuit uw bronnetwerk een ping uitvoert tegen careers.stackoverflow.com, zou u iets moeten zien dat niet al te ver weg is van 72 ms (misschien +/- 20 ms). Als dat het geval is, kun je waarschijnlijk aannemen dat het netwerkpad tussen jullie twee in orde is en binnen normale bereiken loopt. Zo niet, raak dan niet in paniek en meet vanaf een paar andere plaatsen. Het kan uw ISP zijn.

Ervan uitgaande dat dit is aangenomen, is de volgende stap om de applicatielaag aan te pakken en te bepalen of er iets mis is met de extra overhead die u ziet met uw HTTP-aanvragen. Dit kan variëren van app tot app vanwege hardware, besturingssysteem en toepassingsstack, maar aangezien je ongeveer identieke apparatuur hebt aan zowel de oost- als de westkust, kun je gebruikers van oostkust de servers aan de westkust laten raken en gebruikers van westkust het oosten raken kust. Als beide sites goed zijn geconfigureerd, zou ik verwachten dat alle getallen minder gelijk zijn en daarom aantonen dat wat u ziet vrijwel gelijk is aan grof.

Als die HTTP-tijden een grote variantie hebben, zou ik niet verbaasd zijn als er een configuratieprobleem was op de langzamer presterende site.

Nu, zodra u op dit punt bent, kunt u proberen een meer agressieve optimalisatie aan de app-kant uit te voeren om te zien of die getallen helemaal kunnen worden verminderd. Als u bijvoorbeeld IIS 7 gebruikt, profiteert u van de cachingmogelijkheden, enz.? Misschien kun je daar iets winnen, misschien ook niet. Als het gaat om het aanpassen van items op een laag niveau, zoals TCP-vensters, ben ik erg sceptisch dat het veel invloed zou hebben op zoiets als Stack Overflow. Maar goed, je zult het niet weten tot je het probeert en meet.


10
2018-04-30 17:34





Verschillende van de antwoorden hier gebruiken ping en traceroute voor hun uitleg. Deze tools hebben hun plaats, maar ze zijn niet betrouwbaar voor netwerkprestatiemetingen.

Met name (tenminste sommige) Juniper-routers verzenden de verwerking van ICMP-gebeurtenissen naar het besturingsvlak van de router. Dit is VEEL langzamer dan het doorstuurvlak, vooral in een backbone-router.

Er zijn andere omstandigheden waarbij het ICMP-antwoord veel langzamer kan zijn dan de daadwerkelijke doorstuurprestaties van een router. Stel je bijvoorbeeld een router voor alle software voor (geen gespecialiseerde doorstuurhardware) die 99% van de CPU-capaciteit heeft, maar het verkeer is nog steeds prima. Wilt u dat het een groot aantal cycli besteedt aan het verwerken van traceroute-reacties of het doorsturen van verkeer? Dus het verwerken van de respons heeft een super lage prioriteit.

Als gevolg hiervan geeft ping / traceroute u redelijk bovengrenzen - dingen gaan op zijn minst zo snel - maar ze vertellen je niet echt hoe snel het echte verkeer gaat.

In ieder geval -

Hier is een voorbeeld van een traceroute van de Universiteit van Michigan (centraal VS) naar Stanford (westkust VS). (Het gebeurt toevallig via Washington, DC (oostkust VS), dat is 500 mijl in de "verkeerde" richting.)

% 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

Let in het bijzonder op het tijdsverschil tussen de traceroute resultaten van de wassen router en de atla router (hop 7 en 8). het netwerkpad gaat eerst wassen en dan naar atla. wassen duurt 50-100 ms om te reageren, Atla duurt ongeveer 28ms. Het is duidelijk dat Atla verder weg is, maar de traceroute-resultaten suggereren dat het dichterbij is.

Zien http://www.internet2.edu/performance/ voor veel informatie over netwerkmetingen. (disclaimer, ik werkte vroeger voor internet2). Zie ook: https://fasterdata.es.net/

Om een ​​specifieke relevantie toe te voegen aan de oorspronkelijke vraag ... Zoals je ziet had ik een ping-pingtijd van 83 ms naar Stanford, dus we weten dat het netwerk op zijn minst zo snel kan gaan.

Merk op dat het netwerkpad van onderzoek en onderwijs dat ik op deze traceroute volgde waarschijnlijk sneller zal zijn dan een internettraject voor grondstoffen. R & E-netwerken overschrijven over het algemeen hun verbindingen, wat het bufferen in elke router onwaarschijnlijk maakt. Let ook op het lange fysieke pad, langer dan de kust tot de kust, hoewel het duidelijk representatief is voor echt verkeer.

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


7
2017-08-15 15:46





Ik zie consistente verschillen en ik zit in Noorwegen:

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

Dit werd gemeten met de wetenschappelijk nauwkeurige en beproefde methode om de resourceweergave van Google Chrome te gebruiken en gewoon elke link telkens opnieuw op te frissen.

Traceroute naar 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 naar 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.

Helaas begint het nu in een lus te gaan ofzo en blijft het sterren en time-out geven tot 30 hoppen en dan eindigt het.

Let op, de traceroutes zijn van een andere host dan de timings aan het begin, ik moest RDP naar mijn gehoste server om ze uit te voeren


6
2018-04-30 11:43



toch, naar verwachting zal het datacenter aan de oostkust vriendelijker zijn voor ons Europese publiek - u ziet ongeveer + 200ms tijd die u nodig hebt om de breedte van de VS te doorkruisen. Zou het maar ~ 80ms per andere antwoorden moeten zijn? - Jeff Atwood
het ziet ernaar uit dat het consistent is op ongeveer 200ms, ik heb nu ongeveer 20-30 keer op beide vernieuwd (niet tegelijkertijd echter) en de serverfault-site ziet eruit alsof het ongeveer 200 ms +/- meer zweeft dan de andere . Ik heb een traceroute geprobeerd, maar het komt met sterren op alles, dus misschien hebben onze IT-beheerders iets geblokkeerd. - Lasse Vågsæther Karlsen


Ik zie ongeveer 80-90ms latency op goed gerunde, goed gemeten verbindingen tussen oost- en westkusten.

Het zou interessant zijn om te zien waar u latentie krijgt - probeer een tool zoals laag-vier traceroute (lft). De kans bestaat dat veel van het wordt opgedaan op de "laatste mijl" (dat wil zeggen bij uw lokale breedbandprovider).

Dat de overdrachtstijd slechts een klein beetje werd beïnvloed, is te verwachten - pakketverlies en jitter zijn nuttiger metingen om naar te kijken bij het onderzoeken van overdrachtsverschillen tussen twee locaties.


2
2018-04-30 11:42





Gewoon voor de lol, toen ik de online game Lineage 2 NA-release vanuit Europa speelde:

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

Het verschil lijkt te ondersteunen dat tot 100ms redelijk is, gezien de onvoorspelbare aard van internet.

Met behulp van de veelgeprezen Chrome-vernieuwingstest, krijg ik documenttijd die verschilt met ongeveer 130ms.


2
2018-04-30 12:52





iedereen hier heeft een heel goed punt. en zijn correct in hun eigen POV.

En het komt er allemaal op neer dat er hier geen echt exact antwoord is, omdat er zoveel variabel zijn dat elk gegeven antwoord altijd fout kan worden bewezen door een van de honderd variabelen te veranderen.

Net als de 72 ms NY naar SF is latentie de latentie van PoP naar PoP van een pakketdrager. Dit houdt geen rekening met de andere geweldige punten die sommigen hier hebben opgemerkt over congestie, pakketverlies, kwaliteit van de dienstverlening, niet-werkende pakketten of pakketgrootte, of netwerkomleiding alleen tussen de perfecte wereld van de PoP to PoP .

En dan, wanneer je de laatste mijl (meestal vele mijlen) van de PoP toevoegt aan je werkelijke locatie in de twee steden waar al deze variabelen veel vloeiender worden, begin dan exponentieel te groeien uit redelijke schatting!

Als voorbeeld heb ik een test uitgevoerd tussen NY city en SF van de loop van een werkdag. Ik deed dit op een dag dat er geen grote 'incidenten' over de hele wereld plaatsvonden die een piek in het verkeer zouden veroorzaken. Dus misschien was dit niet gemiddeld in de wereld van vandaag! Maar toch was het mijn test. Ik heb in deze periode, en tijdens normale openingstijden van elke kust, van de ene bedrijfslocatie naar de andere gemeten.

Tegelijkertijd heb ik de nummers van circuitproviders op het web gecontroleerd.

De resultaten waren latentienummers van 88 tot 100 ms van deur tot deur van de bedrijfslocaties. Dit omvatte geen latency-nummers van een netwerk van een netwerk.

De netwerkwachttijd van de serviceprovider lag tussen 70 en 80 ms. Dit betekent dat de latentie van de laatste mijl tussen 18 en 30 ms had kunnen liggen. Ik heb de exacte pieken en dalen tussen de twee omgevingen niet gecorreleerd.


2
2017-09-09 15:43





NYC Timings:

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

Chrome gebruiken, op een residentiële verbinding.

Lft gebruiken vanuit een VPS in een datacenter in 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