<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><DIV>Hi Rick,</DIV>
<DIV>Thank you a bunch for all the support that you have been extending.</DIV>
<DIV>After obtaining the updated file src/nettest_bsd.c from the trunk, I have built a fresh copy of "netperf.exe" for Windows 7, Win2K3 and Win2K8 R2 (64-bit) platforms.<BR>Also, I have compiled a fresh installation on my Linux server (10.219.192.20) with the new src/nettest_bsd.c file.</DIV>
<DIV>The result is not what I am expecting (recv_response: partial response received: 0 bytes). </DIV>
<DIV>Atleast happy that no errors this time.</DIV>
<DIV>The query result with debug enabled attached for your reference. (same in all windows platforms)</DIV>
<DIV>Please let me know, if I need to this differently to get the desired result. Thank you.</DIV>
<DIV>Regards<BR>Vinod </DIV>
<DIV><BR>C:\>netperf.exe -f m -i 9,3 -t TCP_STREAM -H 10.219.192.20 -l 20 -c -- -s 131072<BR> -S 131072<BR>TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.219.192.20 (10.219.192.20) port 0 AF_INET : +/-2.500% @ 99% conf.<BR>recv_response: partial response received: 0 bytes</DIV>
<DIV>C:\>netperf.exe -d -f m -i 9,3 -t TCP_STREAM -H 10.219.192.20 -l 20 -c -- -s 131072 -S 131072<BR>resolve_host called with host '10.219.192.20' port '(null)' family AF_UNSPEC<BR>getaddrinfo returned the following for host '10.219.192.20' port '(null)' family AF_UNSPEC<BR> cannonical name: '10.219.192.20'<BR> flags: 4 family: AF_INET: socktype: SOCK_STREAM protocol IPPROTO_TCP addrlen 16<BR> sa_family: AF_INET sadata: 0 0 10 219 192 20 0 0 0 0 0 0 0 0 17 0<BR>scan_sockets_args called with the following argument vector<BR>netperf.exe -d -f m -i 9 -t TCP_STREAM -H 10.219.192.20 -l 20 -c -- -s 131072 -S 131072<BR>Program name: netperf.exe<BR>Local send alignment: 8<BR>Local recv alignment: 8<BR>Remote send alignment: 8<BR>Remote recv alignment: 8<BR>Report local CPU 1<BR>Report remote CPU 0<BR>Verbosity: 1<BR>Debug:
1<BR>Port: 12865<BR>Test name: TCP_STREAM<BR>Test bytes: 0 Test time: 20 Test trans: 0<BR>Host name: 10.219.192.20</DIV>
<DIV>remotehost is 10.219.192.20 and port 12865<BR>resolve_host called with host '10.219.192.20' port '12865' family AF_INET<BR>getaddrinfo returned the following for host '10.219.192.20' port '12865' family AF_INET<BR> cannonical name: '10.219.192.20'<BR> flags: 4 family: AF_INET: socktype: SOCK_STREAM protocol IPPROTO_TCP addrlen 16<BR> sa_family: AF_INET sadata: 50 65 10 219 192 20 0 0 0 0 0 0 0 0 3 0<BR>resolve_host called with host '0.0.0.0' port '0' family AF_UNSPEC<BR>getaddrinfo returned the following for host '0.0.0.0' port '0' family AF_UNSPEC</DIV>
<DIV> cannonical name: '0.0.0.0'<BR> flags: 4 family: AF_INET: socktype: SOCK_STREAM protocol IPPROTO_TCP addrlen 16<BR> sa_family: AF_INET sadata: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 17 0<BR>establish_control called with host '10.219.192.20' port '12865' remfam AF_INET<BR> local '0.0.0.0' port '0' locfam AF_UNSPEC<BR>bound control socket to 0.0.0.0 and 0<BR>successful connection to remote netserver at 10.219.192.20 and 12865<BR>complete_addrinfo using hostname 10.219.192.20 port 0 family AF_INET type SOCK_STREAM prot IPPROTO_TCP flags 0x0<BR>getaddrinfo returned the following for host '10.219.192.20' port '0' family AF_INET<BR> cannonical name:
'10.219.192.20'<BR> flags: 4 family: AF_INET: socktype: SOCK_STREAM protocol IPPROTO_TCP addrlen 16<BR> sa_family: AF_INET sadata: 0 0 10 219 192 20 0 0 0 0 0 0 0 0 4 0<BR>local_data_address not set, using local_host_name of '0.0.0.0'<BR>complete_addrinfo using hostname 0.0.0.0 port 0 family AF_UNSPEC type SOCK_STREAM prot IPPROTO_TCP flags 0x1<BR>getaddrinfo returned the following for host '0.0.0.0' port '0' family AF_UNSPEC</DIV>
<DIV> cannonical name: '0.0.0.0'<BR> flags: 4 family: AF_INET: socktype: SOCK_STREAM protocol IPPROTO_TCP addrlen 16<BR> sa_family: AF_INET sadata: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0<BR>TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.219.192.20 (10.219.192.20) port 0 AF_INET : +/-2.500% @ 99% conf.<BR>create_data_socket: socket 1912 obtained...<BR>netperf: get_sock_buffer: send socket size determined to be 131072<BR>netperf: get_sock_buffer: receive socket size determined to be 131072<BR>send_tcp_stream: send_socket obtained...<BR>recv_response: received a 256 byte response<BR>remote listen done.<BR>recv_response: received a 256 byte response<BR>remote reporting results for 20.28 seconds<BR>correction factor: 1.000000<BR>calc_service_demand called: units_sent =
45350912.000000<BR> elapsed_time = 0.000000<BR> cpu_util = 0.000000<BR> num cpu = 0<BR>calc_service_demand using: units_sent = 45350912.000000<BR> elapsed_time =
20.281250<BR> cpu_util = 0.462250<BR> num cpu = 2<BR>calc_service_demand got: thruput = 2183.691834<BR> servdem = 4.233652<BR>calculate_confidence: itr 1; time 20.281250; res 17.888804<BR> lcpu 0.462250; rcpu
-1.000000<BR> lsdm 4.233653; rsdm -1.000000<BR>create_data_socket: socket 1912 obtained...<BR>netperf: get_sock_buffer: send socket size determined to be 131072<BR>netperf: get_sock_buffer: receive socket size determined to be 131072<BR>send_tcp_stream: send_socket obtained...<BR>recv_response: received a 256 byte response<BR>remote listen done.<BR>recv_response: received a 0 byte response<BR>recv_response: partial response received: 0 bytes</DIV>
<DIV>C:\><BR><BR>--- On <B>Wed, 7/27/11, Rick Jones <I><rick.jones2@hp.com></I></B> wrote:<BR></DIV>
<BLOCKQUOTE style="BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"><BR>From: Rick Jones <rick.jones2@hp.com><BR>Subject: Re: [netperf-talk] NetPerf fails in Windows 2008 Server<BR>To: "Vinod Pademar" <vinod323@yahoo.com><BR>Cc: "netperf-talk@netperf.org" <netperf-talk@netperf.org><BR>Date: Wednesday, July 27, 2011, 4:08 AM<BR><BR>
<DIV class=plainMail>So, I managed to find the diffs that someone sent back in March - they tweak some things in src/nettest_bsd.c to deal with race conditions between the test thread and the one emulating SIGALRM. I honestly don't know if they will address the problem you are encountering, but I've gone ahead and checked them into the top of trunk.<BR><BR>Meanwhile, I'm wondering if there might be a slightly cleaner way to deal with the netlib.c compilation problem - perhaps with casts alone and not an additional variable?<BR><BR>rick<BR></DIV></BLOCKQUOTE></td></tr></table>