iperf question

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?

On 28 Jan, 16:04, George <geo...@nospam.invalid> wrote:
> 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?

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.

George <(E-Mail Removed)> wrote:
> iperf -s on machine with IP 10.1.1.2
> then
> iperf -c 10.1.1.2

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

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

Jeff Liebermann wrote:
> On Wed, 28 Jan 2009 11:04:47 -0500, George <(E-Mail Removed)>
> wrote:
>
>> 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?
>
> Don't know. You didn't post the test results.

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.


>
>> 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?
>
> 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
>
>
I have tried switches like -d but it simply gives both results leaving
you to wonder which is what.

tnx - should have just given us all the info & real question to begin
with....
---

"George" <(E-Mail Removed)> wrote in message
news:glsm2l$pbi$(E-Mail Removed)...
> 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.
>
>

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

ps56k wrote:
> tnx - should have just given us all the info & real question to begin
> with....
> ---
>
> "George" <(E-Mail Removed)> wrote in message
> news:glsm2l$pbi$(E-Mail Removed)...
>> 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.
>>
>>
>
> what does the switch admin screen show for the port being used ?
> speed, config, errors ?
>
>
Unfortunately it is a unmanaged 10/100 switch. We have a "web managed"
GigE switch coming which might cure the problem.

Jeff Liebermann wrote:
> On Thu, 29 Jan 2009 11:38:41 -0500, George <(E-Mail Removed)>
> wrote:
>
>> 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.
>
> 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?
>
>> I am troubleshooting a general speed issue and isolated it to the wired
>> LAN speed from the server which is highly asymmetrical.
>
> 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.
>
just vanilla TCP using iperf -c <server IP>
>> 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.
>
> 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.

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.


>
>> Updating NIC drivers and turning off scalable
>> networking brought the low speed up to 5 Mbit which is still lame.
>
> 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.
>
>> The
>> server has a GigE card
>
> Any particular model number GigE card?

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.

>
>> and there is a 100Mbit unmanaged switch.
>
> 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.
>

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

>> Forcing
>> link speed on the server to various auto/full/half didn't make much
>> difference.
>
> Forcing it where? At the server? At the laptop? With a mechanical
> switch on your unspecified unmanaged switch?

At the server.

>
>> I suggested they replace the switch with a GigE switch which
>> makes sense because there are two servers with GigE capability.
>
> Yeah, that makes sense if the intermediate wiring is 1000baseT
> qualified? What manner of cable and how long?

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

>
>> I think
>> the server NIC just doesn't like talking to the switch.
>
> I also don't like talking to people and devices that I know nothing
> about.
>
>> 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.
>
> Try a 2nd laptop in place of the server. See if the unspecified model
> GigE switch is the problem.
>
>> I have tried switches like -d but it simply gives both results leaving
>> you to wonder which is what.
>
> 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.
>
>
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.

x-posted to some other useful groups -

"George" <(E-Mail Removed)> wrote in message
news:glv10h$3nr$(E-Mail Removed)...
> Jeff Liebermann wrote:
>> On Thu, 29 Jan 2009 11:38:41 -0500, George <(E-Mail Removed)>
>> wrote:
>>
>>> 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.
>>
>> 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?
>>
>>> I am troubleshooting a general speed issue and isolated it to the wired
>>> LAN speed from the server which is highly asymmetrical.
>>
>> 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.
>>
> just vanilla TCP using iperf -c <server IP>
>>> 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.
>>
>> 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.
>
> 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.
>
>
>>
>>> Updating NIC drivers and turning off scalable networking brought the low
>>> speed up to 5 Mbit which is still lame.
>>
>> 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.
>>> The server has a GigE card
>>
>> Any particular model number GigE card?
>
> 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.
>
>>
>>> and there is a 100Mbit unmanaged switch.
>>
>> 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.
>>
>
> It is a D-link something (can't read my notes)
>
>>> Forcing link speed on the server to various auto/full/half didn't make
>>> much difference.
>>
>> Forcing it where? At the server? At the laptop? With a mechanical
>> switch on your unspecified unmanaged switch?
>
> At the server.
>
>>
>>> I suggested they replace the switch with a GigE switch which makes sense
>>> because there are two servers with GigE capability.
>>
>> Yeah, that makes sense if the intermediate wiring is 1000baseT
>> qualified? What manner of cable and how long?
>
> The switch is right above the servers so only short patch cables are
> needed.
>
>>
>>> I think the server NIC just doesn't like talking to the switch.
>>
>> I also don't like talking to people and devices that I know nothing
>> about.
>>
>>> 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.
>>
>> Try a 2nd laptop in place of the server. See if the unspecified model
>> GigE switch is the problem.
>>> I have tried switches like -d but it simply gives both results leaving
>>> you to wonder which is what.
>>
>> 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.
>>
>>
> 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.

On 30 Jan, 00:05, Jeff Liebermann <je...@cruzio.com> wrote:
> On Thu, 29 Jan 2009 11:38:41 -0500, George <geo...@nospam.invalid>
> wrote:
>
> >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

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.