Hi guys,

I already have a couple of linodes running, all based in the UK and I am extremely happy with them.

I have a Brazilian client who wants me to build them a website, and I would like to use Linode to host them if possible.

Which would be the best data center to use and would the speeds be really poor?


Many thanks,
Maff

I would expect the Dallas DC to be pretty fast to Brazil. You could do some speed tests with it as well as the Atlanta and Fremont DCs: http://www.linode.com/speedtest/

I'm always amazed at questions like this.

People play FPS games across oceans ALL the time. Sure, it's better when the game server is on the same continent, but it's playable.

What type of mere website is that latency dependent? Unless it's two-way voice or video (keyword - TWO WAY) then what difference does it make?

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

Less jumps between your customer base and the server = less chances for some router/host to mess up the connection. Not always about latency.

_________________
If you haven't heard this:

echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

You aren't using your computer enough.

I agree that either Dallas, TX or Atlanta, GA would probably be best, and that speed testing will help to clarify which one is really performing the best.

_________________
Amateur, eager to learn.
My hematology, oncology, and chemotherapy regimen wiki

Lol - good one ... wait - you're serious?

Care to throw any facts (or math) at that sweeping statement? Are you saying the risk is 500% greater if you pick a DC off shore, 5000%, or is it more like 5% or 0.5% due to the nature of redundant fiber and the fact that the internet has self correcting routing (ya know, kindof like it was designed that way).

The end users craptastic single point of failure equipment is by far more likely to fail then any enterprise grade equipment involved in the transit, making how far the two endpoints are separated kind of moot.

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

The less hops, the less likely your customers are to get hit by random routing or congestion issues along the path. And those sorts of issues don't tend to affect individual customers, but whole groups of them (say, any Comcast customer whose route goes through level3).

Yes, these sorts of issues tend to get routed around eventually, but given the choice between multiple linode datacenters, it does make sense to pick the one with the least number of hops to your target audience.

Great circle distance is probably about the only thing that can be reliably measured and doesn't change regularly, though. BGP AS Path Length (or, more specifically, the number of distinct autonomous systems between the endpoints) is the next-best thing, but is both subject to frequent changes and can only be determined reliably with access to BGP-speaking routers on both ends.

Traceroute does NOT show you how many routers, networks, carriers, or geopolitical boundaries a packet traveled, as it has no visibility below IP. This, for example, only shows as one hop on a traceroute (from Newark to www.he.net):

 7. 10gigabitethernet5-4.core1.nyc4.he.net   0.0%    15   10.5   5.6   1.6  11.0   3.6
 8. 10gigabitethernet5-3.core1.lax1.he.net   0.0%    15   61.9  63.7  61.9  72.7   3.3

... but there is, almost certainly, a lot more stuff between hops 7 and 8 than there is between hops 1 and 6.

In short, it's impossible to know how many "hops" there are between two points. So, grab a piece of string and a globe.

_________________

/* TODO: need to add signature to posts */

Sure, and the fact that my very first hop on my VDSL2 lines is a 6 hour drive away and passes through dozens of distinct pieces of hardware just backs that up. But it's still a useful metric. Overall latency is probably a better guide, however.