iperf question

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
If I do a simple iperf test such as this:

iperf -s on machine with IP 10.1.1.2
then
iperf -c 10.1.1.2

What speed is it telling me? The speed from server to the client (Rx
speed on client) or the speed from the client to the server (Tx on client)

The iperf tutorial says:

"By default, the Iperf client connects to the Iperf server on the TCP
port 5001 and the bandwidth displayed by Iperf is the bandwidth from the
client to the server."

Which would seem to be Tx speed on the client? or not?

Re: iperf question
Quoted text here. Click to load it

That's how I read it too.

You can possibly check with netstat -e (windows,
I think unix may be the same).

C:\\Users\\me>netstat -e
Interface Statistics

                           Received            Sent

Bytes                     604839852        31041106


hmmm!
I thought that Windows gave seperate stats for
different interface but no interface name is listed here.
Still even if aggregated you will likely be able to
work it out.

As I recall there is an iperf option to do both ways
at once.

Sadly as far as I know this counter cannot be reset
so you will either have to reboot or figure out differences.

*OR*

of course - if on windows use perfmon. There are interface
stats in there. That is a *much* better idea.


Re: iperf question
On 28/01/2009 16:04, George wrote:
Quoted text here. Click to load it
I would say not. Iperf and Jperf are used to measure the bandwidth and
quality of a network link and that link is dependent on at least 2 hosts
and therefore the result that you get is the bandwidth between the 2
hosts in the direction of client to server. If you were to take the case
of wireless PC>>WirelessRouter>>Wireless PC then the Tx speed between
one PC and the router may be 2x but the router will act as a store and
forward device so the Tx speed from the router will only be x to the
other PC so while the client may have a Tx speed of 2x the complete
network link will not.

Re: iperf question
Quoted text here. Click to load it


That would be correct.
The default is 10 seconds, and an 8K window.  You might want to increase
that a bit to see what the best speed is.
Variations on the max with different OS levels and tuning, but you might
want to try

        iperf -w 256k -s
        iperf -w 256k -c  ip-address-of-target -i 10 -t 1000

--
Clarence A Dold - Hidden Valley Lake, CA, USA  GPS: 38.8,-122.5

Re: iperf question
wrote:

Quoted text here. Click to load it

Don't know.  You didn't post the test results.

Quoted text here. Click to load it

Yep.  It's the speed from the client to the server.
However, you can control the direction with various options.  Try
   Iperf -h
for a list.  

These might be useful:  
  -d, --dualtest           Do a bidirectional test simultaneously
  -r, --tradeoff           Do a bidirectional test individually
  -P, --parallel  #        number of parallel client threads to run


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558            jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com               AE6KS

Re: iperf question
Jeff Liebermann wrote:
Quoted text here. Click to load it

Caught me, I was trying to decide whatever result it presented referred
to what direction relative to one of the hosts to help me decide what to
look at.

I am troubleshooting a general speed issue and isolated it to the wired
LAN speed from the server which is highly asymmetrical. iperf reported
300 kbit in one direction and 70 Mbit in the other direction just
working on the wired 100 Mbit LAN using my notebook and also another
server for testing. Updating NIC drivers and turning off scalable
networking brought the low speed up to 5 Mbit which is still lame. The
server has a GigE card and there is a 100Mbit unmanaged switch . Forcing
link speed on the server to various auto/full/half didn't make much
difference. I suggested they replace the switch with a GigE switch which
makes sense because there are two servers with GigE capability. I think
the server NIC just doesn't like talking to the switch. The server had a
second onboard NIC and I switched to it and also tried various switch
ports and it didn't make a difference.


Quoted text here. Click to load it
I have tried switches like -d but it simply gives both results leaving
you to wonder which is what.

Re: server NIC speed question
tnx - should have just given us all the info & real question to begin
with....
---

Quoted text here. Click to load it

what does the switch admin screen show for the port being used ?
speed, config, errors ?



Re: server NIC speed question
ps56k wrote:
Quoted text here. Click to load it
Unfortunately it is a unmanaged 10/100 switch. We have a "web managed"
GigE switch coming which might cure the problem.

Re: iperf question
George wrote:
Quoted text here. Click to load it
....

Unless something /really/ weird is going on, the two should be pretty
much identical on a LAN. Are you testing over some sort of assymetrical
circuit?

I guess if one machine was a 486 and the other a Sun M8000 you might see
some discrepancies...


Re: iperf question
wrote:

Quoted text here. Click to load it

Good question, but an obvious answer, which you already supplied.

Hint:  If you have a problem that needs solving, then please supply:
1.  What problem are you trying to solve?
2.  What hardware and software do you have to work with?
3.  What have you done so far and what happened?

Quoted text here. Click to load it

I've seen this literally dozens of times.  Lots of causes ranging from
bad NIC's, NWAY negotiation failure, CAT5 cable wiring problems,
connector failure, media converter failure, hung ethernet switch,
full/half duplex problems at the NIC, overly busy server, etc.  I'm
going to be my usual obnoxious self and not offer any more until you
disclose what hardware you're working with and how you're doing the
iperf testing (specific command line incantations).  That's because
UDP and TCP testing often yield very different results.

Quoted text here. Click to load it

Wrong on both numbers.  I consistently get 90-95Mbits/sec from a
10/100baseT ethernet switch.  Obviously, the 300Kbit/sec is also
wrong.  You might try removing the intermediate switch, grab some
known good CAT5 cables, and go directly from the "other" server and
your notebook.  Also, check the settings on the ethernet port on both
machines.  You can sorta create the problem by having one set to full
duplex, and the other to half duplex.

Replace the cables, test server, and/or switch, one at a time, until
the problem evaporates.  It's called troubleshooting by substitution.

Quoted text here. Click to load it

It shouldn't make any difference.  Since updating the driver has such
a derastic effect, you might consider the possibility that the
unspecificed device with the NIC card is having a bad day.  It could
be busy from some errant process.  It could have a bad NIC.

Quoted text here. Click to load it

Any particular model number GigE card?  

Quoted text here. Click to load it

Maker and model?  Yeah, I know I'm demand a lot by asking you to
supply such details.  However, there are some boxes out there that are
little better than defective.

Quoted text here. Click to load it

Forcing it where?  At the server?  At the laptop?  With a mechanical
switch on your unspecified unmanaged switch?

Quoted text here. Click to load it

Yeah, that makes sense if the intermediate wiring is 1000baseT
qualified?  What manner of cable and how long?

Quoted text here. Click to load it

I also don't like talking to people and devices that I know nothing
about.

Quoted text here. Click to load it

Try a 2nd laptop in place of the server.  See if the unspecified model
GigE switch is the problem.

Quoted text here. Click to load it

If you have both directions, does it really matter which is which as
long as they're the same?  Methinks you're avoiding the problem.

Your question has absolutely nothing to do with wireless or wireless
internet.  You might consider asking the same question (with the
missing details supplied) in one of the networking newsgroups.


--
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

Re: iperf question
Jeff Liebermann wrote:
Quoted text here. Click to load it
just vanilla TCP using iperf -c <server IP>
Quoted text here. Click to load it

Agree, it is a remote location and I simply ran out of time because of
an ice storm that was closing in. I replaced the cables and have a GigE
switch on order as a replacement.


Quoted text here. Click to load it

Its a Dell Poweredge 1950 with dual onboard Broadcom Net Extreme II
NICs. I configured the other NIC and switched over to it but there was
no difference.

Quoted text here. Click to load it

It is a D-link something (can't read my notes)

Quoted text here. Click to load it

At the server.

Quoted text here. Click to load it

The switch is right above the servers so only short patch cables are needed.

Quoted text here. Click to load it
Yes, thank you much for your interest and suggestions.  I didn't go into
big details initially because I just wanted to understand what iperf was
telling me.

Re: NIC question & troubleshooting
x-posted to some other useful groups -

Quoted text here. Click to load it



Re: iperf question
Quoted text here. Click to load it



This is in my view most likely the result of a duplex
missmatch.
A duplex missmatch can cause asymetric behavior
since one end is halfD and the other fullD:) The HD end
behaves correctly and the FD end does not causing Rx
errors and consequent lost frames at the HD end.

If sending towards the HD end then the performance is
likely to be poor. The other way is likelier to be better.

Set everything to Auto to start with and test.
Then check all accessible counters for
Rx errors - CRC errors, runts
Tx Errors - Late collisions

A significant number of Rx errors is likely to be
the result of you looking at the FD end of a mismatch


ANY Late collisions (Tx errors) means that either you
you are looking at the HD end of a missmatch.
*OR*
network is too big (>2500 meter diameter collision domain).
This is unlikely these days.

Windows perfmon is the place to look or netstat -e.

It might of course be the result of a bad cable or port
but missconfiguration is *much* more likely.

These WORK

Auto - HD
Auto - Auto
HD - HD
FD - FD

These fail BY DESIGN

Auto - FD
FD - HD

Speed detection *always* works but if you set
the two ends differently then I guess it wont.

Your unmanaged switch *will* be Auto. So you have to set
connected devices to Auto *or* HD.

Re: iperf question
wrote:

Quoted text here. Click to load it

I posted gigabit test results and procedures in the distant past. See:
<http://groups.google.com/group/alt.internet.wireless/msg/e48bedc2001a1e71?dmode=source
Note that you have to set some of the iperf parameters as the defaults
will not deliver more than about half the rated speed.  You haven't
hit this problem yet, but you will when you replace the DLink
something with a Gigabit switch.

Quoted text here. Click to load it

I wouldn't excatly call that isolated.  It could be the server,
wiring, switch, more wiring, client, or test parameters.  However, the
most likely is the switch.  If flow control was failing in the switch,
you would get such a unidirectional failure.

Quoted text here. Click to load it

As I previously indicated, *BOTH* numbers are wrong.  You should get
more than 70Mbit/sec and of cours the 0.3Mbits/sec is far too low.  As
you noted, a new switch is probably in order, but you can't be sure
certain that it's not the server until you try replacing it with a 2nd
laptop or a desktop to act as an iperf server.  Re-run the iperf test,
this time without the server.

Quoted text here. Click to load it

Ok, I'll stop insisting on model numbers.  Might was well guess that
the 100baseT switch or associated wiring is a problem.

Quoted text here. Click to load it

Ok, that might eliminate NWAY failure.  However, you need to power
cycle the ethernet switch, or at least temporarily unplug the
corresponding ethernet jack, to make sure that it will restart NWAY
negotiation.

Quoted text here. Click to load it

Duh, yes.... that makes sense.

Quoted text here. Click to load it

I think you're avoiding the problem.  You haven't said anything about
checking or replacing the cabling.  Ethernet switches are sufficiently
common that you could have borrowed one from somewhere and tried
substitution.  It could also be a busy or gutless server or client.
Hard to tell from here.

Quoted text here. Click to load it

True.  It's not obvious from the results.  However, you can use other
diagnostics to (netstat) to see what direction things are moving. Just
looking at the properties for the network card in Windoze will show a
counter with the number of bytes moved.  There's also the Performance
Monitor:
  Start -> Run -> Perfmon
which will show network direction and performance.  While not clearly
stated on the results, it can be deduced.



--
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

Site Timeline