To anyone outside the USA, this is old hat. Yes, latency matters for interactive traffic. Yes, the Atlantic (and Pacific) oceans are big and light ain't getting any faster.
Ah, well it could be. Light travels something like 66% of the speed in Fiber as compared to air. There have been attempts to design things like a balloon network across the Atlantic by HFT folk. It'll happen eventually.
I was hoping this would show us some benchmarks, that is, an Apple A10X ARM based server could be pretty darn fast based on the perf metrics I've seen. And off the damn charts in terms of power per watt. Not that Apple is selling any, but cough theyshouldbe
x86 offerings are so cheap now, is there still a market for this kind of ARM hosting? I would argue that you will achieve at least equivalent performance from an entry level KVM or Xen VM.
Perhaps there is still a market for the security concious or workloads sensitive to noisy neighbours.
Somewhat of a tangent - although not small scale, I have found the packet.net 96 core ARM offering to be good value.
Correct me if I'm wrong, but ARM is much less power hungry, and produces less heat. Both options that at scale means potential cost savings on resale.
It might not be enough to offset the other costs, but it could be enough to offer a less costly service. At the end of the day though, half of what you get with AWS is a ton of library support in many languages for using AWS services.
Performance and power are a complicated topic and Thunder-X2 might produce better numbers. 64-bit ARM for servers must be competitive with Xeons and POWER and can't compromise performance for power either.
Why not measure application response times on instance instead of at home? Would have been more interesting to see how $my_web_app runs on some t2.micros vs some arm boxes?
I don't. The stuff I host on Scaleway is there because 1) I don't want to host it in the US, 2) an ARMv8 experiment, or 3) I need redundant bootstrap capacity in case GCE or AWS goes down.
The dynamic stuff I host for personal use uses a variety of cloud services as backends, and those are anycasted.
One app I wrote in a hurry uses Google Sheets as a backend, and that's worked surprisingly well for the effort it took.
What people typically mean when they say speed of light is the speed in vacuum. For optical fibers, you can reduce that number by about 30%. It's also unlikely that there is a straight line from A to B, and each network hop will introduce additional latency - there are > 10 hops from my home connection to Scaleway, and that's with both ends located in Europe.
Good points. The 30% increase and the not-straight-distance could explain a 50% slowdown. But here we have a 500% difference.
Also the number of hops probably isn't really relevant : there probably isn't any router in the middle of the Atlantic, and just like you said there is already a bunch of router on an European-only route whose latency would most likely be below 10ms.
It's not really a question of where the hops are located. There'll be a couple of them in Europe and a couple in NA. Each will introduce a bit of latency.
The numbers from the article are also round-trip times (that's what you get with the ping command), so you'd have to double whatever number you come up with from the one-way distance alone.
> The numbers from the article are also round-trip times (that's what you get with the ping command), so you'd have to double whatever number you come up with from the one-way
distance alone.
Indeed, the theoretical minimum ping time for 9000km is 60ms.
I use scaleway for some of my side projects. The latency is noticeable but with a little bit of cache adjustments and a free cloudflare plan in front of it, it is fine.
I took about 5 sites from a $50 a month shared cPanel plan that included a few WordPress blogs and some custom sites and put them on a $3 a month scaleway instance and haven't had a bit of trouble.
It's interesting people are worried about this with Scaleway because I don't remember reading this with Slicehost or Amazon EC2 while they were ramping up.
So, is the bar so much higher or is it something else?
I used Slicehost and EC2 from Europe with total disregard for latency because I never had much users. For my (mostly internal) servers it was fast enough.
And even now, I have the cheapest Scaleway machine with a public-facing website that seems to be running fine a small Angular4 + Java backend app.
I would also like to see a graph showing the latencies between all the AWS regions. Which I guess will show that AWS regions do have a logic and that having servers next to your users makes sense.
Still, why worry about this from the start when your monthly 'budget' is less than the price of your coffee breakfast and you get unmetered bandwidth?
I highly recommend Packet.net instead of Scaleway if you care for bare metal or ARM. Their storage is local by default, which makes a huge difference in operational stability. In addition, their staff is super helpful.
As far as ARMv8, and Erlang go, I would suggest you not bother. At least in casual testing, I found P99 latency to be massively higher than the equivalent x86. BEAM just doesn't seem to want to do a massive number of schedulers well.
Packet.net's cheapest server looks to be about $37/mn while you can get a Scaleway server starting at about $3. I run a small website and I use Scaleway despite the latency because I don't want to spend more than a few dollars a month.
32 comments
[ 3.3 ms ] story [ 83.8 ms ] threadA few years ago, dedicated Raspberry Pi hosting was a bit of a thing for a bit.
I looked a bit, a few months ago, but I didn't turn up what appeared to be a clear winner of a choice.
Perhaps there is still a market for the security concious or workloads sensitive to noisy neighbours.
Somewhat of a tangent - although not small scale, I have found the packet.net 96 core ARM offering to be good value.
It might not be enough to offset the other costs, but it could be enough to offer a less costly service. At the end of the day though, half of what you get with AWS is a ton of library support in many languages for using AWS services.
This seems like a myth repeated without any proof to back it up.
Performance and power are a complicated topic and Thunder-X2 might produce better numbers. 64-bit ARM for servers must be competitive with Xeons and POWER and can't compromise performance for power either.
Thank you for the packet.net mention. It is interesting, even if it is not quite what I am looking in this context.
The dynamic stuff I host for personal use uses a variety of cloud services as backends, and those are anycasted. One app I wrote in a hurry uses Google Sheets as a backend, and that's worked surprisingly well for the effort it took.
How comes we're 5 times above that ?
Is the latency introduced by routers ? If yes, then that quite doesn't make sense : I doubt there is any in the middle of the Atlantic.
Is the routing that inefficient that the data travels 50000 km ?
Also the number of hops probably isn't really relevant : there probably isn't any router in the middle of the Atlantic, and just like you said there is already a bunch of router on an European-only route whose latency would most likely be below 10ms.
The numbers from the article are also round-trip times (that's what you get with the ping command), so you'd have to double whatever number you come up with from the one-way distance alone.
Indeed, the theoretical minimum ping time for 9000km is 60ms.
I took about 5 sites from a $50 a month shared cPanel plan that included a few WordPress blogs and some custom sites and put them on a $3 a month scaleway instance and haven't had a bit of trouble.
So, is the bar so much higher or is it something else?
I used Slicehost and EC2 from Europe with total disregard for latency because I never had much users. For my (mostly internal) servers it was fast enough.
And even now, I have the cheapest Scaleway machine with a public-facing website that seems to be running fine a small Angular4 + Java backend app.
I would also like to see a graph showing the latencies between all the AWS regions. Which I guess will show that AWS regions do have a logic and that having servers next to your users makes sense.
Still, why worry about this from the start when your monthly 'budget' is less than the price of your coffee breakfast and you get unmetered bandwidth?
As far as ARMv8, and Erlang go, I would suggest you not bother. At least in casual testing, I found P99 latency to be massively higher than the equivalent x86. BEAM just doesn't seem to want to do a massive number of schedulers well.