Ping times (latency) from Metro NYC to the datacenters?

Hi,

Could someone who's got an office or a home in the Metro NYC area please post ping times for the data centers?

I have a web app that will serve people in this area, in addition to the Pacific NW, which it's currently doing. And I live in Portland, OR, which makes it hard for me to judge what a NY/NJ/CT/PA user's experience would be like. I've deciding whether to move from Fremont, whether to split to two servers, etc.

In case it's interesting, here are my ping times from my slow home connection in Portland:

fremont1.linode.com: 34ms

newark1.linode.com: 110ms

dallas1.linode.com: 80ms

atlanta1.linode.com: 94ms

20 Replies

For NYC, Newark is undoubtedly best — it’s only a few miles away.

CT, PA and obviously NJ are also geographically closest to Newark.

Atlanta is second-closest, though with really, really bad routes, it’s slightly possible that London or even Dallas would be faster for some users.

That's what I was thinking, what the relative differences are.

I'm trying to decide, though, whether the increase in latency to, say, Dallas or Fremont is a show-stopper for a web app.

From my FIOS connection in Northern NJ (close enough to Metro NY)

64 bytes from newark1.linode.com (207.192.68.6): icmp_seq=1 ttl=48 time=11.7 ms

64 bytes from fremont1.linode.com (64.71.152.17): icmp_seq=1 ttl=49 time=86.7 ms

64 bytes from dallas1.linode.com (70.85.129.19): icmp_seq=1 ttl=46 time=56.7 ms

64 bytes from 63.247.71.196: icmp_seq=1 ttl=48 time=34.8 ms (that's Atlanta1; no rDNS?!)

For completeness:

64 bytes from london1.linode.com (109.74.207.9): icmp_seq=1 ttl=50 time=94.8 ms

I used to live in the area. pings to newark are incredibly low. Atlanta has good pings too, but I wouldn't get a a linode there. Dallas is decent and Fremont is a little slow.

If you have any European traffic, I'd go with Newark. Otherwise, Dallas is a good compromise for US traffic.

I'd lean towards Dallas; it's a good compromise between both coasts and is well-connected in both directions. The increase in latency will probably be minor compared to the total page load time, given a decently-smart web server and network stack. Alternatively, design the application to use two Linodes, one on each coast.

For what it's worth, at least two of us with cable modems in upstate New York have used VoIP through Dallas with no deleterious effects. :-) (For what it's worth, London is "closer" to me than Fremont, so I might just be in a bizarro pocket.)

@sweh:

From my FIOS connection in Northern NJ (close enough to Metro NY)…

Thanks - that's very helpful. I'm deciding between two scenarios:

1) Linode in Newark and Linode in Fremont

2) Linode in Dallas.

It's a Rails app with an average server response time of 80ms. So it's very fast, and offhand I have no idea how I'd split it up to run redundantly in different data centers. The big issue is user sign-ins and history.

From a Pittsburgh data center (run by a large host), I'm getting an average of 32ms over about 20 pings.

I hope at some point in the future Linode gets some space in a Seattle DC. I have 5ms ping times to one in particular :)

However, the 23ms I get to Fremont ain't bad either :)

@waldo:

However, the 23ms I get to Fremont ain't bad either :)

That's actually pretty ridiculous. I was curious so:

http://www.wolframalpha.com/input/?i=di … to+fremont">http://www.wolframalpha.com/input/?i=distance+pittsburgh+to+fremont

It takes light 16.9ms (in fiber) to cover that distance… but that's if the fiber was a straight line from pittsburg to fremont. Basically, the computers between you and fremont are adding almost no latency.

You assumed I was in Pittsburgh. I'm in the Seattle area. I have a shared hosting account at a large host in Pittsburgh where I tested to Newark.

From Pittsburgh to Fremont I get 63ms.

From a cable modem in Bellevue, WA (a Seattle suburb):

fremont1:

round-trip min/avg/max/stddev = 32.575/34.932/36.295/1.084 ms

dallas1:

round-trip min/avg/max/stddev = 74.200/75.360/78.328/1.271 ms

newark1:

round-trip min/avg/max/stddev = 107.097/110.173/112.980/1.769 ms

So I've reduced my DNS TTLs in preparation for a move from Fremont to Dallas. It seems like Dallas is best for serving both coasts, with Fremont a close second.

Anyone else situated in Dallas to best serve people nationwide?

I can attest that Florida Comcast users ping best to Dallas, so I think you must be right. Of course it's best to host servers in multiple locations, but I'd say if you have to choose one, Dallas is probably best. It is the most centrally located geographically, anyway. I ping better to Dallas than Fremont.

@BarkerJr:

I can attest that Florida Comcast users ping best to Dallas, so I think you must be right.

Interesting.

> Of course it's best to host servers in multiple locations…

I'd love to do that, but I haven't come with good ways of (1) Keeping geographically distributed database-stored sessions and associated user data synced, and (2) reliably / cost-consciously / maintainably do the Geo-IP routing.

For my setup I haven't had to deal with your problem #2, but for problem #1, master-master mysql replication has done the trick for years with zero issues.

````
alpha:~ brianpuccio$ ping -c 1 fremont1.linode.com
PING host27.linode.com (64.71.152.17): 56 data bytes
64 bytes from 64.71.152.17: icmp_seq=0 ttl=48 time=88.088 ms

--- host27.linode.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 88.088/88.088/88.088/0.000 ms
alpha:~ brianpuccio$ ping -c 1 newark1.linode.com
PING newark1.linode.com (207.192.68.6): 56 data bytes
64 bytes from 207.192.68.6: icmp_seq=0 ttl=45 time=10.032 ms

--- newark1.linode.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.032/10.032/10.032/0.000 ms
alpha:~ brianpuccio$ ping -c 1 dallas1.linode.com
PING host107.linode.com (70.85.129.19): 56 data bytes
64 bytes from 70.85.129.19: icmp_seq=0 ttl=44 time=55.819 ms

--- host107.linode.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 55.819/55.819/55.819/0.000 ms
alpha:~ brianpuccio$ ping -c 1 atlanta1.linode.com
PING host77.linode.com (63.247.71.196): 56 data bytes
64 bytes from 63.247.71.196: icmp_seq=0 ttl=46 time=28.279 ms

--- host77.linode.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.279/28.279/28.279/0.000 ms
alpha:~ brianpuccio$
````

This is from a FIOS connection on Long Island, about 23 miles as the bird flies from midtown Manhattan.

@Brian Puccio:

alpha:~ brianpuccio$ ping -c 1 fremont1.linode.com...
> 
> Thanks!  Interesting - you have great connectivity to all the data centers, even though you're geographically on the "other side" of Manhattan.

@Xan:

For my setup I haven't had to deal with your problem #2, but for problem #1, master-master mysql replication has done the trick for years with zero issues.

Mysql replication definitely sounds like a way to go, but I didn't know about traffic and then how network speeds would affect it. I'm sure I'll just have to do some testing and see what the results are. E.g., replication running between Fremont and Newark.

And "master-master"? I hadn't heard of that configuration. I'll look into it.

Unless you're doing a lot of truly massive queries, the databases will for practical purposes always be in sync. I don't think the latency between Newark and Fremont would be a factor at all.

I've designed my app to favor multiple, small queries (in general) rather than enormous all-in-one queries. The all-in-ones may be the best in isolation, but with smaller ones, other threads have a chance to run, including the replication.

Master-master is a technique whereby two (or possibly more) database instances are simultaneously masters. When one makes a write, the other duplicates it. Very handy for high availability across datacenters, and really very easy to set up since MySQL 5.0.

The MySQL docs say to only run a cluster locally. It's not just writing that is duplicated, but also locks and such. You don't want a zillion row locks being sent across the wire synchronously for one write.

cluster != master-master replication

@Xan:

For my setup I haven't had to deal with your problem #2, but for problem #1, master-master mysql replication has done the trick for years with zero issues.

I've yet to find a good solution that is open source and free for #2, but for any geo setups we have I use Zeus GLB.

Bit expensive though, which will probably deter most people. Amazing product but yeah, there aren't many options that I am aware of comparable to the Linode pricing.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct