[netperf-talk] Why the test results were diffentent between netperf win32 version and Vmware+RedHat9 version

[Rick Jones]

Ye wrote:
> Hi, 
> I am using netperf to test a Netcard. 
> I built two version of netperf . One is win32 version with VS.net 
> 2003.The other is RedHat9 version running on the Vmware workstation.
> Both are netperf clients and  ran on the same PC. The netperf server ran 
> at a Linux server and it is linux version.
> The test command :  netperf -H 172.16.52.56
> I was expecting this two version would report the same result. But they 
> didn't .

Given that Linux and Windows have two very different TCP/IP implementations, 
expecting them to have the same TCP performance is generally going to be incorrect.

> Linux version result:
> $ netperf -H 172.16.52.56
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.16.52.65 
> (172.16.52.65) port 0 AF_INET
> Recv   Send    Send                          
> Socket Socket  Message  Elapsed              
> Size   Size    Size     Time     Throughput  
> bytes  bytes   bytes    secs.    10^6bits/sec  
> 
>  87380  16384  16384    10.01      91.15  
> 
> Win32 version result:
> ./winnetperfclient.exe -H 172.16.52.65
> TCP STREAM TEST from (null) (0.0.0.0) port 0 AF_INET to (null) 
> (172.16.52.65) port 0 AF_INET
> Recv   Send    Send                          
> Socket Socket  Message  Elapsed              
> Size   Size    Size     Time     Throughput  
> bytes  bytes   bytes    secs.    10^6bits/sec  
> 
>  87380   8192   8192    10.00      82.93   
> 
> Dose anyone know why the results were different? 
> Did it mean win32 socket implement is poor than linux implement? 

One limit to the performance of a TCP connection is discussed in an attachment 
along with a checklist of sorts.

"Classic" (non-omni) netperf tests on Linux cannot account for the automatic 
growth of the TCP window over the life of a connection.  So, while it is 
reporting a recv socket size of 87380 and send of 16384, by the end of the 
connection those were probably rather larger.

Windows does not "grow" the window like Linux does - in this case then you can 
presume that the Window was 8192 bytes.

If you add some test-specific -s and -S options you can get the two stacks to use 
the same socket buffer sizes.

netperf -H <remote> -- -s 16K -S 16K -m 16K

This will turn-off the Linux autotuning. however, you will notice on Linux 
netperf will report 32K - the Linux stack does a "2x" (up to a sysctl limit) for 
overhead tracking that it exposes to the user.

To be certain you get the same window in both cases you should take a packet 
trace which includes the connection establishement (to see the window scaling 
options) and then calculate the window sizes being advertised by the remote.

Even if you see the two stacks reporting the same throughput, that still does not 
_really_ mean the two stacks have the same "performance."   One stack might use 
more CPU to achieve the same level of throughput.  That is why you should also 
enable CPU utilization in all your tests.  Then netperf will report the CPU 
utilization and will also calculate a measure of efficiency called a "service 
demand" - the quantity of CPU time required to perform a unit of work.

netperf -c -C -H <remote> -- -s 16K -S 16K -m 16K


> 
> best regards
> Ye
> 
> 
>  
> 
>  
>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netperf-talk mailing list
> netperf-talk at netperf.org
> http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-talk

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: net_perf_list
Url: http://www.netperf.org/pipermail/netperf-talk/attachments/20090224/1a67f160/attachment.txt