Another effect is the latency and response time for events. As you get closer to the sensor, you enter the realm of hard real-time requirements. These systems are typically deeply embedded systems or microcontrollers that have latency set by real-world events. For example, a video camera is sensitive to the frame rate (typically 30 or 60 fps) and must perform a number of sequential tasks in a data flow pipeline (demosaicing, denoting, white balance and gamma adjusting, gamut mapping, scaling, and compression). The amount of data flowing through a video imaging pipeline (1080p video using 8-bits per channel at 60 fps)is roughly 1.5 GB/s. Every frame must flow through this pipeline in real time, therefore most video image signal processors perform these transforms in silicon.  

If we move up the stack, the gateway has the next best response time and is usually in the single digit millisecond range. The gating factor in the response time is the WPAN latency and the load on the gateway. As previously mentioned in the WPAN chapter, most WPANs such as BLE, are variable and dependent on the number of BLE devices under the gateway, scan intervals, advertisement intervals, and so on. BLE connection intervals can be as low as 7.5 ms but can vary depending on how the customer adjusts the advertisement intervals to minimize power usage. Wi-Fi signals typically have a 1.5 ms latency. Latency at this level requires a physical interface to the PAN. One wouldn't expect to pass raw BLE packets to the cloud with any hope of near real-time control.  

The cloud component introduces another degree of latency over the WAN. The route between the gateway and cloud provider can take multiple paths based on the locations of the data centers and the gateway. Cloud providers usually provide a set of regional data centers to normalize traffic. To understand the true latency impact of a cloud provider, one must sample the latency ping over the course of weeks or months and across regions:

Amazon AWS CloudPing from the US West Client courtesy of CloudPing.info (for more information, visit http://www.cloudping.info).

An exhaustive analysis of cloud latency and response times is kept by CLAudit (for more information, visit http://claudit.feld.cvut.cz/index.php#). Other tools also exist to analyze latency, such as Fathom and SmokePing (for more information visit https://oss.oetiker.ch/smokeping/). These sites research, monitor, and archive TCP, HTTP, and SQL database latency across AWS and Microsoft Azure on a daily basis across many regions worldwide. This produces the best visibility to the overall latency impact one may expect from a cloud solution. For example, the figure here illustrates the round-trip times (RTT) for a single day between a test client in the US communicating with Amazon AWS and Microsoft Azure servers in the Western US. It is also useful to note the variability in RTT. While a spike of 5 ms may be tolerable in many applications, it may lead to failure in a hard real-time control system or factory automation:

Typically, cloud latency will be in the order of tens if not hundreds of milliseconds without accounting for any overhead of processing for the incoming data. This should now set an expectation for the varying levels of response when building a cloud-based architecture for the IoT. Near-device architectures allow for sub-10 ms responses and also enjoy the benefit of being repeatable and deterministic. Cloud solutions can introduce variability into response times as well as an order of magnitude/greater response time than a near-edge device. An architect needs to consider where to deploy portions of the solution based on these two effects. Cloud providers should also be chosen based on their data center deployment models. If an IoT solution is being deployed worldwide or perhaps will grow to cover multiple regions, the cloud service should have data centers located in geographically similar areas to assist in normalizing the response time. The chart reveals the great variance in latency based on a single client reaching data centers worldwide. This is not an optimal architecture.