Using the example ping pong code at https://developer.electricimp.com/examples/deviceagent in Australia on good (100Mbit) internet with imp005 using ethernet, I get:
|2018-03-10 22:32:24 +10:30|[Device]|Round trip took: 200ms|
|2018-03-10 22:32:30 +10:30|[Device]|Round trip took: 199ms|
|2018-03-10 22:32:35 +10:30|[Device]|Round trip took: 198ms|
|2018-03-10 22:32:40 +10:30|[Device]|Round trip took: 200ms|
|2018-03-10 22:32:45 +10:30|[Device]|Round trip took: 199ms|
|2018-03-10 22:32:51 +10:30|[Device]|Round trip took: 201ms|
What do you get? Where are you? and What are you using?
That sounds about right, depending on where you are in Australia.
If you visit http://www.cloudping.info/ from the same network, what does it show for US-West (Oregon)? That’s where the imp public cloud servers are at this point.
It’s the same. There isn’t any problem, just want to understand what it looks like in other parts of the world.
It does show that the imp system latency is pretty negligible when a trip through two VMs, crypto, MCU etc is almost the same as the raw ICMP ping time
Here in the South West United Kingdom (UK), I get 180 ms for US-West (Oregon) when using cloudping.info
They are quite large numbers. It means you can’t do anything interactive with the technology. I wonder how it would go if it used a mqtt style protocol that establishes connection once instead of every message like a http style protocol. Just a thought.
@trevor, large compared to what? Other services delivered from the US would give you similar roundtrip times. Along with the imp services, I regularly use jira, confluence, github, trello, loggly etc. They are all served up from the US, I believe. All have similar or worse lag (I’m in NZ, even slower than Australia). In fact, jira and confluence are glacial in comparison.
Hi @coverdriven, as an example:
If we use MQTT between a web browser in Adelaide and a device also in Adelaide with an MQTT server in AWS Sydney, the round trip for a MQTT message is less than 1mSec while a HTTP or an ICMP Ping has a round trip greater than 30mSec.
A little detail - The device is a PWM controlled motor. The web page has a variable slider that sends an MQTT message up to 4 times per second if change detected. When the PWM receives the instruction with a new value it first changes the PWM to the new value, then sends that new value back. When the web browser receives the new value from the device, it changes it’s display to reflect. The worst I’ve recorded is when we use celular (4G) internet, then it approaches the 10mSec round trip.
When I get time, I’ll set up an MQTT server in Oregon where the imp servers are and try the browser->MQTT->device->MQTT->browser to see what result I get.
Yes, I get your point. If you are in Sydney, you can reduce your ping time by putting the server close to you. Likewise, we could host Confluence locally and get a very responsive system. I believe that Electric Imp offers private deployments of the Imp Cloud for commercial customers. That would satisfy your needs if your customers were all in one geographic area. If your clients are distributed across the globe (as Electric Imp’s clients are), you’d need distributed servers. That may very well be within the scope of Electric Imp’s designs. Whether it’s MQTT or HTTP will probably make less of a difference. Have you looked at AMQP?
Yes, as @coverdriven says, this is just down to server location - nothing to do with protocols, it’s the packet transit time.
For the US, we’re very much real-time (generally 200ms is the limit of human perception - at 200ms or below, a human thinks an action and the result happen at the same time, eg flicking a switch and a light going on).
As we roll out more public cloud regions over time, latencies will improve for non-US regions.
If you would like a private cloud, you can have one of these essentially anywhere AWS or Azure have a region. We have customers who have private cloud regions in the US (east coast) and Europe (ireland) for example, which deals with data sovereignty issues too.
Your example of MQTT being 1ms and ICMP ping being 30ms doesn’t make any sense; there’s no way MQTT is faster than ICMP, which is a basic low level packet round-trip. HTTP performance will depend on the HTTP server, sure, but ICMP is about as low level as you can get (it’s below the level of MQTT, which is running over TCP).