A robot request has a deadline. Plain code decides whether the model runs locally or on a remote service, and a non-actuating sink then accepts or rejects each answer. The five cases follow the logic of the deterministic simulator in experiments/edge-cloud-placement. The numbers are small declared inputs chosen for teaching. They are not simulator output and not measurements.
- Status: simulated
- Storyboard: illustrative, hand-authored
- Measured results: N/A (not run)
- Registry status: planned, nothing measured
- dataRequest
- plain codeEligibility
- plain codePlacement policy
- advisory only, optionalAdvisory model
- plain codeNon-actuating sink
Predicted fit: remote
The remote service is eligible and the predicted round trip fits inside the deadline, so the deadline-aware policy sends the request there.
-
A request arrives with a deadline info
The request has a 300 ms budget, counted from capture.
deadline_ms: 300
-
The remote service is eligible passed
16384 MB are free and the model needs 8192 MB, so the remote can take it, as far as the policy knows.
remote: 16384 MB free, needs 8192 MB
-
The prediction fits the budget passed
Predicted round trip 100 ms plus a 20 ms margin is 120 ms, which is within 300 ms. The route is remote, reason predicted_fit.
route: remote (predicted_fit)
-
Optional advisory model: not run N/A (not run)
It is not part of the simulator. Advice could not make an ineligible remote eligible.
-
The sink accepts the first answer passed
The answer arrives at 130 ms, before the deadline, and nobody has answered yet. The sink records would_apply with actuated: false.
decision: would_apply
actuated: false
Outcome: accepted Remote placement accepted by plain code. No action was applied to anything: the sink only records would_apply.
Predicted miss: local
Earlier timeouts raised the round-trip estimate. It no longer fits the deadline, and no probe is due, so the policy keeps the request on the robot.
-
A request arrives with a deadline info
The budget is 300 ms.
deadline_ms: 300
-
The remote is eligible passed
Eligibility alone does not send the request there.
-
The remote does not fit, so it is rejected rejected
Predicted 320 ms plus a 20 ms margin is 340 ms, above 300 ms. The last remote send was 400 ms ago, so the 1000 ms probe interval has not passed and no probe is sent. The route is local, reason predicted_miss.
route: local (predicted_miss)
-
Optional advisory model: not run N/A (not run)
The policy decided without it.
-
The sink accepts the local answer passed
Local compute takes 150 ms, inside the deadline. Decision: would_apply.
decision: would_apply
Outcome: accepted Local placement accepted. The estimate can recover later because a probe is allowed once the probe interval has passed.
Remote says no: explicit reject
The policy's view of the remote is out of date. The remote refuses because it has too little memory, and the hedged policy falls back to the robot.
-
A request arrives with a deadline info
The budget is 300 ms.
deadline_ms: 300
-
The remote refuses: not enough memory rejected
Memory dropped 300 ms ago, but the capability advertisement lags by 500 ms, so the policy still saw 16384 MB. The remote has 4096 MB and needs 8192 MB, so it rejects at 70 ms with ineligible_memory.
remote reply: reject
reason: ineligible_memory
-
The hedged policy launches the local fallback passed
After the explicit reject the policy starts the local copy at once and holds the remote back for the probe interval.
route: local (fallback)
-
Optional advisory model: not run N/A (not run)
It cannot add free memory to the remote.
-
The sink accepts the fallback answer passed
The local answer arrives at 230 ms, before the 300 ms deadline. Decision: would_apply, marked as a fallback.
decision: would_apply
fallback: true
Outcome: rejected The remote placement was rejected for memory. The request still met its deadline through the local fallback.
Duplicate answer: second one rejected
Both the remote and the local fallback answer. The first accepted answer wins, and the second is refused even though it arrived before the deadline.
-
A request arrives with a deadline info
The budget is 300 ms.
deadline_ms: 300
-
The remote is tried, and a hedge is armed passed
The remote has not answered when the hedge timer fires at 110 ms, so the local fallback starts in parallel.
hedge: local fallback at 110 ms
-
Optional advisory model: not run N/A (not run)
The timer, not a model, decides when to hedge.
-
The local answer is accepted first passed
It arrives at 270 ms, within the deadline. Decision: would_apply.
decision: would_apply
-
The remote answer is rejected as a duplicate rejected
It arrives at 285 ms, also within the deadline, but this request is already applied. The sink checks for duplicates before lateness.
decision: rejected
reason: duplicate_response_id
Outcome: rejected One action is applied per request. The slower copy is rejected with duplicate_response_id.
Local-only request: remote answer rejected
The request must stay on the robot. The remote is never asked, and an unexpected remote answer is rejected by the sink.
-
A request that must stay local arrives info
The local_only flag is set. The deadline is 300 ms.
local_only: true
-
The remote is ruled out up front rejected
A local_only request never considers the remote. No remote request is sent.
remote: not considered
-
The route is local passed
Reason: local_only.
route: local (local_only)
-
Optional advisory model: not run N/A (not run)
Advice cannot override local_only.
-
A stray remote answer is rejected rejected
An unexpected answer from the remote arrives at 100 ms. The sink rejects it with ineligible_source before the local answer arrives.
decision: rejected
reason: ineligible_source
-
The local answer is accepted passed
Local compute takes 150 ms, within the 300 ms deadline. Decision: would_apply.
decision: would_apply
Outcome: rejected The remote source was rejected for a local_only request. The local answer was accepted.
What gets rejected, and why
Each row is a negative case in the storyboard above. Reason names are proposals for this study, not an implemented interface, unless the simulator source below defines them.
Experimental protocol
- Fix the request stream, the deadlines and the network profile in a config file before running anything. Every parameter there is declared, not measured.
- Run all policies on the same seeded request stream, so differences come from the policy.
- Compare always_local, always_remote, deadline_aware and hedged_fallback on deadline misses and on the cause of each miss.
- Treat every number the simulator prints as SIMULATED. Real-network or real-robot evidence needs a separate, reviewed run.
The simulator never actuates anything: its sink only records would_apply or rejected. There are two sites only, the robot and one remote service, and no hold action: a request with no accepted answer is a deadline miss. Do not assume the remote wins. Under the simulator's placeholder parameters, running locally is not worse than always going remote, and other parameters could change that ordering. The registry primary metric (sensor-to-valid-action p95) has no measured value. See also the experiment blueprint on this page.
Measured values
Every value is N/A until a reviewed run exists| Metric | Value | Why |
|---|
| Sensor-to-valid-action p95 (registry primary metric) | N/A | No live measurement. Simulated values are not results. |
|---|
| Deadline-miss rate on a real network | N/A | Not run. |
|---|
| Local versus remote energy | N/A | Not measured. |
|---|
See the evidence registry. Nothing on this page is a benchmark.
Where the real code and tests live
Paths are relative to the repository root and the links open the main branch on GitHub. A link resolves once the change that adds the path has been merged.
Illustration only. The steps are fixed text written by hand. This page runs no model, sends no network request, publishes no ROS 2 message and moves no robot. Use the Pause decorative motion button near the top of the page to stop all motion; the player never starts by itself.
ROS 2