Re: [Make-wifi-fast] Fwd: iperf 2 "short term" road map

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Bob McMahon <bob.mcmahon@broadcom.com> writes:

> Hi Toke,
>
> Do let me know.  We're focused on the network i/o testing aspect (per being
> a WiFi chip vendor) and are intentionally not trying to provide CPU load
> metrics. (I think netperf provides both.)  A feature we are adding is to
> warn when we think something other than the socket reads() and writes()
> have become bottlenecks, e.g. in a CPU constrained system it becomes an
> "entangled metric" between i/o and CPU though still presents in network i/o
> units which can be misleading to network device vendors.
>
> Also, many might want to consider monitoring "network power" which is
> average throughput / latency or delay, i.e. "something good" / "something
> bad"

It's more socket-level statistics I'm after for Flent use; we generally
run multiple instances (flows) concurrently and graph the results. This
is the variables we currently extract from Netperf:

    output_vars = 'THROUGHPUT,LOCAL_CONG_CONTROL,REMOTE_CONG_CONTROL,' \
                  'TRANSPORT_MSS,LOCAL_TRANSPORT_RETRANS,' \
                  'REMOTE_TRANSPORT_RETRANS,LOCAL_SOCKET_TOS,' \
                  'REMOTE_SOCKET_TOS,DIRECTION,ELAPSED_TIME,PROTOCOL,' \
                  'LOCAL_SEND_SIZE,LOCAL_RECV_SIZE,' \
                  'REMOTE_SEND_SIZE,REMOTE_RECV_SIZE,' \
                  'LOCAL_BYTES_SENT,LOCAL_BYTES_RECVD,' \
                  'REMOTE_BYTES_SENT,REMOTE_BYTES_RECVD'

Some of these can be set as well (such as TOS and congestion control
algorithm).


Also, how safe is it to run an iperf server instance on the public
internet? :)

-Toke