126 lines
4.1 KiB
Markdown
126 lines
4.1 KiB
Markdown
# BACKBEAT Tempo Recommendations
|
|
|
|
## Why Slower Beats Make Sense for Distributed Systems
|
|
|
|
Unlike musical BPM (120+ beats per minute), distributed task coordination works better with much slower tempos. Here's why:
|
|
|
|
### Recommended Tempo Ranges
|
|
|
|
**Development & Testing: 1-2 BPM**
|
|
- 1 BPM = 60-second beats (1 minute per beat)
|
|
- 2 BPM = 30-second beats (30 seconds per beat)
|
|
- Perfect for debugging and observing system behavior
|
|
- Plenty of time to see what agents are doing within each beat
|
|
|
|
**Production: 5-12 BPM**
|
|
- 5 BPM = 12-second beats
|
|
- 12 BPM = 5-second beats
|
|
- Good balance between responsiveness and coordination overhead
|
|
- Reasonable for most distributed task processing
|
|
|
|
**High-Frequency (Special Cases): 30-60 BPM**
|
|
- 30 BPM = 2-second beats
|
|
- 60 BPM = 1-second beats
|
|
- Only for very short-duration tasks
|
|
- High coordination overhead
|
|
|
|
### Window Sizing Examples
|
|
|
|
With **2 BPM (30-second beats)** and **4 beats per window**:
|
|
- Each window = 2 minutes
|
|
- Downbeats every 2 minutes for secret rotation, rollups, reviews
|
|
- Agents report status every 30 seconds
|
|
- Reasonable time for meaningful work between status updates
|
|
|
|
With **12 BPM (5-second beats)** and **8 beats per window**:
|
|
- Each window = 40 seconds
|
|
- Downbeats every 40 seconds
|
|
- Agents report every 5 seconds
|
|
- More responsive but higher coordination overhead
|
|
|
|
### Why Not 120+ BPM?
|
|
|
|
**120 BPM = 500ms beats** - This is far too fast because:
|
|
- Agents would report status twice per second
|
|
- No time for meaningful work between beats
|
|
- Network latency (50-100ms) becomes significant fraction of beat time
|
|
- High coordination overhead drowns out actual work
|
|
- Human operators can't observe or debug system behavior
|
|
|
|
### Beat Budget Examples
|
|
|
|
With **2 BPM (30-second beats)**:
|
|
- `withBeatBudget(4, task)` = 2-minute timeout
|
|
- `withBeatBudget(10, task)` = 5-minute timeout
|
|
- Natural timeout periods that make sense for real tasks
|
|
|
|
With **120 BPM (0.5-second beats)**:
|
|
- `withBeatBudget(10, task)` = 5-second timeout
|
|
- Most meaningful tasks would need budget of 100+ beats
|
|
- Defeats the purpose of beat-based timeouts
|
|
|
|
## BACKBEAT Default Settings
|
|
|
|
**Current Defaults (Updated):**
|
|
- Pulse service: `1 BPM` (60-second beats)
|
|
- Window size: `8 beats` = 4 minutes per window
|
|
- Min BPM: `1` (60-second beats for debugging)
|
|
- Max BPM: `24` (2.5-second beats for high-frequency systems)
|
|
|
|
**Configuration Examples:**
|
|
|
|
```bash
|
|
# Development - very slow for debugging
|
|
./pulse -bpm 1 -bar 4 # 60s beats, 4min windows
|
|
|
|
# Production - balanced
|
|
./pulse -bpm 5 -bar 6 # 12s beats, 72s windows
|
|
|
|
# High-frequency - only if needed
|
|
./pulse -bpm 24 -bar 10 # ~2.5s beats, 25s windows
|
|
```
|
|
|
|
## Integration with CHORUS Agents
|
|
|
|
When CHORUS agents become BACKBEAT-aware, they'll report status on each beat:
|
|
|
|
**With 2 BPM (30s beats):**
|
|
```
|
|
T+0s: Agent starts task, reports "executing", 10 beats remaining
|
|
T+30s: Beat 1 - reports "executing", 9 beats remaining, 20% progress
|
|
T+60s: Beat 2 - reports "executing", 8 beats remaining, 40% progress
|
|
T+90s: Beat 3 - reports "review", 0 beats remaining, 100% progress
|
|
T+120s: Downbeat - window closes, reverb generates BarReport
|
|
```
|
|
|
|
**With 120 BPM (0.5s beats) - NOT RECOMMENDED:**
|
|
```
|
|
T+0.0s: Agent starts task, reports "executing", 600 beats remaining
|
|
T+0.5s: Beat 1 - barely any progress to report
|
|
T+1.0s: Beat 2 - still barely any progress
|
|
... (598 more rapid-fire status updates)
|
|
T+300s: Finally done, but coordination overhead was massive
|
|
```
|
|
|
|
## Performance Impact
|
|
|
|
**Slower beats (1-12 BPM):**
|
|
- ✅ Meaningful status updates
|
|
- ✅ Human-observable behavior
|
|
- ✅ Reasonable coordination overhead
|
|
- ✅ Network jitter tolerance
|
|
- ✅ Debugging friendly
|
|
|
|
**Faster beats (60+ BPM):**
|
|
- ❌ Status spam with little information
|
|
- ❌ High coordination overhead
|
|
- ❌ Network jitter becomes significant
|
|
- ❌ Impossible to debug or observe
|
|
- ❌ Most real tasks need huge beat budgets
|
|
|
|
## Conclusion
|
|
|
|
BACKBEAT is designed for **distributed task coordination**, not musical timing. Slower beats (1-12 BPM) provide the right balance of coordination and efficiency for real distributed work.
|
|
|
|
The updated defaults (2 BPM, 8 beats/window) give a solid foundation that works well for both development and production use cases.
|