Average response time


I’m situated in Sweden. The average response time of a cloud get, or post is something like 3 seconds. We all know that the all mighty internet operates at the speed of light, but…
Is the response time in e.g. the US shorter?

I would like to know that.

It’s probably so and latency plays a part in this.

I believe Spark has plans to spin up more Spark :cloud: in various availability as demand increases!

So…grab a hundred people, make them all buy Spark cores and play with it… Send Spark HQ an email telling them that tons of Swedish geeks are messing with the cores but the response time is too slow! Can we have a sweden spark cloud spun up?! :smiley:

1 Like

Yeah, yeah Kenneth,

Latency is something we don’t like…
I’m just wondering if the spark cloud servers are up to their task, connecting to the cloud usually takes 2 attempts, 3 red blinks in between attempts. That’s giving me the impression the server are overloaded sometimes.

@jgoggins and @Dave has been scaling up the cloud and over here in Singapore, connection to the cloud is fairly stable!

Are you running the latest firmware? The 3 red blinks might be coincidental when the spark server code is updated and a short restart occurs.

Other than that, connection should be established fairly quickly. At least that’s how it has been for me so far on the other side of the globe! :globe_with_meridians:

1 Like

Latency times can be found here: http://status.spark.io/
If you want to make sure your connection is really fast, you might want to consider setting up a local Cloud. This way, your signal won’t have to travel half the gobe and back, which should be noticable in terms of latency.

1 Like

Thanks for the info!

1 Like

Hey @marcus , thanks for bringing this up, I know latency can vary widely depending on where you are connecting from, and it’s useful to know that there are folks in Sweden like yourself that could use some latency optimizing efforts, :slight_smile: . As @kennethlimcp mentioned, we’re taking steps to provision cloud infrastructure on multiple continents to reduce latency + create higher availability in Europe and Asia.

Thanks, I’ll understand, I hope to roll out a lot of sparks in the near future in Sweden. When that happens I will install our server locally, until than it’s not a big problem.
I do experience very often that the spark needs 2 rounds to be able to connect to the cloud, is it possible that the current servers are sometimes to busy?

Ok guys it’s in Sweden 24:07, response times for a get or a post are about 4 seconds, sometimes even 7 seconds.
My guess is that your servers are pretty busy at this time of day in your part of the world…
Is it possible to confirm my findings? the spark device string is available for reference, just drop me a mail.
If the response times are indeed as long as measured, I will get a local cloud server ASAP!

Hey All!

Typically our servers operate with a lot of headroom, and we have instrumentation that watches for unexpected spikes in latency that might be a result of load on our end. We’re confident that adding extra zones worldwide will have a big impact in lowering latency internationally, but it’s also somewhat dependent on your local connection, etc.

I realize this isn’t super scientific, but I just did a speedtest from my location to Karlstad, Sweden, and Stockholm, and got 140ms and 137ms, could you try doing a speedtest against some random locations on the US East coast, or share where you’re located so we can get a better idea of where the bottleneck is? Normally I would recommend a traceroute, but that’s tricky with our current setup…

A local server will always get you the best response time, since you’re not reaching out over the internet, my goal is just to make sure that’s at least as convenient as something in the cloud. :slight_smile:


Thanks for your message,
Today I experienced better performance, on average 1.5 seconds.
The setup here is wifi (duh) -> 4G -> internet.
pinging around the world is fast, about 30ms to 135ms.

Diving in to the problem I saw that the DNS server, translating api.spark.io, sometimes is slow. Maybe that’s was the source of the problem. And off course 4G is not as reliable as a copper / fiber connection.

Further more the latency collides with the time difference, sort off, at my clock, 05:00, yours 22:00?
the latency is lowest. Yes I got up early. Earlier, say your time 17:00 - 21:00 the latency is bigger.

As I write this, 24:00 the average response is 1.4 sec. That is from a phone running an app to my spark. path: phone -> 4g(by phone provider) -> cloud -> 4g router(other provider) -> wifi -> spark.

Today I optimized the android app to minimize comms. That helps as well.

For now it’s okay.

I’ll do my demo’s next week while your part off the world sleeps!



Hi @marcus,

Cool, thanks for the extra detail, that helps! :slight_smile:

I forgot this earlier, but we also have an internal health check that measures the round-trip time inside the cloud, without going out over the internet and back. It should help indicate the ‘latency floor’ of the service without considering links in-between. It’s here if you scroll down to the “Round Trip Latency” graph - http://status.spark.io -

I am really looking forward to spinning up more servers worldwide. :slight_smile:


Hi @Moors7

This may well be out of date by now but I’m looking around for how to set up a local cloud here (in the UK) as I’m working on a quad-copter which needs slightly better response times than I’m getting going across the Atlantic and back! Any advice/documentation would be appreciated


Hi @yardbird,

I need a faster response too, shall we setup a ‘continental’ server together? I am situated in Sweden, and I can live with 300mS response time.
About your project, I think most people use UDP to communicate with flying objects…
When I would design a control system for a moving object I would create a shotgun messenger that shouts commands at a speed of 100 ms or so, that means it repeats the last command eternally.
This method guarantees a reliable connection.
The theory behind this strategy is that sending a message 3 times or more gives very high change of reaching the destination, I read it somewhere long ago, can’t find it right now.
If you need more advice, PM me :smile:

You might want to check out how these guys are doing it, seems like they’ve gotten pretty far already:

1 Like

Tnx know the project and like it!
But my whish is to have a continental cloudserver.

I’m not sure on how you’re planning to do that though. I can imagine Particle not wanting to hand out their cloud infrastructure to just anyone. That’s where the Local Cloud comes in. Since you can run that on a Raspberry Pi, I don’t think you’d benefit to set one of those us continentally. Rather, just set it up at home, where you’d have the lowest latency possible(?)

My thoughts are going in that direction too. But I was more thinking along the line of renting a virtual server and set up the local cloud there, but it will not be so local then :grinning:

Since I have not done this before, or even read the documentation, I would like to invite other users to join the party and make it work together in Holland, or Sweden, or … somewhere near.

Another option will be that Particle deploys a cloud server in Europe and direct traffic accordingly.
An Idea?

What would be the benefit of setting up a local server on a virtual machine, rather than in-house, on something like a Pi?
A user-powered continental server is probably not going to happen. The local cloud is not meant for those kinds of situations, and several of the (cool) functions are still lacking. If you’re looking for a continental sever with all the functions from the current server, I think that needs to be done by Particle. I’m not sure if that’s on the time line anytime soon though. There are more important things to be done than slightly decreasing latency, whereby the local cloud will always be the fastest option.

“The Netherlands” ;), which is where I live, has a fairly low latency. I can toggle functions almost instantly, at least twice a second. Could it be that the connections in Sweden aren’t that fast, or your connection in particular (no pun intended)?

Well @Moors7,

I am dutch too, and I also have experience with (then) the spark core in Holland :wink: as well. There I measured response times between 700mS and 1.5 second, but that’s a long time a go. Maybe the cloud services are faster now.

In Sweden we all have 4G or fiber… so speed is not an issue. As soon I have time I will setup a local server on one of my raspi’s, it is clear that a local server will improve performance.
And when we finally hit the market with my product, we’ll address this issue again.
Miss, Hollandse Haring though!

1 Like