the same speed is computed in MiB/s in some places and MB/s in others, all labelled "MB/s"

[LeyckerS]

Speeds are divided by two different constants depending on where they are computed, and every one of them reaches the user labelled MB/s:

Where	Code	Unit it actually is
Per-file live speed	moon_download.py:513 — / 1_048_576	MiB/s
Per-file final average	moon_download.py:545 — / 1e6	MB/s
Engine aggregate speed	moon_engine.py:582 — / 1_048_576	MiB/s
Report session speed	moon_download.py:275, 337 — / 1e6	MB/s
Stall detector threshold	moon_download.py:525 — / 1e6	MB/s

1_048_576 / 1_000_000 = 1.048576, so the two families disagree by 4.9% for the same real transfer rate.

Two visible consequences:

• A file downloading at a perfectly steady rate shows one number while it runs and a ~4.9% higher number the moment it completes, with nothing having changed.
• The live speed in the GUI and the "Session speed" line in the moontech_*.log report disagree by 4.9% for the same run.

The stall detector is the one place where the choice actually matters beyond display: STALL_MIN_MBS is compared against an /1e6 value, so whichever convention is chosen, that comparison must stay consistent with the constant's intended meaning.

Acceptance criteria

• One convention throughout. /1e6 with the label MB/s is the honest pairing and matches what the reports already claim
• The live number and the final average for the same file agree
• STALL_MIN_MBS still means what its name and its comment say
• Say in the pull request which convention you picked and list every line you changed

No Windows machine needed to reason about it, though it is worth a real run to confirm the numbers now line up.

[happykawayigt]

I can take this. I’ll standardize the live and aggregate paths on decimal MB/s, update the ETA conversion consistently, and add focused regression coverage.

[LeyckerS]

@happykawayigt — yours, assigned.

Your plan of standardising on decimal MB/s is the right call: it is what the reports already claim in their own labels, so it is the convention that makes the fewest things liars.

Two things to watch:

• STALL_MIN_MBS is not a display value. It is compared against an /1e6 figure in the stall detector, so whatever you do elsewhere, that comparison has to keep meaning what the constant's name says. Changing the units under it would quietly re-tune when a download gets killed.
• the per-file live speed in the GUI is roughly nine times the real rate #86 touches the same expressions. It found that the per-file live speed reads about nine times the real rate, measured against a run's own report — a much bigger error than this 4.9%. If they land first you will need to rebase; if you land first, say so there. Worth reading before you start so the two fixes do not fight.

[LeyckerS]

@happykawayigt — one more file for your list. moon_cli.py:106 divides by 1_048_576 too, in a progress loop the CLI keeps separate from Engine.snapshot(). A patch that standardises moon_engine.py and moon_download.py but not the CLI would leave the two front-ends reporting different numbers for the same run — which is the problem, not a smaller version of it.

There is now an issue about removing that duplication entirely, but it is a bigger change than yours and should not block you. Just include the CLI line.

[LeyckerS]

@happykawayigt — still yours, and no rush. Two things have changed around this issue since you claimed it.

moon_download.py moved. #120 (@XEDAB) added an on_event callback and routed the four mid-transfer notes through a note() helper, and #119 (@felix-windsor) changed how destination filenames are reserved. Neither touches the speed arithmetic, but both edit the same file, so pull main first.

The related issue got sharper. #86 measured the per-file live speed at roughly nine times the real rate — 38 MB/s on screen against a median 4.2 MB/s in the same run's own report. That is a different bug from yours (it divides by the age of the oldest retained sample instead of the observation window) but it lives in the same expressions.

That matters for scope: if you standardise the units and someone later fixes #86, they will be editing the lines you just touched. Either order works. Whichever you do, say in the pull request whether you deliberately left the window arithmetic alone — I would expect you to, and stating it stops the next person guessing.

The third file is still moon_cli.py:106, which carries the same 1_048_576 and the same window bug in a copy the engine does not share. #97 covers removing that duplication properly, but until it lands, a fix that only touches the engine leaves the CLI reporting different numbers for the same run.

If you want to hand it back that is completely fine — say so and I will free it. One sentence saying you are still on it keeps it yours for as long as you need.