[netperf-dev] do you depend heavily on netperf header formats?

[anil mishra]

Thanks, I will download from the trunk and run the test.
  

Rick Jones <rick.jones2 at hp.com> wrote:
  anil mishra wrote:
> Yes, having the header information is helpful to understand the output.

I wasn't going to remove the header, it just might not look the same.

> For TCP_RR, if it gives the calculated latency (RTT/2), that will be 
> helpful.
> 
> Also, can it be possible to specify the mtu size, TCP Window parameter 
> etc. in the command if user wants to use it like that?

Netperf will never specify the MTU size. That is too far down the stack 
for netperf to be messing with. At present, it can _report_ the *MSS* 
of the connection when the verbosity is >= 2. I'm still waffling on 
whether or not to include the option to try to _set_ the MSS via the 
TCP_MAXSEG option.

The TCP window settings are presumed to derive from the socket buffer 
settings made (-s and -S) before the connection is established.


I have checked-in a first pass at some changes to have the TCP_RR test 
allow one to ask for bitrate rather than transactions per second as the 
primary figure of merit. Also, for the verbosity > 2 level, it will 
report the average RTT latensy, the transactions/s and the inbound and 
outbound bitrates.

You can try-out the bits from the top of trunk in the repository:

http://www.netperf.org/svn/netperf2/trunk/

>From the Release Notes (not in the docs since this is still experimental)



*) One can now pass a value of 'x' to the global -f option to specify
the units as transactions per second. This is the default for any
request/response test, which is determined by there being a "double
`r'" in the name - eg "RR," "rr," "Rr," or "rR." At present only
the TCP_RR test actually looks for this to be set.

*) One can request bits/bytes per second as the primary output of a
TCP_RR test by setting the global -f option to [kmgKMG] as with any
of the "STREAM" tests. This converts the primary throughput metric
to a bitrate (byterate) following the verbosity rules for a STREAM
test. Service demand remains usec/Transaction regardless of the
setting of the global -f option.

A verbosity level of 2 or more will cause the TCP_RR test to report
calculated average RTT latency, transaction rate, and inbound and
outbound transfer rates regardless of the primary units selected
with the global -f paramter. If the primary output is transactions
per second, the reported inbound and outbound transfer rates will
be 10^6 bits per second, otherwise, they honor the setting of the
global -f option.

All of this is EXPERIMENTAL and subject to change without prior
notice in future versions of netperf.



an example with the primary figure of merit still transactions/s:

raj at tardy:~/netperf2_trunk$ src/netperf -H tardy.cup.hp.com -v 2 -f x -t 
TCP_RR -- -r 1024 -b 120 -S 1M -s 1M -D
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay : first burst 120
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

219136 219136 1024 1024 10.00 9209.07
1048576 1048576
Alignment Offset RoundTrip Trans Throughput
Local Remote Local Remote Latency Rate 10^6bits/s
Send Recv Send Recv usec/Tran per sec Outbound Inbound
8 0 0 0 13139.216 9209.073 75.441 75.441

and one with it as MB/s:

raj at tardy:~/netperf2_trunk$ src/netperf -H tardy.cup.hp.com -v 2 -f M -t 
TCP_RR -- -r 1024 -b 120 -S 1M -s 1M -D
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay : first burst 120
Local /Remote
Socket Size Request Resp. Elapsed
Send Recv Size Size Time Throughput
bytes Bytes bytes bytes secs. MBytes/sec

219136 219136 1024 1024 10.01 15.84
1048576 1048576
Alignment Offset RoundTrip Trans Throughput
Local Remote Local Remote Latency Rate MBytes /s
Send Recv Send Recv usec/Tran per sec Outbound Inbound
8 0 0 0 14921.124 8109.309 7.919 7.919

note that both were using the "first burst" option. Here is a simpler 
one with just the classic single-byte request/response and no actual burst:

raj at tardy:~/netperf2_trunk$ src/netperf -H tardy.cup.hp.com -v 2 -t TCP_RR
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : first burst 0
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 10.00 783.88
32768 32768
Alignment Offset RoundTrip Trans Throughput
Local Remote Local Remote Latency Rate 10^6bits/s
Send Recv Send Recv usec/Tran per sec Outbound Inbound
8 0 0 0 1275.702 783.882 0.006 0.006


> 
> */Rick Jones /* wrote:
> 
> If you depend heavily on the netperf header format, please let me know
> ASAP. Since it is possible now to use a netperf TCP_RR test to perform
> a bidirectional transfer on the same connection, I would like to modify
> things so one can ask for output in the same units as the STREAM tests.
> 
> This _may_ alter what one sees by default for the headers of a TCP_RR
> test and I want to know if it will break anyone's scripts or whatnot.
> 
> happy benchmarking,
> 
> rick jones
> _______________________________________________
> netperf-dev mailing list
> netperf-dev at netperf.org
> http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-dev
> 
> 
> ------------------------------------------------------------------------
> Get the Yahoo! toolbar and be alerted to new email 
> wherever 
> you're surfing.



       
---------------------------------
Need a vacation? Get great deals to amazing places on Yahoo! Travel. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.netperf.org/pipermail/netperf-dev/attachments/20070612/6e19170b/attachment.htm