ndt-users list created

[Richard Carlson <>]

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