iperf question

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.

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.

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

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

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

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.

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....

....

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...

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'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.

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.

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.

Any particular model number GigE card?

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.

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

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

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

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

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.

Unfortunately it is a unmanaged 10/100 switch. We have a "web managed" GigE switch coming which might cure the problem.

just vanilla TCP using iperf -c

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.

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.

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

At the server.

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

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.

I posted gigabit test results and procedures in the distant past. See:

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.

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.

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.

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

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.

Duh, yes.... that makes sense.

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.

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.

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.