Evidence ledger

What has been qualified, what has been measured, what is still in progress, and what remains designed.

Qualification and characterization are separate. So are an unknown problem, a known root cause, a designed correction, deliberately deferred implementation and demonstrated running code. Measurements belong to the machine, path, workload and checkpoint that produced them. A documented bug is not silently promoted into an architectural failure, and a designed fix is not silently promoted into running code.

Root cause known

The failure mechanism has been inspected and understood. That does not by itself mean the correction is implemented.

Solution designed / deferred

A concrete correction exists, but current requirements do not justify interrupting higher-value work to implement it yet.

Implemented / qualified

The mechanism exists in running code; qualification then establishes what contract and conditions have actually been demonstrated.

Qualified

Living Network

Qualified

Multi-city network; split/heal machinery; 900 MHz mobile segment; remote physical actuation.

Communicator

Characterized

Bidirectional 160×120 video at 24 fps with uninterrupted prioritized audio at an observed ~121 Kbps point, over TCP. The Communicator path ran Seattle → WireGuard → broker → WireGuard → New York → 900 MHz. Watch the recorded operating points.

Python ↔ C++

Qualified

Memory and Plane interoperability exercised in both directions against the same framing and semantics.

big5 Internet RAM

Qualified

Five machines in two cities mounted one Region served from a third with the same program and no placement logic.

Redis oracle

Qualified

Redis 7.2.11 used as an external behavioral oracle. Recorded checkpoint: 1,502 OK / 207 N/A over 29 files on one core; ARM64 parallel checkpoint: 1,177 OK / 94 errors over eight files; no timeout, exception or weak-memory ordering hole was observed at that checkpoint.

Characterized

FrogTorch campaigns

Characterized

Four same-campaign comparisons: 1.95×, 1.64×, 1.03× and 1.75× versus Gloo in the recorded campaigns.

C++ Memory

Characterized

Recorded flat acknowledged run: 21,037 writes/s with zero skipped. Distinct-cell contention acknowledged: 13,974 writes/s, zero dropped of 56,052, median delivery ~1.0 ms.

Operating envelope

Characterized

One-core sandbox produced separate recommendations for distinct state, every-generation observation and latest-value freshness. These are host/policy measurements, not FrogNet limits.

Redis machine sensitivity

Characterized

On the small-cache i7-5557U MacBook, one-core Ribbit measured 0.60× / 0.66× / 0.66× / 0.41× stock Redis for SET / GET / LPUSH / SADD. With two cores it reached 1.07× / 1.18× / 1.19× / 0.72×. The unfavorable result stays beside the Pi 5 results because the representation and cache cost are part of the evidence.

In progress

Failure qualification

In progress

Listener kill, packet loss and server restart/recovery remained explicit qualification items in the recorded Network Shared RAM checkpoint.

SuperTuxKart

In progress

The object model and validator exist. Completed physical-machine integration is not claimed here.

Deliberately not implemented

This is the register. A declined behavior is not hidden as a failed implementation.

Redis stale-expiry bookkeeping

Deliberate semantic difference

Redis can retain stale expiry bookkeeping until a key is touched. Ribbit does not need to reproduce that internal artifact to preserve the useful external state model.

Writer-side synchronous handoff

Deliberate semantic difference

Redis may serve a blocked client inside the writer's call. Ribbit treats publication as synchronization: publication makes the waiter runnable; the writer does not wait for the reader to consume.

Global guarantees

Non-claim

No global coherent heap, global transactions, automatic cross-Region reconciliation or automatic continuity across re-homing.

Current pond-size implementation limit

Root cause known · replacement designed · implementation deferred

The current implementation spends a scarce carrier resource per tunnel. In a full mesh, tunnel count therefore grows quadratically and reaches the present roughly 56-node pond limit. The failure mechanism has been traced to that allocator; it is not a limit of FrogNet discovery or the addressing model. The replacement design allocates the resource per node instead of per tunnel, changing the relevant growth from quadratic to linear and providing about 59,500 addresses under the current plan. It has not been implemented because the physical development network has only a handful of machines and the existing limit is not constraining current experiments. Code velocity was deliberately spent on work that is.

Measured comparisons

Measured comparisons

FrogTorch: same-campaign rate vs Gloo

Campaign 1
1.95×
Campaign 2
1.64×
Campaign 3
1.03×
Campaign 4
1.75×
Four same-campaign comparisons preserving ordinary DDP semantics in the compared arm. The bars are normalized to a 2.0× display ceiling.

Redis-on-Ribbit: Pi 5 throughput

SET, 1 core
268k
SET, 3 cores
704k
GET, 1 core
399k
GET, 3 cores
858k
LPUSH, 1 core
424k
LPUSH, 3 cores
1.03M
Raspberry Pi 5, million-key workload. This graph shows Ribbit's measured one-core and three-core rates; it is not a universal scaling claim.