Skip to content

fix: use sliding window for download speed display#1535

Open
ianbmacdonald wants to merge 1 commit intolemonade-sdk:mainfrom
ianbmacdonald:fix/download-speed-sliding-window
Open

fix: use sliding window for download speed display#1535
ianbmacdonald wants to merge 1 commit intolemonade-sdk:mainfrom
ianbmacdonald:fix/download-speed-sliding-window

Conversation

@ianbmacdonald
Copy link
Copy Markdown
Collaborator

@ianbmacdonald ianbmacdonald commented Apr 4, 2026

Summary

  • Replaces the all-time average speed calculation with a 5-second sliding window, showing actual recent throughput instead of a dragged-down session average.
  • Records timestamped byte samples on each progress event, prunes samples older than 5 seconds, and computes speed from the window edges.
  • Cleans up sample data on download completion and error.

Problem

The Download Manager computed speed as totalBytes / totalElapsedTime — the average over the entire session. If early portions of the download were slow (API negotiation, initial buffering, HF rate limiting ramp-up), the displayed speed remained far below actual throughput. In testing, btop showed ~925 MiB/s network throughput while the app displayed only 15 MB/s.

Changes

  • src/app/src/renderer/DownloadManager.tsx — Add useRef-based sliding window sample storage, record samples in handleDownloadUpdate, clean up in completion/error handlers, rewrite calculateSpeed to use window.

Test plan

  • Verified speed display reflects actual throughput during active download
  • Verified ETA calculation remains accurate (uses same calculateSpeed)
  • Verified speed shows -- initially (before 2 samples collected)
  • No memory leak from sample accumulation — samples pruned to 5s window on every event, map cleaned up on completion/error

🤖 Generated with Claude Code

@ianbmacdonald ianbmacdonald marked this pull request as ready for review April 4, 2026 04:15
@ianbmacdonald ianbmacdonald force-pushed the fix/download-speed-sliding-window branch 2 times, most recently from c324aae to 691434e Compare April 8, 2026 03:29
The download speed display was showing the all-time average (total bytes
/ total elapsed time), which drastically underreported actual throughput
when early portions of the download were slow or there was initial
negotiation delay.

Switch to a 5-second sliding window: record timestamped byte samples on
each progress event, prune samples older than 5s, and compute speed from
the window edges. This shows the actual recent throughput.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ianbmacdonald ianbmacdonald force-pushed the fix/download-speed-sliding-window branch from 691434e to 358bfbf Compare April 8, 2026 21:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant