|
Posted by matt on November 27, 2006, 2:01 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Hello,
Allow me to get some information out of the way before my problem
description.
PC1 - Running Fedora Core 3, ethtool version 1.8 (reported from man
page), Intel 82540EM NIC.
PC2 - Windows XP acting as a server for file transfers
Switch - 4 port supporting auto-negotiation
During these tests I am download a 50MB file onto PC1 from PC2 and
changing the link speed of PC1 during the file transfer with ethtool.
My Problem:
I am using ethtool to change the linkrate of a NIC for a project at my
university. I have run into a problem though: when changing the the
link speed with ethtool the link goes down for approximately 4 seconds.
The commands I am using are:
First:
ethtool -s eth0 autoneg off duplex half speed 100
Later:
ethtool -s eth0 speed 10
ethtool -s eth0 speed 100
I am toggling between the two speeds throughout my test. Each time the
link goes down for approximately 4 seconds. I have done over 50
ethereal traces to verify this standard 4 second delay. I am not
speaking just of TCP, there are no packets on the link for 4 seconds.
However when I use the command:
time { ethtool -s eth0 speed 10; }
I get the real time around 0.100 seconds each time. To me this shows
that ethtool is returning from executing quickly and would not be the
cause of the link down time. To verify this I tried physically
unplugging the link for fixed period of time and then plugging it back
in. When doing this the link is always down for 3 seconds longer than
it is unplugged.
>From my research into this delay I have come across the Parallel
Detection portion of Auto-Negotation. I have been unable to find the
length of time Auto-Negotiation waits before deciding there are no FLPs
from the other link partner. I find it hard to believe that this is
the cause of the delay, but could it be?
Any suggestions or advice for helping me track down the cause of this
delay?
Thank you for your time,
-Matt
|