[netperf-talk] Packet size

[Rick Jones]

Clive Barker wrote:
> Rick, thanks again! the information provided is extremely helpful!
> 
> I would generate some 150 instances using either TCP/UDP stream and 
> specifying the packet size. I will not be mixing packet sizes on the 
> instances..
> 
> I guess the next qtn is adjusting the rate at which packet is sent. Is 
> this something that is utilized with the burst option? What i was hoping 
> to do was to send packets at a specified rate to the router and see the 
> effect it has on accepting new connections.

That would be the "intervals" functionality - ./configure --enable-intervals, 
which will give you global -b <burst size> and -w <burst interval> options.

Be aware that on some platforms, if it takes longer than <burst interval> to send 
a burst of <burst size> the test will terminate prematurely.

The effective values of  <burst interval> will depend on the effective 
granularity of setitimer() on the running platform.

While I would not suggest it for 150 concurrent netperfs there is also a 
--enable-spin configure option that will replace the interval timer with a 
sit-and-spin interface.  Much finer granulatiry, at the cost of a massive 
increase in CPU utilization on the sending system - each instance of netperf 
using spinning will attempt to fully consume a single core on the system.

there are some other tidbits scattered in:

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

happy benchmarking,

rick jones

> 
> --- On *Thu, 3/26/09, Rick Jones /<rick.jones2 at hp.com>/* wrote:
> 
>     From: Rick Jones <rick.jones2 at hp.com>
>     Subject: Re: [netperf-talk] Packet size
>     To: echelon360 at yahoo.com
>     Cc: netperf-talk at netperf.org
>     Date: Thursday, March 26, 2009, 9:47 AM
> 
> Clive Barker wrote:
>> Hello,
>> 
>> is there an option for me to send traffic and include a packet size, i
> need to generate several instances of netperf and have 3 separate runs starting
> from 512bytes, 256bytes then 128bytes.
>> 
>> is this possible?
> 
> Is this TCP or UDP?  For UDP, since each send is a UDP datagram, you have
> direct control over the UDP datagram size with the test-specific -m option:
> 
> netperf -H <remote> -t UDP_STREAM -- -m 128
> 
> will have a stream of UDP datagrams with 128 byte user payloads, added to that
> will be 8 bytes of UDP header, 20 bytes (typically) of IPv4 header (or N bytes
> of IPv6 header) and then M bytes of data-link header (14 for Ethernet).
> 
> If this is TCP, you have _indirect_ control over the quantity of data in each
> TCP segment with a combination of the -m and -D (TCP_NODELAY):
> 
> netperf -H <remote> -t TCP_STREAM -- -m 128
>  -D
> 
> will *ask* TCP to not bundle-up successive sends into larger TCP segments.  So,
> barring packet losses and retransmissions that will be 128 bytes of user payload
> per segment, with 32 bytes (I'm including TCP timestamp option, 20 without
> it) of TCP header, and then IP and data-link headers as with UDP.
> 
> Keep in mind that while 128, 256 and 512 bytes are usually smaller than a link
> MTU, they don't _have_ to be, and so you could have either IP fragmentation
> in the UDP case or TCP segmentation.
> 
> Now, if you mean you wanted a *mix* of packet sizes in the same
> stream/flow/connection, that is something else, and is presently addressed in
> netperf4, the egg-laying-woolly-milk-pig :) netperf.
> 
> rick jones
> 
>