On Tue, Jan 20, 2026 at 1:53 PM Jakub Kicinski <[email protected]> wrote: > > On Mon, 19 Jan 2026 19:58:52 +0100 [email protected] > wrote: > > Linux Accurate ECN test sets using ACE counters and AccECN options to > > cover several scenarios: Connection teardown, different ACK conditions, > > counter wrapping, SACK space grabbing, fallback schemes, negotiation > > retransmission/reorder/loss, AccECN option drop/loss, different > > handshake reflectors, data with marking, and different sysctl values. > > Thank you for closing the packetdrill side, and big thanks to Neal > for prioritizing getting it reviewed and merged! > > I updated the packetdrill build in netdev CI and looks like one of > the cases is flaking a little. Since it looks like you'll have to > respin, please try to fix: > > # 1..2 > # tcp_accecn_client_accecn_options_lost.pkt:32: error handling packet: timing > error: expected outbound packet in relative time range +0.020000~+0.500000 > sec but happened at +0.015816 sec > # script packet: 0.181936 .5 1:1013(1012) ack 1 <ECN e1b 1 ceb 0 e0b 1,nop> > # actual packet: 0.177752 .EA 1:1013(1012) ack 1 win 1050 <ECN e1b 1 ceb 0 > e0b 1,nop> > # not ok 1 ipv4 > # tcp_accecn_client_accecn_options_lost.pkt:32: error handling packet: timing > error: expected outbound packet in relative time range +0.020000~+0.500000 > sec but happened at +0.015800 sec > # script packet: 0.181952 .5 1:1013(1012) ack 1 <ECN e1b 1 ceb 0 e0b 1,nop> > # actual packet: 0.177752 .EA 1:1013(1012) ack 1 win 1050 <ECN e1b 1 ceb 0 > e0b 1,nop> > # not ok 2 ipv6 > # # Totals: pass:0 fail:2 xfail:0 xpass:0 skip:0 error:0 > > https://netdev-ctrl.bots.linux.dev/logs/vmksft/packetdrill/results/482201/115-tcp-accecn-client-accecn-options-lost-pkt/stdout
Probably this is happening because the SRTT is around 56ms: .050 * 7/8 + 1/8 * .1 = .05625 sec So the RACK fast recovery starts afte rabout 15ms due to .25 * srtt being about 14ms: (.050 * 7/8 + 1/8 * .1) * .25 = .0140625 sec If we make the SRTT 100ms then the fast retransmit should be around: (.1 * 7/8 + 1/8 * .1) * .25 = .025 sec So I'd suggest changing the timing of the SYNACK from 50ms to 100ms: old: +0.05 < [ect0] SW. 0:0(0) ack 1 win 32767 <mss 1024,ECN e0b 1 ceb 0 e1b 1,nop,nop,nop,sackOK,nop,wscale 8> new: +.1 < [ect0] SW. 0:0(0) ack 1 win 32767 <mss 1024,ECN e0b 1 ceb 0 e1b 1,nop,nop,nop,sackOK,nop,wscale 8> neal
