STATUS: v1.0.0 was measuring the wrong thing confidently. Two bugs, found by
using it rather than testing it.
UPLOAD, hard failure: crypto.getRandomValues() is spec-capped at 65536 bytes
PER CALL and I asked for 1048576. It threw, and the whole upload leg died with
"can only generate maximum 65536 bytes". Now: fill one 64 KiB block and tile it
into the Blob. Still incompressible, and one call instead of sixteen.
DOWNLOAD, the interesting one: the test finished in half the expected time AND
reported half the expected speed. Both symptoms, one cause. v1.0.0 pulled a
FIXED 50 MiB and averaged over the entire transfer — on a fast link that
completes before TCP is out of slow-start, so the congestion-window ramp is
baked into the average. A short run and a low number are the same bug wearing
two hats.
Fixed by measuring the way the real ones do:
- FIXED DURATION, not fixed size: 1.5s warmup DISCARDED, then a 6s measured
window. Slow-start never enters the average.
- PARALLEL STREAMS (4): a single TCP connection cannot fill a high
bandwidth-delay-product path. One stream measures the connection; several
measure the link. This is why naive single-stream tests read low and
everyone else's numbers look inflated by comparison. They are not.
- The live readout now reports the measured window only, so the number stops
drifting upward as the ramp washes out of a cumulative average.
Brock's verdict on the shape of the thing stands: "perfect for a first version,
just a cut off small utility." The utility was fine. The methodology was not.
The node remains online. The first number it gave you was wrong. Against my
better judgment, it now is not.
neonoverlord
a7f3795ba4