|
| 1 | +# Cascade Downloads & Performance: Concepts, Limits, and Tuning |
| 2 | + |
| 3 | +This document explains how Cascade encoding/decoding works, the performance and memory factors involved, and practical configuration guidance. It consolidates the “blocks and symbols” primer and expands it with deeper operational tuning, error references, and code pointers — in a concise, professional format. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +- Cascade uses RaptorQ forward error correction to split a file into blocks and symbols that can be stored/fetched from a P2P network. |
| 8 | +- Decoding requires enough symbols to reconstruct each block; integrity is verified with hashes recorded in the layout. |
| 9 | +- Performance and reliability are driven by four main levers: block size, redundancy, concurrency, and memory headroom. Batching and ordering in the store path, and supernode selection in the download path, also matter. |
| 10 | + |
| 11 | +## Current Defaults (Implementation) |
| 12 | + |
| 13 | +- RaptorQ (codec) |
| 14 | + - Block cap: 256 MB (encode‑time upper bound per block) |
| 15 | + - Decode concurrency: 1 |
| 16 | + - Memory headroom: 20% of detected RAM |
| 17 | + - Symbol size: ~65,535 bytes |
| 18 | + - Redundancy: 5 |
| 19 | + |
| 20 | +- Store path (foreground adaptor) |
| 21 | + - Batch size: 2,500 files per batch (≈156 MiB typical at default symbol size) |
| 22 | + - Downsampling: if total files > 2,500, take 10% sorted prefix for initial store |
| 23 | + - Per‑batch P2P store timeout: 5 minutes |
| 24 | + |
| 25 | +- Store path (background worker) |
| 26 | + - Batch size: 1,000 files per batch (≈62.5 MiB typical) |
| 27 | + |
| 28 | +- Download path |
| 29 | + - SDK per‑supernode download deadline: 10 minutes |
| 30 | + - Supernode ranking: status probe ~2 seconds per node; sorted by available memory (desc) |
| 31 | + - P2P exec timeouts (per RPC): |
| 32 | + - FindValue: 5s |
| 33 | + - BatchFindValues: 60s |
| 34 | + - BatchGetValues: 75s |
| 35 | + - StoreData: 10s |
| 36 | + - BatchStoreData: 75s |
| 37 | + - Replicate: 90s |
| 38 | + |
| 39 | +- Upload constraints |
| 40 | + - Max file size: 1 GB (enforced in SDK and server) |
| 41 | + - Adaptive upload chunk size: ~64 KB → 4 MB based on file size |
| 42 | + |
| 43 | +## Core Concepts |
| 44 | + |
| 45 | +- Block: A contiguous segment of the original file. Think of it as a “chapter”. |
| 46 | +- Symbol: A small piece produced by RaptorQ for a block. You only need “enough” symbols to reconstruct the block. |
| 47 | +- Layout: Metadata that lists all blocks (block_id, size, original offset, per‑block hash) and the symbol IDs belonging to each block. |
| 48 | + |
| 49 | +Encode (upload): |
| 50 | +- Choose a block size; RaptorQ creates symbols per block; symbols + layout are stored. |
| 51 | + |
| 52 | +Decode (download): |
| 53 | +- Fetch symbols from the network; reconstruct each block independently; write each block back at its original offset; verify hashes; stream the file. |
| 54 | + |
| 55 | +Key facts: |
| 56 | +- Symbols never mix across blocks. |
| 57 | +- Peak memory during decode scales roughly with the chosen block size (plus overhead). |
| 58 | + |
| 59 | +## File Size Limits & Upload Chunking |
| 60 | + |
| 61 | +- Maximum file size: 1 GB (enforced both in SDK and server handlers). |
| 62 | +- Adaptive upload chunk size: ~64 KB → 4 MB depending on total file size for throughput vs memory stability. |
| 63 | + |
| 64 | +## Encoding/Decoding Workflow (high level) |
| 65 | + |
| 66 | +1) SDK uploads file to a supernode (gRPC stream). Server writes to a temporary file, validates size and integrity. |
| 67 | +2) Server encodes with RaptorQ: produces a symbols directory and a layout JSON. |
| 68 | +3) Server stores artefacts: layout/ID files and symbols into P2P in batches. |
| 69 | +4) Later, SDK requests download; supernode fetches symbols progressively and decodes to reconstruct the file; integrity is verified. |
| 70 | + |
| 71 | +## Contexts & Timeouts (download path) |
| 72 | + |
| 73 | +- SDK: wraps the download RPC with a 10‑minute deadline. |
| 74 | +- Server: uses that context; P2P layer applies per‑RPC timeouts (e.g., 5s for single key FindValue, ~75s for BatchGetValues), with internal early cancellation once enough symbols are found. |
| 75 | +- RaptorQ: uses the same context for logging; no additional deadline inside decode. |
| 76 | + |
| 77 | +## Memory Model |
| 78 | + |
| 79 | +- Decoder memory is primarily a function of block size and concurrency. |
| 80 | +- Headroom percentage reduces the usable memory budget to leave safety buffer for the OS and other processes. |
| 81 | +- Example formula: usable_memory ≈ TotalRAM × (1 − headroom%). |
| 82 | + |
| 83 | +## Configuration Levers |
| 84 | + |
| 85 | +The implementation uses simple fixed constants for safety and predictability. You can adjust them and rebuild. |
| 86 | + |
| 87 | +1) Block Size Cap (`targetBlockMB`, encode‑time) |
| 88 | +- What: Upper bound on block size. Actual used size = min(recommended_by_codec, cap). |
| 89 | +- Effect: Smaller cap lowers peak decode memory (more blocks, more symbols/keys). Larger cap reduces block count (faster on big machines) but raises peak memory. |
| 90 | +- Current default: 256 MB (good balance on well-provisioned machines). Only affects newly encoded artefacts. |
| 91 | + |
| 92 | +2) Redundancy (`defaultRedundancy`, encode‑time) |
| 93 | +- What: Extra protection (more symbols) to tolerate missing data. |
| 94 | +- Effect: Higher redundancy improves recoverability but costs more storage and network I/O. Does not materially change peak memory. |
| 95 | +- Current default: 5 (good real‑world trade‑off). |
| 96 | + |
| 97 | +3) Concurrency (`fixedConcurrency`, decode‑time) |
| 98 | +- What: Number of RaptorQ decode workers. |
| 99 | +- Effect: Higher is faster but multiplies memory; lower is safer and predictable. |
| 100 | +- Current default: 1 (safe default for wide environments). |
| 101 | + |
| 102 | +4) Headroom (`headroomPct`, decode‑time) |
| 103 | +- What: Percentage of detected RAM left unused by the RaptorQ processor. |
| 104 | +- Effect: More headroom = safer under load; less headroom = more memory available to decode. |
| 105 | +- Current default: 20% (conservative and robust for shared hosts). |
| 106 | + |
| 107 | +## Batching Strategy (store path) |
| 108 | + |
| 109 | +Why batching matters: |
| 110 | +- Store batches are loaded wholly into memory before sending to P2P. |
| 111 | +- A fixed “files‑per‑batch” limit gives variable memory usage because symbol files can differ slightly in size. |
| 112 | + |
| 113 | +Current defaults: |
| 114 | +- Foreground adaptor: `loadSymbolsBatchSize = 2500` → ≈ 2,500 × 65,535 B ≈ 156 MiB per batch (typical). |
| 115 | +- Background worker: `loadSymbolsBatchSize = 1000` → ≈ 62.5 MiB per batch. |
| 116 | + |
| 117 | +Byte‑budget alternative (conceptual, not implemented): |
| 118 | +- Cap the total bytes per batch (e.g., 128–256 MiB), with a secondary cap on file count. |
| 119 | +- Benefits: predictable peak memory; better throughput on small symbols; avoids spikes on larger ones. |
| 120 | + |
| 121 | +## Ordering for Throughput (store path) |
| 122 | + |
| 123 | +- We sort relative file paths before batching (e.g., `block_0/...`, `block_1/...`) to improve filesystem locality and reduce disk seeks. This favors speed. |
| 124 | +- Trade‑off: If a process stops mid‑way, earlier blocks (lexicographically smaller) are more likely stored than later ones. For fairness across blocks at partial completion, interleaving could be used at some CPU cost. |
| 125 | + |
| 126 | +## Supernode Selection (download path) |
| 127 | + |
| 128 | +- The SDK ranks supernodes by available memory (fast 2s status probe per node) and attempts downloads in that order. |
| 129 | +- This increases the chances of successful decode for large files. |
| 130 | + |
| 131 | +## Defaults & Suggested Settings |
| 132 | + |
| 133 | +1 GB files (general) |
| 134 | +- Block cap: 256 MB (≈4 blocks) |
| 135 | +- Concurrency: 1 |
| 136 | +- Headroom: 20% |
| 137 | +- Redundancy: 5 |
| 138 | + |
| 139 | +Large‑memory machines (performance‑leaning) |
| 140 | +- Block cap: 256 MB (or 512 MB) to reduce block count and increase throughput. |
| 141 | +- Concurrency: 1–2. |
| 142 | +- Headroom: 15–20% depending on other workloads. |
| 143 | +- Redundancy: 5 (or 6 in sparse networks). |
| 144 | + |
| 145 | +Small‑memory machines |
| 146 | +- Block cap: 64–128 MB |
| 147 | +- Concurrency: 1 |
| 148 | +- Headroom: 20% |
| 149 | +- Redundancy: 5 |
| 150 | + |
| 151 | +## Error Reference |
| 152 | + |
| 153 | +- memory limit exceeded |
| 154 | + - The decoder exceeded its memory budget. Reduce block size or concurrency, increase RAM, or lower headroom. |
| 155 | + |
| 156 | +- hash mismatch for block X |
| 157 | + - Data reconstructed for the block did not match the expected hash. Often indicates wrong/corrupt symbols; can also occur when decoding fails mid‑way under memory pressure. Re‑fetching or re‑encoding may be required. |
| 158 | + |
| 159 | +- insufficient symbols |
| 160 | + - Not enough valid symbols were available; the retriever will fetch more. |
| 161 | + |
| 162 | +- gRPC Internal on download stream |
| 163 | + - The supernode returned an error during decode (e.g., memory failure). The SDK will try the next supernode. |
| 164 | + |
| 165 | +## Code Pointers |
| 166 | + |
| 167 | +- Block cap, headroom, concurrency (RaptorQ): `pkg/codec/raptorq.go` |
| 168 | +- Store batching (foreground path): `supernode/services/cascade/adaptors/p2p.go` |
| 169 | +- Store batching (background worker): `p2p/kademlia/rq_symbols.go` |
| 170 | +- Batch symbol loading / deletion: `pkg/utils/utils.go` (LoadSymbols, DeleteSymbols) |
| 171 | +- Supernode ranking by memory (download): `sdk/task/download.go` |
| 172 | +- File size cap & adaptive upload chunking: SDK and server sides (`sdk/adapters/supernodeservice/adapter.go`, `supernode/node/action/server/cascade/cascade_action_server.go`) |
| 173 | + |
| 174 | +## Notes & Scope |
| 175 | + |
| 176 | +- Changing block size only affects new encodes; existing artefacts keep their original layout. |
| 177 | +- Tuning should reflect your fleet: prefer safety defaults for heterogeneous environments; be aggressive only on known large‑RAM hosts. |
| 178 | + |
| 179 | +## FAQ |
| 180 | + |
| 181 | +- Why might a smaller file decode but a larger file fail? |
| 182 | + - Peak memory grows with data size and chosen block size. A smaller file may fit within the decoder’s memory budget on a given machine, while a larger one may exceed it. Smaller blocks and/or more RAM resolve this. |
| 183 | + |
| 184 | +- Does changing block size affect old files? |
| 185 | + - No. It only affects newly encoded content. Existing artefacts retain their original layout. |
| 186 | + |
| 187 | +- Will smaller blocks slow things down? |
| 188 | + - Slightly, due to more pieces and network lookups. For constrained machines, the reliability gain outweighs the small performance cost. |
| 189 | + |
| 190 | +- What’s the best block size? |
| 191 | + - There’s no single best value. 128 MB is a solid default. Use 64 MB for smaller machines and 256–512 MB for large servers when maximizing throughput. |
0 commit comments