phcc75
asked on
Hard time achieving Gig Network Speed on Windows Machines
I have a Cisco gig switch and I decided to test my network bandwidth on various machines by using the Iperf utility. I am confused by what I found.
When I run the iperf test on a linux box or mac to my 2003 server that is plugged into a gig port, Iperf reports speeds around 933 Mb/s... yea!
However, when I run the same test on all of my windows 7 machines Iperf only reports speeds around 450 Mb/s.
Does anyone if there is some setting in Windows 7 that would prevent me from getting true gig speeds. Auto negotiation is set on them.
Thanks
When I run the iperf test on a linux box or mac to my 2003 server that is plugged into a gig port, Iperf reports speeds around 933 Mb/s... yea!
However, when I run the same test on all of my windows 7 machines Iperf only reports speeds around 450 Mb/s.
Does anyone if there is some setting in Windows 7 that would prevent me from getting true gig speeds. Auto negotiation is set on them.
Thanks
marine7275
I don't know of any win7 settings other than autonegiate, but make sure the cable is gb capable
Your duplex settings will negotiate 10/100 or 1000, half duplex or full duplex. For cisco equipment, they have to match EXACTLY. You can not set a computer to 1000 full duplex, and the cisco switch to Auto negotiate....
Here's the stickler. Some NICS are not recognizing the Fast Link Pulse data as full duplex. So, the machines end up as trying to transfer data with HALF duplex. This is the data that is used in Auto negotiation of the duplex settings. Let me see if I can find the article on this>
This link explains the fast link pulse and what can potentially go wrong in the autonegotiations of the duplex settings:
http://www.dell.com/content/topics/global.aspx/power/en/ps1q01_hernan?c=us&l=en&cs=555
Now, the fast link pulse problems will NOT be OS specific. Instead it will be hardware and third-party driver specific. Also, if your duplex settings don't match, you will see symtpoms of intermittent communications and what appears to be a flooded nic for a couple minutes, OR you will probably not communicate at all because they are on different communications parameters.
------>>>So, I don't think that the duplex settings is your problem.
You can check them to make sure the switch matches the computer's duplex settings. Also make sure it matches the router's and firewall's duplex settings.
Here's the stickler. Some NICS are not recognizing the Fast Link Pulse data as full duplex. So, the machines end up as trying to transfer data with HALF duplex. This is the data that is used in Auto negotiation of the duplex settings. Let me see if I can find the article on this>
This link explains the fast link pulse and what can potentially go wrong in the autonegotiations of the duplex settings:
http://www.dell.com/content/topics/global.aspx/power/en/ps1q01_hernan?c=us&l=en&cs=555
Now, the fast link pulse problems will NOT be OS specific. Instead it will be hardware and third-party driver specific. Also, if your duplex settings don't match, you will see symtpoms of intermittent communications and what appears to be a flooded nic for a couple minutes, OR you will probably not communicate at all because they are on different communications parameters.
------>>>So, I don't think that the duplex settings is your problem.
You can check them to make sure the switch matches the computer's duplex settings. Also make sure it matches the router's and firewall's duplex settings.
What happens when you turn of your Win7 firewall. Probably the speed will increase quite a bit.
ASKER
It's already off
I think you have to decipher what the test is really running. A TCP connection with synchronizations and handshakes will always appear less of a payload than a UDP connectionless protocol.
While in class, (as an example) we performed a lab on different protocols and perceived bandwidth of them we tried different VoIP codecs, and also different encryption, and also different compression utilities. It was pretty shocking what we figured out on the LAB. The perceived bandwidth was not exactly what we thought it would be.
Sometimes running a test, and not really translating the test correctly can cause you problems as well.
While in class, (as an example) we performed a lab on different protocols and perceived bandwidth of them we tried different VoIP codecs, and also different encryption, and also different compression utilities. It was pretty shocking what we figured out on the LAB. The perceived bandwidth was not exactly what we thought it would be.
Sometimes running a test, and not really translating the test correctly can cause you problems as well.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The question is still unresolved.