laantungir/amethyst
1
0
Fork 0
mirror of https://github.com/vitorpamplona/amethyst.git synced 2026-08-11 16:57:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(relayBench): add REQ-mode 1M pull results alongside negentropy

Browse Source 
geode paged-REQ sink (verify on, FTS off):
  geode→geode  4,963 ev/s (completes)   strfry→geode  5,801 ev/s (completes)

Findings: strfry has no REQ bulk sync (stream is live-only limit:0), so the
strfry-sink REQ pairs are n/a. strfry→geode over REQ now completes (earlier
FTS-on stall was strfry killing the slow client at its 32MB pending cap; FTS-off
keeps pace). REQ is ~15-30% slower than negentropy for the geode sink, and
geode-as-a-REQ-source is slower than strfry (SQLite range scans vs LMDB).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EZeWww5TJnzBZKPoc6mvU
This commit is contained in:
Claude
2026-07-05 03:43:43 +00:00
parent 59641ba1ef
commit 5dd9fc5266
1 changed files with 26 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
relayBench/plans/2026-07-04-sync-throughput-1m.md
+26 -1
View File
@@ -32,7 +32,32 @@ relay, each holding the corpus.
so a geode source offers its full ~994k (D transfers all of it). Same
NIP-62/09/40 fairness family as `2026-07-04-sync-fairness-nip62-09-40.md`.
REQ-mode comparison to follow separately.
### REQ-mode counterpart (2026-07-05)
Same corpus + same geode sink config (verify ON, FTS OFF), but a plain **paged
`REQ`** pull instead of negentropy (`-DsyncMode=req`, 20k-event `until` windows).
| # | source → sink | mechanism | synced | time | throughput |
|---|---------------|-----------|--------|------|------------|
| A | geode → geode | geode paged REQ | 994,144 / 994,832 | 200.3 s | **4,963 ev/s** ✅ |
| B | strfry → geode | geode paged REQ | 994,813 / 994,898 | 171.5 s | **5,801 ev/s** ✅ |
| C | strfry → strfry| — | — | — | **n/a** |
| D | geode → strfry | — | — | — | **n/a** |
- **strfry has no REQ bulk sync.** Its REQ path is `strfry stream`, which sends
`["REQ","sub",{"limit":0}]` — live-only, no historical replay; `strfry sync` is
negentropy. So the strfry-*sink* REQ pairs (C, D) have no strfry-native
mechanism — that gap is the finding: geode can bulk-pull over REQ, strfry can't.
- **strfry→geode over REQ now completes** (B) — earlier it stalled at ~310k
because FTS-on ingest fell behind strfry's page serving and strfry killed the
slow client at its 32 MB pending cap. With FTS off the sink keeps pace, so
strfry never trips the cap. (Completion over REQ is contingent on the sink
out-running the source; negentropy is immune because it's pull-paced.)
- **REQ is ~15–30% slower than negentropy** for the geode sink (4,963–5,801 vs
6,690–6,971): the paged `until` windows re-fetch boundary duplicates and range-
scan the source, vs negentropy's direct id fetch. And geode-as-a-REQ-*source*
is slower than strfry-as-a-source (A 4,963 < B 5,801) — SQLite range scans vs
strfry's LMDB.
---