Measured

Latency

Every remote play client claims to be fast. This one leaves evidence: each session appends a line to a record on your own machine, naming the decoder, the renderer, the requested bitrate and both loss settings, with the timing of each stage of the frame path beside them.

What is timed

✓Receive. Where the packet lands. The step is budgeted at zero bytes of allocation per packet, because a collection in the middle of a stream is a stutter with no visible cause.
✓Reorder dwell. How long a packet waited for the ones in front of it, which is the difference between a network that is lossy and one that is merely late.
✓Reassemble. Units back into the frame the encoder produced.
✓Error correction. What it cost to rebuild what the network dropped.
✓Decoder send-to-pull. The frame handed to the GPU and taken back, which is the stage a decoder choice actually changes.
✓A latency floor. Input queueing plus the console's own reported round trip, in milliseconds: the part of glass-to-glass the client can see without a camera.

Two runs, one table

compare-baselines reads two records and prints p50, p99 and maximum per stage with the difference between them. It refuses a comparison whose two halves do not have the same field set, because a row that gained a field silently is two questions and one answer.

It stays on your machine

The record is a file in your own application data. Nothing is uploaded, there is no account, and no part of the application asks for one. The reason the numbers exist is so that two builds can be compared here, on the hardware that has to run them.