[netperf-talk] Considering declaring a 2.6.0 release
Cook, Jonathan
jonathan.cook at nist.gov
Mon Apr 30 15:26:56 PDT 2012
The autogen.sh script fixed the ./configure problem and the new version of netserver fixed the problem with using -b and -D together.
I always use the omni tests and I am doing UDP and TCP tests in both receive and transmit directions. The PAD_TIME is always added to the elapsed time when performing a UDP receive test (that is, with netserver running on Linux and netperf running on Windows). PAD_TIME is never added to the elapsed time for the other tests I am running.
I was hoping there would be a way for netserver to report interim results to netperf during a UDP send test so the user would only have to monitor the netperf side to see true throughput. I haven't looked at the messaging between netserver and netperf so I don't know if that is a practical possibility.
Here is an example of the PAD_TIME being added to the elapsed time. The test was set to run for 10 seconds, but the elapsed time is shown as 12 seconds. If you calculate the elapsed time from the local bytes received and final throughput then netperf appears to have used an elapsed time of 16 seconds.
G:\netperf>netperf.exe -H10.8.7.240 -L10.8.34.147 -tOMNI -l 10 -fk -D 1 -- -Tudp
-dreceive -m,1400 -s128k -S128k -O PROTOCOL,THROUGHPUT,THROUGHPUT_UNITS,DIRECTI
ON,ELAPSED_TIME,REMOTE_BYTES_RECVD,LOCAL_BYTES_RECVD, -R1
OMNI Receive TEST from 10.8.34.147 () port 0 AF_INET to 10.8.7.240 () port 0 AF_
INET : histogram : demo
Interim result: 57259.71 10^3bits/s over 1.001 seconds ending at 1335800367.046
Interim result: 58016.58 10^3bits/s over 1.008 seconds ending at 1335800368.062
Interim result: 57996.42 10^3bits/s over 1.004 seconds ending at 1335800369.062
Interim result: 58831.09 10^3bits/s over 1.001 seconds ending at 1335800370.062
Interim result: 58759.71 10^3bits/s over 1.003 seconds ending at 1335800371.062
Interim result: 58475.54 10^3bits/s over 1.005 seconds ending at 1335800372.062
Interim result: 58236.37 10^3bits/s over 1.004 seconds ending at 1335800373.078
Interim result: 57772.79 10^3bits/s over 1.008 seconds ending at 1335800374.078
Interim result: 57373.61 10^3bits/s over 1.007 seconds ending at 1335800375.093
Interim result: 57303.65 10^3bits/s over 1.001 seconds ending at 1335800376.093
Protocol Throughput Throughput Direction Elapsed Remote Local
Units Time Bytes Bytes
(sec) Received Received
UDP 39081.70 10^3bits/s Receive 12.00 0 78163400
-----Original Message-----
From: Rick Jones [mailto:rick.jones2 at hp.com]
Sent: Monday, April 30, 2012 11:19 AM
To: Cook, Jonathan
Cc: netperf-talk at netperf.org; netperf-dev at netperf.org
Subject: Re: [netperf-talk] Considering declaring a 2.6.0 release
On 04/30/2012 09:29 AM, Cook, Jonathan wrote:
> It builds and runs on Windows now which I think is a great thing. However, I cannot build on my Linux machine that I am running netserver on. Here is the error:
> ./configure: line 5323: syntax error near unexpected token `ac_cv_sockaddr_has_sa_len'
> ./configure: line 5323: `AC_CHECK_SA_LEN(ac_cv_sockaddr_has_sa_len)'
The joys of autoconf I suspect. I encounter that from time to time as I'm moving bits about via subversion, and deal with it via the autogen.sh script. You might try ./autogen.sh at the top of the
netperf2 tree and see if that clears-up the ./configure problem.
> Since I couldn't build the latest netserver on the Linux machine I
> used an older version with revision 572 netperf built on Windows and
> came up with some comments and requests.
> 1. The -b global option seems to nullify the -D global option.
> Interim results do not get shown when using the -b global option. I
> would like to use the two options together.
It would seem to be functioning fine for me:
raj at tardy:~/netperf2_trunk$ src/netperf -l 10 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain () port 0 AF_INET : interval : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 25830.48
raj at tardy:~/netperf2_trunk$ src/netperf -l 10 -w 1 -b 10 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain () port 0 AF_INET : interval : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 131.07
raj at tardy:~/netperf2_trunk$ src/netperf -l 10 -w 1 -b 10 -D 1 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain () port 0 AF_INET : interval : demo Interim result: 131.81 10^6bits/s over 1.030 seconds ending at
1335805647.922
Interim result: 130.43 10^6bits/s over 1.010 seconds ending at
1335805648.932
Interim result: 131.72 10^6bits/s over 1.000 seconds ending at
1335805649.932
Interim result: 130.44 10^6bits/s over 1.010 seconds ending at
1335805650.942
Interim result: 131.71 10^6bits/s over 1.000 seconds ending at
1335805651.943
Interim result: 130.44 10^6bits/s over 1.010 seconds ending at
1335805652.952
Interim result: 131.85 10^6bits/s over 1.000 seconds ending at
1335805653.952
Interim result: 130.42 10^6bits/s over 1.010 seconds ending at
1335805654.962
Interim result: 131.72 10^6bits/s over 1.000 seconds ending at
1335805655.963
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 131.07
Though I will point-out that a change in top-of-trunk has converted the global -D option from one where a parameter is optional to one where it is required. That may have altered the interaction. The previous code for -D may have "consumed" a following option if there was no parameter associated with the -D.
> 2. When using Windows the PAD_TIME gets added to the elapsed time
> causing the final throughput to appear lower than any of the interim
> results.
As I recall, the test does not always have PAD_TIME added to the elapsed time, yes?
> 3. Is it possible to display the interim results from the netserver
> (receive) end when doing a netperf send test? When I do a UDP send
> test the interim results displayed are much higher than the final
> throughput due to packets getting lost.
Ostensibly, if you use the "omni" tests one can do a UDP send test with the netperf side as the receiver. I haven't actually tried that in a long while though.
It would be something along the lines of:
netperf -H <remote> -t omni -- -T udp -d recv ...
Since I'm already running netperf for this email, here is an example:
raj at tardy:~/netperf2_trunk$ src/netperf -l 10 -t omni -D 1 -- -T UDP -d recv -O rss_size_end,lsr_size_end,remote_send_size,throughput,throughput_units,protocol
OMNI Receive TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain () port 0 AF_INET : interval : demo Interim result: 29355.75 10^6bits/s over 1.000 seconds ending at
1335805952.868
Interim result: 29349.47 10^6bits/s over 1.000 seconds ending at
1335805953.868
Interim result: 29299.48 10^6bits/s over 1.002 seconds ending at
1335805954.870
Interim result: 29465.97 10^6bits/s over 1.000 seconds ending at
1335805955.870
Interim result: 29779.85 10^6bits/s over 1.000 seconds ending at
1335805956.870
Interim result: 29715.55 10^6bits/s over 1.002 seconds ending at
1335805957.872
Interim result: 30187.69 10^6bits/s over 1.000 seconds ending at
1335805958.872
Interim result: 29947.33 10^6bits/s over 1.008 seconds ending at
1335805959.880
Interim result: 29771.90 10^6bits/s over 1.006 seconds ending at
1335805960.886
Remote Local Remote Throughput Throughput Protocol
Send Socket Recv Socket Send Units
Size Size Size
Final Final
126976 126976 65507 21218.54 10^6bits/s UDP
It though may have an intermittent issue with PAD_TIME too :) The extent to which that can be detected/compensated for is a good question.
While, IIRC, the "omni" tests will attempt to signal end-of-test via a series of zero-length UDP datagrams, that is not a "reliable" signal.
And even if the timer does pop, we don't "know" that the data stream actually terminated PAD_TIME seconds ago (long latency networks, buffer-bloat, etc - anywhere where one sees a TCP_STREAM test end somewhat longer than the desired test-time is the situation I'm thinking of)
rick
>
> I have attached the commands I used and the results.
>
> Thanks,
> Jon Cook
>
> -----Original Message-----
> From: netperf-talk-bounces at netperf.org [mailto:netperf-talk-bounces at netperf.org] On Behalf Of Rick Jones
> Sent: Friday, April 27, 2012 3:20 PM
> To: netperf-talk at netperf.org; netperf-dev at netperf.org
> Subject: [netperf-talk] Considering declaring a 2.6.0 release
>
> Folks -
>
> There have been enough changes to netperf2 since the 2.5.0 release that I'm considering declaring a 2.6.0 release. So, if you could grab top-of-trunk bits and try them out and let me know what problems you find I would appreciate it.
>
> sincerely,
>
> rick jones
>
> (2.6.0 rather than 2.5.1 because some of the changes altered the control message size - again :) and while netperf never has supported mixed versions, if I know I've made a change like that, upping the middle digit seems warranted) _______________________________________________
> netperf-talk mailing list
> netperf-talk at netperf.org
> http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-talk
More information about the netperf-talk
mailing list