dear renaud: my take on this was that we should measure this from a couple RTT samples in the case of SSL, rather than a fixed qty, although the syn/synack pair might be good enough for many purposes.
that said, do you have the simple patch lying around? the dslreports.com tests show the carnage when 8 or 24 flows start simultaneously. I know that those that need TSO for their short transactions will hate it but in my case what I am seeing on an uplink (10mbit) is a giant IW10 GRO packet arrives in the latest routers (where we do not break it up, presently, back into packets), so I would like to fiddle with the concept more. On Fri, Mar 21, 2014 at 8:53 AM, renaud sallantin <[email protected]> wrote: > For our tests, we needed to adjust the "tcp_initial_quantum" in the FQ, > but as you said, it is just a FQ parameter. > > The "patch" we added, and once again, it was just a few lines, enabled to > set, via a sysctl parameter, the initial pacing value, regardless of the > RTT. > This can be valuable for different reasons: > o In case of long RTT, not set the pacing value is going to introduce > an un-necessary delay > (we aims to use this mechanism for satcom, so the delay could be greater > than 500ms) > o In case of a wrong RTT measurement, i.e. an RTT measurement that is > higher that the real RTT (because of congestion for example), you are going > to have a wrong pacing evaluation... > > and finally, for experimental purpose, be able to change the initial pacing > value could be very interesting > > > 2014-03-21 16:06 GMT+01:00 Eric Dumazet <[email protected]>: >> >> On Fri, 2014-03-21 at 09:15 +0100, renaud sallantin wrote: >> >> > >> > FQ/pacing enables to do a lot of things, >> > and as I already said, it could be used to easily implement the >> > Initial Spreading. >> > (we did it and it' s just a few lines to add, and a couple of >> > parameters to change) >> > >> > >> > But for the moment, FQ/Pacing sends the IW in one burst (up to 10 >> > segments). >> > >> >> This is not true. This depends on RTT and your qdisc parameters. >> >> Whole point of TSO autosizing is to make all this stuff automatic. >> >> Here is the tcpdump output for a 10ms RTT, which is quite standard. >> >> You can see 5 packets are sent, with a delay of more than 1 ms. >> >> 07:58:52.616379 IP 10.246.11.51.39905 > 10.246.11.52.41276: S >> 2187811646:2187811646(0) win 29200 <mss 1460,nop,nop,sackOK,nop,wscale 6> >> 07:58:52.626575 IP 10.246.11.52.41276 > 10.246.11.51.39905: S >> 81785763:81785763(0) ack 2187811647 win 29200 <mss >> 1460,nop,nop,sackOK,nop,wscale 7> >> 07:58:52.626642 IP 10.246.11.51.39905 > 10.246.11.52.41276: . ack 1 win >> 457 >> 07:58:52.626671 IP 10.246.11.51.39905 > 10.246.11.52.41276: . 1:2921(2920) >> ack 1 win 457 >> 07:58:52.627740 IP 10.246.11.51.39905 > 10.246.11.52.41276: . >> 2921:5841(2920) ack 1 win 457 >> 07:58:52.628815 IP 10.246.11.51.39905 > 10.246.11.52.41276: . >> 5841:8761(2920) ack 1 win 457 >> 07:58:52.629946 IP 10.246.11.51.39905 > 10.246.11.52.41276: . >> 8761:11681(2920) ack 1 win 457 >> 07:58:52.631054 IP 10.246.11.51.39905 > 10.246.11.52.41276: . >> 11681:14601(2920) ack 1 win 457 >> 07:58:52.637147 IP 10.246.11.52.41276 > 10.246.11.51.39905: . ack 2921 win >> 274 >> 07:58:52.637207 IP 10.246.11.51.39905 > 10.246.11.52.41276: . >> 14601:17521(2920) ack 1 win 457 >> 07:58:52.638117 IP 10.246.11.51.39905 > 10.246.11.52.41276: . >> 17521:20441(2920) ack 1 win 457 >> 07:58:52.638114 IP 10.246.11.52.41276 > 10.246.11.51.39905: . ack 5841 win >> 320 >> 07:58:52.639011 IP 10.246.11.51.39905 > 10.246.11.52.41276: . >> 20441:23361(2920) ack 1 win 457 >> >> >> You also can tune /proc/sys/net/ipv4/tcp_min_tso_segs from 2 to 1 if you >> really want... >> >> No kernel patches needed... >> >> >> > -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
