[mythtv-users] IOBOUND errors over NFS - fixed

[Tim Tait]

Rudy Zijlstra wrote:

>Asher wrote:
>
>  
>
>>On 2/23/06, Kevin Kuphal <kuphal at dls.net> wrote:
>> 
>>
>>    
>>
>>>It's a wiki.  Fix it yourself or provide the detailed explanation.
>>>There is certainly nothing about this that requires both sides to be
>>>fixed at full duplex.  Networking isn't a one to one arrangement.  I too
>>>work in IT for a living and I can fix my servers at full duplex gigabit
>>>without fixing my multitude of clients at full duplex as well.
>>>
>>>Kevin
>>>   
>>>
>>>      
>>>
>>Right, because your switch supports 1000FD, and is able to handle you
>>forcing your connection.  I don't think Rudy was saying all the
>>clients have to support FD, but the switch needs to support it.
>>
>>
>>I turn autoneg off on all my devices just as force of habit, Cisco
>>used to tell people not to use auto on their switches cause it often
>>failed, and I've stuck with that ever since, but you have to know that
>>both sides (computer and switch) are set to the same speed and duplex.
>> 
>>
>>    
>>
>Which was because Cisco initially had a rather bad implementation of 
>auto-nego. That problem has been long solved though.
>When using recent equipment (<= 5 year old for Cisco) disabling 
>auto-nego will usually create more problems than solve them.
>Cisco is now adays advising to leave auto-nego on.
>
>I remain convinced that what the OP did was hiding his true problem. And 
>he will likely run into problem again.
>
>The reason forcing on Gig does not result in problems, can be found on 
>page 80, section 37.1.4.4 of IEEE 802.3: "Rather than disabling 
>Auto-Negotiation, the following behavior is suggested to improve 
>interoperability with other Auto-Negotiation devices. When a device is 
>configure for one specific mode of operation, it is recommended to 
>continue using Auto-Negotiation but only advertise the specifically 
>selected ability or abilities. " Such a recommendation in the standard 
>is usually followed.
>
>This in contrast with 100Mbit operation, where forcing the interface 
>will disable auto-negotiation.
>  
>
I would agree with that last statement. I work for an OEM networking 
company, and we have found that forcing settings on a NIC and disabling 
auto-neg can actually cause certain switches (mostly CISCO and mabye 
3COM too I forget, but these were not SOHO gear) to refuse to link at 
all. The IEEE spec indicates that if you do not Auto-neg, then you must 
be assumed to be so old as to predate the spec, and includes parallel 
detection of 10BASE-T, 100BASE-TX, or 100BASE-T4 signals. However, this 
does not detect FDX/HDX operation. And 1000Base-T is not supported w/o 
auto-neg.  Now most switches and PHYs support a non-IEEE feature called 
something like "Auto-neg bypass" where they usually take a stab at the 
settings, but in my experience end up going to HDX  incorrectly for 
speeds below 1000Mbps.  This may even be the cause of the original 
posters problem, indicating that the auto-neg on the switch port is not 
working, thus causing the NIC to guess erroneously. Interestingly, the 
auto-neg is carried out use 10Base-T link pulses, which uses differrent 
signalling levels than 100Base-T or 1000Base-T, thus could be caused by 
some selective hardware faults. A useful diagnostic might be to force 
10Base-T HDX operation, and see if it links and passes packets.

As stated, if you can force both ends of the link (NIC & switch, NOT 
Server NIC & Client NIC) you should be OK. Or if you allow autoneg but 
limit the advertised capabilities. The advantage to that is when you 
have redundant systems/link, if something is wrong, it will fail to 
link, thus causing a hard failure and trigger a fail over scenario 
rather than degraded operation.

The real evil is not auto-neg, but rather auto-neg bypass.

Tim