your limit is a measurement
not the sensor's datasheet: it does not know your room
not the best team's number: their setup is not yours
not the arithmetic with the values you wish for
two kilobytes.
twenty-seven minutes.
twenty-seven minutes.
image: ai-generated (gpt-image-2)
you know this screen
the rate is measured. the minutes are a guess made from it, and they jump when it does.
gross and net
nothing was lost. most of it was administration.
where the 24 went
deductions multiply. they do not add up.
pulling the wrong lever
a lever past the bottleneck does not help. it destroys.
what your link really does
| team | net bit/s | how it was measured |
|---|---|---|
| team 3 | 21 | 50 messages, raised the rate until the first error |
| team 9 | 14 | same, but by the window in the afternoon |
| team 6 | 12 | estimated, not measured |
| team 1 | 31 | with a cardboard tube around the sensor |
same hardware. different rooms. different numbers.
three levers, and only three
a faster computer is not one of them.
the same 20 bit/s, twice
the product decides. the two factors decide what breaks first.
the third lever has its own deck
fewer bits in total: compression
costs milliseconds, not safety margin
works before the link, so it works on any link
next: compression
three levers, one file
the levers are independent. that is why they multiply.
every tenth one again
nothing was lost. the link was busy anyway.
acknowledge each, or a block
how big a block? that depends on a number you have to measure.
throughput is not delay
20 bit/s does not mean a one-byte command is there after 0.4 seconds. around it sit the frame, the recognising and the reaction.
today
1 measure your own net rate, and write down how
2 find the lever that is cheapest on your setup, with the number that says so
3 pick a block size for your acknowledgements, with a reason
the neck decides
how much gets through.
you decide
what you send.
how much gets through.
you decide
what you send.
image: ai-generated (gpt-image-2)