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.

latency
Edge Eddie, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • 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.
  • Explain: 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.
  • Explain: The sensor reacts, code checks the state, a command travels, and the brake takes time to act.
iotclass.org

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.

Key terms

Edge-fog latency
Edge-fog latency is the time between a physical event and the response that matters.
iotclass.org

Major section

Start Simple

The sensor has detected trouble, but the shaft is still turning.

  • The picture puts a local decision path beside a distant one; neither path is proven safe by the drawing alone.
  • The first question is not where the code is fashionable; it is how many milliseconds the whole loop can spend from sensing to actuation.
iotclass.org

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.
Latency budget path from event to evidence
Latency budget path from event to evidence
iotclass.org

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.
iotclass.org

Major section

Measure the Path, Not the Label

Start the clock at the physical change, stop at the required response, and report the ninety-fifth percentile with its slower cases.

  • The response clock starts at the physical change.The start marker must represent the event that creates the workload deadline.
  • The ninety-fifth percentile describes a measured time bound.Ninety-five percent of measured responses fall at or below it, while slower cases still matter.
  • Record the load, method, owner, and retest trigger.A percentile without its test conditions cannot support a placement decision.
iotclass.org

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.
iotclass.org

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.
iotclass.org

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.

Key terms

Placement
Placement is credible only when the measured trace includes those waits and the fallback path.
iotclass.org

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.
iotclass.org

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.
iotclass.org

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.
iotclass.org

Deck summary

Key takeaways

The sensor reacts, code checks the state, a command travels, and the brake takes time to act.

  • The sensor has detected trouble, but the shaft is still turning.
  • 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.
iotclass.org

Retrieval practice

Recall check 1 of 4

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?

AThe cloud owns the stop decision because its dashboard will make the event easiest for operators to audit later.
BThe edge owns the stop decision, while the fog or cloud path keeps evidence for review and fleet history.
CThe fog tier owns every stop decision automatically because it sits between the field device and cloud.
DNo explicit tier ownership is needed if one pressure-threshold test run succeeds during commissioning.
Show answer

Answer: B Latency placement should separate immediate response ownership from later evidence, governance, and review paths.

iotclass.org

Retrieval practice

Recall check 2 of 4

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?

AOnly the fastest successful run from commissioning, because it proves the alert path can be quick at least once.
BA cloud-only dashboard screenshot showing that alert events eventually appear in the operator interface.
CTail-latency and jitter evidence under realistic load, plus a record of what happens when the path misses the budget.
DNo retest rule after deployment, because latency is fixed by physical distance between the device and gateway.
Show answer

Answer: C Latency reviews need path-segment evidence, tail behavior, and retest rules, not only averages or labels.

iotclass.org

Retrieval practice

Recall check 3 of 4

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?

AThe full sensor-to-actuator response path, including tail-latency segments outside inference
BThe cloud storage cost alone, since local inference supposedly proves response speed
CThe edge device's architecture label rather than sensing and actuation timing
DThe repeated model inference time alone, excluding sampling and actuator response
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.

iotclass.org

Retrieval practice

Recall check 4 of 4

Edge Eddie says: answer from memory, then check your reasoning.

Q4A plant needs an immediate machine stop, site-wide status, and later fleet analysis. Which split fits the timing roles?

AStop locally at edge, coordinate site status at fog, and analyze fleet history in cloud
BWait for cloud analysis before an immediate machine-stop action at the plant
CPut fleet-wide history on the local actuator that must make the stop
DMake site-wide status depend only on a remote cloud dashboard during WAN loss
Show answer

Answer: A Each tier owns the work whose timing and scope it can meet.

iotclass.org

Print reference

Answers

Answer key.

  1. B · Latency placement should separate immediate response ownership from later evidence, governance, and review paths.
  2. C · Latency reviews need path-segment evidence, tail behavior, and retest rules, not only averages or labels.
  3. A · Tail latency review must measure the end-to-end response path and the degraded behavior that appears outside the happy path.
  4. A · Each tier owns the work whose timing and scope it can meet.
iotclass.org
With the four answers visible, follow one response clock. Put immediate action near the machine and later review on its own route. Measure busy-period slow cases, not just an idle average. Model runtime is only one segment. Retest when any segment or fallback changes.