[netperf-talk] Considering declaring a 2.6.0 release
Rick Jones
rick.jones2 at hp.com
Mon Apr 30 10:19:18 PDT 2012
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