On Wed, 2012-07-11 at 11:23 -0700, Rick Jones wrote: > On 07/11/2012 08:11 AM, Eric Dumazet wrote: > > > > > > Tests using a single TCP flow. > > > > Tests on 10Gbit links : > > > > > > echo 16384 >/proc/sys/net/ipv4/tcp_limit_output_bytes > > OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 > > (192.168.99.2) port 0 AF_INET > > tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600 > > tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 16 tpci_snd_cwnd 79 > > tcpi_reordering 53 tcpi_total_retrans 0 > > I take it you hacked your local copy of netperf to emit those? Or did I > leave some cruft behind in something I committed to the repository? > Yep, its a netperf-2.5.0 with a one line change to output these TCP_INFO bits
> What was the ultimate limiter on throughput? I notice it didn't achieve > link-rate on either 10 GbE nor 1 GbE. > My lab has one fast machine (source in this 10Gb test), and one slow machine (Intel Q6600 quad core), both with ixgbe cards. On Gigabit test, the receiver is a laptop. > > Thats the plan : limiting numer of bytes in Qdisc, not number of bytes > > in socket write queue. > > So the SO_SNDBUF can still grow rather larger than necessary? It is > just that TCP will be nice to the other flows by not dumping all of it > into the qdisc at once. Latency seen by the application itself is then > unchanged since there will still be (potentially) as much stuff queued > in the SO_SNDBUF as before right? Of course SO_SNDBUF can grow if autotuning is enabled. I think there is a bit of misunderstanding about this patch and what it does. It only makes sure the amount of packets (from socket write queue) are cloned in qdisc/device queue in a limited way, not "as much as allowed" _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
