Latency of Scaleway, the cloud provider offering multicore ARM servers | Hacker News Reader

Latency of Scaleway, the cloud provider offering multicore ARM servers

philipmw.github.io

33 pointspmw30 comments

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.

RTT based on the speed of light should be 54 ms. Say 70 ms because it won't go as the crow flies, so could actually get twice as fast in theory.

You're discounting TCP ACK overhead, and time taken by switches.

Ping doesn't use TCP and the time taken by switches can be reduced, theoretically.

This has nothing to do with Scaleway, the latency results would be the same no matter the provider.

So, where on the North American continent are people going for a small (ARM or otherwise), dedicated server that doesn't break the bank?

A 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.

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.

Here you go: http://www.anandtech.com/show/10353/investigating-cavium-thu...

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.

>ARM is much less power hungry, and produces less heat

This seems like a myth repeated without any proof to back it up.

Scaleways offers x86 options that are the same price with same number of cores.

I got an email saying that they recently doubled the arm cores.

Yes, I have some interest in an inexpensive, relatively low demand hosting scenario that does not involve a VM / CPU sharing.

Thank you for the packet.net mention. It is interesting, even if it is not quite what I am looking in this context.

They are only cheap because Intel has competition. Offering ARM, get them probably cheaper access to Intel Hardware.

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 just use Cloudflare's free plan with my Scaleway servers, so Scaleway could be hosting from low earth orbit for all I care.

How would you speed up a dynamic real-time app with cloudflare? It'd not like you can cache real-time results.

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.

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?

What's weird is that the distance from SF to Paris is 9000 Km, which is 30 light-ms. So the theoretical minimal latency would be 30ms.

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 ?

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.

This is really obvious. You should lose karma for up voting it.

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

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.

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.

Reply on news.ycombinator.com