Topic

TCP

1 post about TCP. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Posts

Clickhouse
Chasing that 32 ms tail latency in ClickHouse
A customer observed an extra ~32 ms tail latency on simple SELECT queries after idle periods in ClickHouse’s Native TCP protocol. The root cause was that after a TCP idle period (RTO), the congestion window resets to initcwnd (8 MSS), and with TCP_NODELAY enabled, each metadata packet (ProfileEvents, Logs, Progress) becomes a separate TCP segment, exceeding the small window and forcing an additional round trip. The ClickHouse Native protocol sends these metadata packets between Data and EndOfStream, and the unbatched writes caused the problem. The team reproduced the issue deterministically using Linux network namespaces and tc to simulate 32 ms RTT and initcwnd 8. They fixed it by batching those metadata packets into a single buffer write at the application layer, reducing tail latency from ~32 ms to ~1 ms, as confirmed by a Go client program that measured the time between the last Data packet and EndOfStream.

The best engineering reads, once a week.

Topic

1 post about TCP. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Clickhouse
Chasing that 32 ms tail latency in ClickHouse
A customer observed an extra ~32 ms tail latency on simple SELECT queries after idle periods in ClickHouse’s Native TCP protocol. The root cause was that after a TCP idle period (RTO), the congestion window resets to initcwnd (8 MSS), and with TCP_NODELAY enabled, each metadata packet (ProfileEvents, Logs, Progress) becomes a separate TCP segment, exceeding the small window and forcing an additional round trip. The ClickHouse Native protocol sends these metadata packets between Data and EndOfStream, and the unbatched writes caused the problem. The team reproduced the issue deterministically using Linux network namespaces and tc to simulate 32 ms RTT and initcwnd 8. They fixed it by batching those metadata packets into a single buffer write at the application layer, reducing tail latency from ~32 ms to ~1 ms, as confirmed by a Go client program that measured the time between the last Data packet and EndOfStream.

The best engineering reads, once a week.