Edge & Fog Computing · Study deck
Latency Budgets for Tier Choice
Picture a saw that must stop when a guard opens.
Edge Eddie is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: A vibration threshold might wait for the next sensor sample, retry on a noisy radio link, sit behind a gateway upload, run a model, request command authorization, and then wait for the actuator to respond.
- Explain: The same path may miss its response budget during radio retries, gateway overload, cold starts, model loading, authentication checks, congestion, actuator delay, or an upstream outage.
- Explain: A common hybrid pattern is edge for the minimum safe action, fog for site coordination and buffering, and cloud for history, comparison, governance, and model improvement.
- separate immediate response ownership from later review evidence;
Major section
In 60 Seconds
The sensor reacts, code checks the state, a command travels, and the brake takes time to act.
- A small ping time cannot prove the complete loop.
- Nearby and remote systems can coordinate sites, retain history, and improve rules, but they must not become the only path to immediate safety.
- This opening does not place every task at one tier.
Major section
Start Simple
The first question is not where the code is fashionable; it is how many milliseconds the whole loop can spend from sensing to actuation.
- Everyday IoT latency work starts by timing that loop, then moving only the responsibilities that miss the budget closer to the device.
Major section
Start the Clock at the Physical Event
A latency budget starts when the physical condition changes, not when the dashboard receives a message.
- A cold-room door sensor may need a local alarm within a site-defined window, while the supervisor dashboard and monthly energy review can wait.
- This budget supports edge ownership when the local confirmed action must survive backhaul loss.
Major section
Start the Clock at the Physical Event (continued)
If local firmware can alarm reliably during backhaul loss, the edge can own the immediate response.
- The fog gateway can still coordinate nearby devices and buffer records, while the cloud receives the event later for reporting.
- Transfer + Queue adds hops, retries, buffering, and burst load before Process + Decide applies a rule, inference, or site policy.
- The path ends only after Command + Act sends and confirms the response or invokes local fallback; Evidence Record then separates device, site, and review proof.
Major section
Measure the Path, Not the Label
A latency decision record should show the start event, stop event, path segments, measurement method, stressed condition, accepted percentile, owner, and retest trigger.
- The record should explain why the chosen tier is acceptable and what evidence must remain visible after deployment.
- The response clock starts at message receipt instead of the physical event.
Major section
Measure the Path, Not the Label (continued)
Sensor, firmware, sampling policy, calibration, timestamp source, or event definition changes.
- One healthy link measurement is treated as proof for congested, weak-signal, or outage conditions.
- Topology, gateway, backhaul, antenna, channel, retry policy, protocol, or site load changes.
- Model inference is measured alone while preprocessing, postprocessing, and actuation are ignored.
Major section
Measure the Path, Not the Label (continued)
Model, rule, device class, actuator, command policy, security check, or software version changes.
- Fast response works, but later reviewers cannot reconstruct what happened or why.
- Retention, privacy policy, upload path, dashboard, audit rule, ownership, or incident workflow changes.
- Prefer percentile evidence over averages when the workload is safety-related, control-related, or user-facing.
Major section
Tail Latency Is Where Placement Fails
A queue that preserves throughput can still break a response budget.
- A path may look acceptable when a device is idle, a gateway is nearby, a queue is empty, and the cloud service is healthy.
- Each segment can be small alone, yet the combined slow path can exceed the budget.
- Mixed clocks can make evidence misleading.
Major section
Tail Latency Is Where Placement Fails (continued)
Placement is credible only when the measured trace includes those waits and the fallback path.
- The same path may miss its response budget during radio retries, gateway overload, cold starts, model loading, authentication checks, congestion, actuator delay, or an upstream outage.
- Response records should preserve enough timestamps or trace IDs to reconstruct the path.
- When a path misses the budget, the system needs a defined local fallback, degraded mode, retry policy, or human-review route.
Major section
Tail Latency Is Where Placement Fails (continued)
A vibration threshold might wait for the next sensor sample, retry on a noisy radio link, sit behind a gateway upload, run a model, request command authorization, and then wait for the actuator to respond.
- A common hybrid pattern is edge for the minimum safe action, fog for site coordination and buffering, and cloud for history, comparison, governance, and model improvement.
- The under-the-hood rule is to review the worst useful path, not the happiest path.
- If the design depends on an edge model, measure preprocessing, inference, postprocessing, command output, and fallback.
Major section
Summary
Edge-fog latency is an end-to-end response budget from physical event to useful system response.
- The path includes sensing, queueing, network transfer, gateway behavior, processing, command delivery, actuation, and retained evidence.
- Edge ownership fits immediate local action; fog ownership fits site coordination; cloud ownership fits history, governance, training, and fleet review when delay is acceptable.
- A latency decision record should state start and stop points, segment budgets, measurement conditions, accepted percentile, owner, fallback, and retest trigger.
Deck summary
Key takeaways
The sensor reacts, code checks the state, a command travels, and the brake takes time to act.
- The first question is not where the code is fashionable; it is how many milliseconds the whole loop can spend from sensing to actuation.
- A latency budget starts when the physical condition changes, not when the dashboard receives a message.
- If local firmware can alarm reliably during backhaul loss, the edge can own the immediate response.
- A latency decision record should show the start event, stop event, path segments, measurement method, stressed condition, accepted percentile, owner, and retest trigger.
Retrieval practice
Recall check 1 of 3
Edge Eddie says: answer from memory, then check your reasoning.
Q1A pump must stop quickly when a local pressure threshold is crossed, but the cloud dashboard can receive the event later. Which placement claim is most reviewable?
Show answer
Answer: B Latency placement should separate immediate response ownership from later evidence, governance, and review paths.
Retrieval practice
Recall check 2 of 3
Edge Eddie says: answer from memory, then check your reasoning.
Q2A team reports low average latency for an edge-fog path, but the workload is a user-facing alert that must remain responsive during busy periods. What should the practitioner require?
Show answer
Answer: C Latency reviews need path-segment evidence, tail behavior, and retest rules, not only averages or labels.
Retrieval practice
Recall check 3 of 3
Edge Eddie says: answer from memory, then check your reasoning.
Q3A latency test measures model inference on the edge device but excludes sensor sampling, preprocessing, command output, and actuator response. What is missing?
Show answer
Answer: A Tail latency review must measure the end-to-end response path and the degraded behavior that appears outside the happy path.
Print reference
Answers
Answer key.
- B · Latency placement should separate immediate response ownership from later evidence, governance, and review paths.
- C · Latency reviews need path-segment evidence, tail behavior, and retest rules, not only averages or labels.
- A · Tail latency review must measure the end-to-end response path and the degraded behavior that appears outside the happy path.