`NP_ChannelLatencyReductionPercentage` ships 75, not 0, so a real install
really does take three quarters of the round trip off a channel's end.
Without it a press held through a channel is sent a round trip late, which
is the cost the whole press queue exists to remove — leaving this stored
would have left the queue's worst case exactly where it started.
**Why sending early here is conservative and not reckless**, which is the
part worth writing down. The server starts the channel at T and ends it at
T + duration; we only learn of it half a trip later, so our own end sits at
T + L/2 + duration — half a trip *after* the server is already free.
Trimming 75% of L puts our end at T + duration − L/4, and a packet sent
then reaches the server at T + duration + L/4: still after its own end, by
a quarter of a trip. Same arithmetic as the cast buffer, and the round trip
it removes was never real work.
It reads the channel's **named** end, not the slack-inflated one. That
slack is two seconds of belt-and-braces for a lost `MSG_CHANNEL_UPDATE(0)`,
and reading it here would make every channel look longer than it is — the
pop gate was doing exactly that, so the press would have fired a round trip
and then some after the channel finished.
With no pong measured yet nothing is trimmed, which is the safe direction
to be wrong in. The lock is recovered rather than unwrapped, as every
reader of it is, and that matters more here than at the latency meter: the
cast path reads it now, and a poisoned lock must not take the ability to
cast with it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
39932b12da