On 19 February 2011 08:27, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2011/02/17 19:37, Christiano F. Haesbaert wrote:
>> So here is a better diff, plus the changes to the manpage and usage() which
were
>> lacking.
>> When I get a ENOBUFS in UDP I simply return to event_dispatch().
>
> Nice, it is a bit more consistent than netblast. With 1 byte UDP:
>
> Sent by tcpbench -u -B1 <host>:
>
> Elapsed:        1000 Mbps:       0.626 Peak Mbps:       0.626 Rx PPS:
 78274.000
> Elapsed:        2000 Mbps:       0.577 Peak Mbps:       0.626 Rx PPS:
 72118.000
> Elapsed:        3000 Mbps:       0.628 Peak Mbps:       0.628 Rx PPS:
 78516.000
> Elapsed:        4000 Mbps:       0.643 Peak Mbps:       0.643 Rx PPS:
 80415.000
> Elapsed:        5000 Mbps:       0.615 Peak Mbps:       0.643 Rx PPS:
 76821.000
> Elapsed:        6000 Mbps:       0.581 Peak Mbps:       0.643 Rx PPS:
 72668.000
> Elapsed:        7000 Mbps:       0.639 Peak Mbps:       0.643 Rx PPS:
 79897.000
> Elapsed:        8000 Mbps:       0.590 Peak Mbps:       0.643 Rx PPS:
 73722.000
> Elapsed:        9056 Mbps:       0.604 Peak Mbps:       0.643 Rx PPS:
 75557.000
> Elapsed:       10056 Mbps:       0.483 Peak Mbps:       0.643 Rx PPS:
 60432.000
> Elapsed:       11056 Mbps:       0.624 Peak Mbps:       0.643 Rx PPS:
 78059.000
> Elapsed:       12056 Mbps:       0.627 Peak Mbps:       0.643 Rx PPS:
 78360.000
> Elapsed:       13056 Mbps:       0.607 Peak Mbps:       0.643 Rx PPS:
 75828.000
> Elapsed:       14056 Mbps:       0.637 Peak Mbps:       0.643 Rx PPS:
 79679.000
> Elapsed:       15056 Mbps:       0.621 Peak Mbps:       0.643 Rx PPS:
 77680.000
>
> Sent by netblast <host> 12345 1 30:
>
> Elapsed:        1285 Mbps:       0.528 Peak Mbps:       0.528 Rx PPS:
 65954.000
> Elapsed:        2285 Mbps:       0.730 Peak Mbps:       0.730 Rx PPS:
 91231.000
> Elapsed:        3285 Mbps:       0.738 Peak Mbps:       0.738 Rx PPS:
 92197.000
> Elapsed:        4285 Mbps:       0.639 Peak Mbps:       0.738 Rx PPS:
 79835.000
> Elapsed:        5285 Mbps:       0.418 Peak Mbps:       0.738 Rx PPS:
 52238.000
> Elapsed:        6303 Mbps:       0.339 Peak Mbps:       0.738 Rx PPS:
 42413.000
> Elapsed:        7303 Mbps:       0.683 Peak Mbps:       0.738 Rx PPS:
 85437.000
> Elapsed:        8303 Mbps:       0.677 Peak Mbps:       0.738 Rx PPS:
 84674.000
> Elapsed:        9303 Mbps:       0.487 Peak Mbps:       0.738 Rx PPS:
 60928.000
> Elapsed:       10303 Mbps:       0.565 Peak Mbps:       0.738 Rx PPS:
 70665.000
> Elapsed:       11303 Mbps:       0.588 Peak Mbps:       0.738 Rx PPS:
 73527.000
> Elapsed:       12375 Mbps:       0.513 Peak Mbps:       0.738 Rx PPS:
 64082.000
> Elapsed:       13375 Mbps:       0.698 Peak Mbps:       0.738 Rx PPS:
 87302.000
> Elapsed:       14375 Mbps:       0.700 Peak Mbps:       0.738 Rx PPS:
 87440.000
> Elapsed:       15375 Mbps:       0.574 Peak Mbps:       0.738 Rx PPS:
 71786.000
>
> (tcpbench -u -s makes a nice receiver for netblast/netsend :-)
>
>
>> -The default is 262144 bytes.
>> +The default is 262144 bytes for TCP client/server and UDP server. In UDP
client,
>> +this may be used to specify the packet size on the test stream.
>
> New sentence should be on a new line (here and in a couple of
> other lines), e.g.
>
> +The default is 262144 bytes for TCP client/server and UDP server.
> +In UDP client, this may be used to specify the packet size on the test
stream.
>

Cool, will change that, thanks !

> Maybe I would say 'In UDP client mode, [...]'
>
> One documentation nit (not related to your changes),
>
>     tcpbench [-v] [-u] [-B buf] [-k kvars] [-n connections] [-p port]
>              [-r rate] [-S space] [-V rtable] hostname
>
> I think using "rate" here implies something about packet rate,
> but this is actually for reporting, I would prefer the word
> "interval".
>
>> +#define DEFAULT_UDP_PKT (1500 - 28) /* TODO don't hardcode this */
>
> I think you'll have to do a route lookup to determine the MTU of
> the recipient to avoid hardcoding this.
>

True, I think that is unnecessary for now.

Any more feedback ?
Any chance this goes in ?

Reply via email to