Skip to content
R2Kernel Runtime Kernel for Robotics v1.0.0rc1
R2Kernel Runtime Kernel for Robotics v1.0.0rc1

    Deployment Checks

    Use this page after installing R2Kernel on a host and before treating that host as a managed deployment target.

    These checks answer operational questions.

    • is the installed runtime reachable?
    • is the selected time-sync path accepted for the workload?
    • are the Web/API security gates configured for the deployment network?
    • can managed packages launch through the runtime path?
    • are resource leases visible and released correctly?
    • is cross-host Event delivery ready before collecting one-way latency numbers?

    For benchmark methodology and comparison envelopes, use Benchmarks. This page stays focused on deployment readiness, not performance reporting.

    1. Runtime Install

    Load the installed environment.

    . /opt/r2kernel/env.sh

    Check the service state.

    sudo systemctl status r2kernel-control.service --no-pager
sudo systemctl status r2kernel-resourced.service --no-pager
sudo systemctl status r2kernel-timesyncd.service --no-pager

    Check the local readiness endpoint.

    curl -sf http://127.0.0.1:8001/api/v1/ready

    2. Public SDK Smoke

    Use the installed Python SDK runtime.

    . /opt/r2kernel/env.sh
cd /opt/r2kernel

    Run a short local transport smoke.

    python3 benchmarks/transport/event/run_benchmark.py \
  --publisher-language python \
  --subscriber-language python \
  --count 20 \
  --warmup 5 \
  --fail-on-warning

    Healthy smoke runs should report ok and no warning promoted by --fail-on-warning.

    3. Time Sync Acceptance

    Run doctor before accepting cross-host one-way timing.

    r2kernel timesync doctor --wait --stable-polls 3

    Minimum acceptance checks.

    • time_sync_status.enabled = true
    • selected role and leader match the intended topology
    • selected backend is accepted for the workload
    • clock_status.accepted_for_one_way = true
    • clock_status.domain_compatible = true
    • hardware PTP paths have a valid active NIC and no recent ptp4l faults

    Strict 50 us cross-host one-way acceptance requires physical hosts on the same L2 segment, PHC-capable active NICs, an accepted hardware PTP or hardware-backed R2Kernel logical clock path, and accepted application-clock evidence. VM-led or software-timestamp-only runs can validate orchestration and delivery, but their one-way latency rows remain diagnostic.

    Use Time Sync Operations for configuration, startup, recovery, and failure cases.

    4. Web And API Access

    Before exposing the runtime API outside a trusted local environment, confirm.

    • security gates are enabled when remote access is expected
    • allowed CIDRs match the operator network
    • browser login is enabled for Web Console users
    • normal API clients use issued API keys rather than the bootstrap token

    Use Web and API Security for the detailed configuration path.

    5. Managed Package Launch

    Install or select a package that declares at least one resource claim, then launch it through r2kernel launch, r2kernel deploy, or a managed Runtime launch in the Web Console.

    Confirm.

    • package validation succeeds
    • the subsystem package starts through the managed launch path
    • the Resource page shows the lease owner, resource type, and assigned value
    • stopping the package releases the lease

    Use Resource Control for resource semantics and service setup.

    6. Cross-Host Event Gate

    Cross-host one-way Event measurement requires two gates.

    • the Event data path for the exact publisher/subscriber pair is ready
    • the clock path is accepted for one-way timestamp comparison

    Inspect the public control status on both hosts before collecting one-way samples. The sender must report the requested route as forward-ready, the receiver must report it as inbound-ready, and both hosts must accept their clock evidence for one-way timing.

    Accepted gate reports should show.

    • requested topics under sender forward_ready_topics
    • requested topics under receiver inbound_ready_topics
    • topology fallback flags set to false
    • data_plane_ready=true
    • time_sync_required=true, time_sync_status=accepted, and time_sync_ready=true
    • latency_evidence_accepted=true
    • final JSON ready == true

    Readiness-only Event smoke proves delivery-path setup only. Do not use its one-way latency rows as accepted performance data.

    7. Runtime Cleanup

    Runtime-owned communication and resource state should be reclaimed when the owning subsystem or deployment stops. Check the public runtime status after an abnormal termination instead of relying on host implementation directories.

    r2kernel deploy down <deployment.yaml>
r2kernel resource status
r2kernel subsystem sessions

    The deployment is clean when terminated instances no longer appear as active, their resource leases are absent, and a subsequent deployment can start without an ownership conflict.

    Result Rule

    Treat a deployment as accepted only when the relevant checks pass for the intended environment. Record VM, software timestamp, stress, or readiness-only runs as diagnostic evidence rather than production timing evidence.