Thanks for the prompt reply. There is no pkt loss, none, at either netem, pfifo_fast. or TCP level (from netstat -s -t). This is a back2back 1GbE link with one iperf test running. For the 150ms delay case, tcptrace shows the TCP receive window never grows beyond ~15.5MB. That probably explains partly the low (~615Mbps) throughput. Jerry On 10/19/06, John Heffner <jheffner@xxxxxxx> wrote:
H.K. Jerry Chu wrote: > Hello, > > I'm testing 2.6.18 over an emulated long haul network (using netem > with 100ms delay). > For some reason if I just rely on the autotuning ffeature of the stack > (i.e., no -w to > iperf) over a 1GbE link, I can only get ~820Mbps throughput. All the > other sysctl > tunables (e.g., tcp_rmem, tcp_wmem) have been set to sufficiently large > (4096 8388608 20971520). In order to saturate the link I had to > specify SO_SND/RCVBUF > sizes to, e.g, 13MB using the -w option to iperf, effectively > disabling autotuning. > > I also discovered that the autotuning deficiency seems to reside only > on the xmit side, > i.e., if i specify -w 13m on the xmit side only I can attain 945Mbps > throughput. > > Also if i increase the delay to 150ms I can only get up to ~615Mbps > from autotuning. > > Am I bumping into some known bugs? Are you getting any packet losses? Sometimes autotuning allows congestion control to operate as it should, which does not always fully utilize a link. Careful hand tuning can give you a window that is capped just below congestion so you avoid packet losses altogether and get perfect utilization. This situation isn't a bug, just a limitation of TCP congestion control. I'm not sure this is what's happening to you. Can you check? -John
- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
