Skip to Content.
Sympa Menu

ndt-users - Re: Amount of data sent on each test

Subject: ndt-users list created

List archive

Re: Amount of data sent on each test


Chronological Thread 
  • From: Richard Carlson <>
  • To: Clarke Morledge <>
  • Cc: Jordi Bosch <>,
  • Subject: Re: Amount of data sent on each test
  • Date: Thu, 24 Apr 2008 15:38:09 -0400

Hi Clarke;

I'm waiting for the MS engineers to get back to me on this. I have sent them some traces and said that it appears that things aren't working right. I haven't heard back yet on any possible patches.

The last report I sent them showed that both XP and Vista based hosts were getting very low throughput over long RTT paths. In tracing this behavior I found that the Win PC was sending 16 KB of data per RTT, so throughput was basically 16636*8/RTT b/s. The longer the RTT the lower the throughput.

The MS engineers responded and said the kernel wasn't getting data fast enough and that is what was limiting the speed. I ran some experiments and found that raising the application buffer from 8 KN to 64 KB improved the throughput, but it's still RTT limited. I also pointed out that the application send loop isn't doing anything but dumping buffers down to the stack and it seemed strange that raising this buffer size actually improved things. MS is suppose to be looking at this some more.

I haven't noticed any issues when the Win PC is receiving data.

As to your particular problem, is this a Windows XP host or Vista? XP has an old stack with manual tuning parameters. Try using the TCPoptimizer from speedguide to look at/change the settings http://www.speedguide.net/downloads.php A Reno compliant TCP, like that found in XP, will have trouble with Out-of-order packets dropping into a timeout if the ooo value is large enough. The TCPoptimizer tool does allow you to reset the ooo threshold and that may help some hosts.

Other than that, I'll need to wait for MS to get back to me.

Rich
At 04:20 PM 4/23/2008, Clarke Morledge wrote:
On Wed, 23 Apr 2008, Richard Carlson wrote:

The NDT sending process (C2S or S2C) runs in a tight 'do loop" dumping 8KB buffers down to the kernel for delivery over the network. I am currently testing a change in the C2S test to move 64 KB blocks down to the kernel to overcome a problem with Windows based hosts. The kernel is responsible for breaking these buffers into packets and TCP then delivers them across the network. All the data generated by the application should be sent to the remote receiving host. I would be interested in seeing network traces that show some data blocks getting dropped by the kernel.

Rich,

Are you at liberty to discuss what the problem is with Windows based hosts? We are seeing some cases where Windows XP does not have the same performance numbers when compared to hosts with other OSes. But we haven't been able to make a good apples-to-apples comparison yet.

One thing we've been seeing is that in a high bandwidth, low latency environment that if a Windows host sees a number of TCP packets delivered to it out-of-order that the TCP/IP stack does not always handle that situation very well. I do NOT have enough hard data available to stand on that observation, but it has come up frequently enough on our NDT tests that I was wondering if anyone has discovered something peculiar with the Windows TCP/IP stack.

This could just be a corner case due to some local architectural issues we have, but your comment drew my interest.

Thanks.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187

------------------------------------



Richard A. Carlson e-mail:

Network Engineer phone: (734) 352-7043
Internet2 fax: (734) 913-4255
1000 Oakbrook Dr; Suite 300
Ann Arbor, MI 48104



Archive powered by MHonArc 2.6.16.

Top of Page