Ethernet (speed) auto-negotiation - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: September 17, 2019, 02:46:28 pm
content: so, I have a couple of days to play with our (my crew of crazy friends)Sonoko project, which has different boards running Linux, and the road-map is still ... sit, relax, and ... yes, it's all still a bloody messAnyway, one of the weird problems we have found is related to the Ethernet auto-negotiation, which is still a mystery.Each node does bootstrap from the network via tftp, so it's very important that each node uses the maximal speed possible because the kernel image is of 8Mbyte and the ramrootfs is of 64Mbyte.A lot of Mbyte to be uploadedEach graphic node has a PowerPC405GP embedded CPU with an MII channel to the Ethernet PHY, which should be responsible for both speed { 10Mbps, 100Mbps} and {half, full} duplex auto-negotiation, while the router-node has three fast-ethernet ports configured to autonegotiate the maximal speed possible, but ... when you look at the configuration reported by U-boot on each of the graphic nodes, it randomly looks like "a deranged dog on speed" ().Here it is an exampleCode:# tftpboot 800000 kernelENET Speed is 100 Mbps - FULL duplex connection (EMAC0)Using ppc_4xx_eth0 deviceu-boot says 100Mbps full duplex!Does it lie? Well, the Linux router says thisCode:# ethtool eth1Settings for eth1:Supported ports: [ TP MII ]Supported link modes: 10baseT/Half 10baseT/Full100baseT/Half 100baseT/FullSupports auto-negotiation: YesAdvertised link modes: 10baseT/Half 10baseT/Full100baseT/Half 100baseT/FullAdvertised auto-negotiation: YesSpeed: 10Mb/sDuplex: HalfPort: MIIPHYAD: 1Transceiver: internalAuto-negotiation: onSupports Wake-on: pumbgWake-on: dCurrent message level: 0x00000000 (0)Link detected: no10Mbps half duplex100Mbps full duplex != 10Mbps half duplex .... do have to trust the router because a second laptop has just confirmed that the graphic node is *somehow* failing the auto-negotiate, so it has forced the link to be 10Mbps half-duplex.In fact, the Ethernet PHY is aDP83843chip which exposes some pins for Auto-Negotiation and other pins are used to indicate Duplex, Link, Receive and Transmit, Link, Collision, and Speed status. By reading their logic status ... yet again confirmed what the router says: 10Mbps half-duplexSo u-boot does lie!One of the question is: why? why does it fail? It's not clear how and why the auto-negotiate protocol does work at this point.-Perhaps, I cannot even exclude a bug in u-boot, but in my mind, this is less convincing.-Anyway, I do not even know how to proceed, and where I have to investigate.

author: Daixiwen
author_rank: Frequent Contributor
timestamp: September 18, 2019, 06:35:09 am
content: It is possible that the link starts at 100 Mbits/s in full duplex but drops to 10 Mbits/s and half duplex because of a poor connection.If you use a computer instead, connected to the same router port with the same network cable, which speed do you get?It could also be a bad soldering problem on the network connector or the transformer on the board.

author: edpalmer42
author_rank: Super Contributor
timestamp: September 18, 2019, 07:41:33 am
content: Check your cables. Are they home made? Are they actual Cat5 or better or are they some unlabelled cable that happens to fit. I've seen people try to use 8-wire flat telephone cables. Not going to work!!One odd thing I saw was with old 3Com 10/100 cards plugged into a Netgear 5 port Gigabit switch. If you used 1 meter cables, auto-negotiate would fail. Use 10 meter cables and everything worked perfectly!By the way, if it's a private setup that's not going to change, you can always force the ports on one side and/or the other to 100 Mbps. I'm not sure if you have to do both sides or not.

author: legacy
author_rank: Super Contributor
timestamp: September 18, 2019, 08:16:41 am
content: Quote from: Daixiwen on September 18, 2019, 06:35:09 amCode:graphic node0 === link2 === router node0 === link1 === laptop0storage node1 === link3 === router node0my router sayslink1 is 100Mbpslink2 is 10Mbpslink3 is 100Mbpswithout changing the physical cables, let's replace the graphic node with a laptop2Code:laptop1 === link2 === router node0 === link1 === laptop0storage node1 === link3 === router node0my router sayslink1 is 100Mbpslink2 is 100Mbpslink3 is 100MbpsQuote from: Daixiwen on September 18, 2019, 06:35:09 amyup, it looks like the graphic node0 is triggering the ethernet phy to the lowest configuration possible due to a bad transform.I am going to replace it.

author: CaptCrash
author_rank: Regular Contributor
timestamp: September 18, 2019, 10:52:35 am
content: QuoteI have come across this quite a bit with IT equipment where people use short cables to attach devices to ethernet switches. My understanding is that for active ethernet devices a minimum cable distance of 1.5m is required (approx 4').I would expect that if you hard set the speeds of both ethernet ports and use a 1m cable it will probably work fine, otherwise use a longer cable and auto negotiate is likely to be ok.Either way you would be much better off setting the speeds/duplex so that you dont have items changing on you and negotiating at one end differently to the other.

author: Halcyon
author_rank: Unknown
timestamp: September 18, 2019, 11:24:14 am
content: Quote from: CaptCrash on September 18, 2019, 10:52:35 amThanks for sharing, very interesting. I can't say I've come across this myself but it's not often when I need to connect such devices so close to a switch. That being said, I also use enterprise switches (Cisco, HP etc...) and most of them auto-detect cable length and switch to a low-power mode on shorter runs.

author: NiHaoMike
author_rank: Super Contributor
timestamp: September 18, 2019, 01:09:51 pm
content: If the problem appears to be the signal being too strong, what about make an attenuator to reduce it?

author: ogden
author_rank: Super Contributor
timestamp: September 18, 2019, 01:40:07 pm
content: Quote from: CaptCrash on September 18, 2019, 10:52:35 amNot true. There is no minimum cable length mentioned in IEEE 802.3. 0.5m or even 0.25m patch cords are widely used in networking and they work. Also - most multi-port routers/switches have some kind of management CPU which is then connected to built-in switch ASIC. Both are active devices. Sometimes those are very close to each other on the PCB, few mm apart. Such kind of PHY connection usually is transformerless, just using AC coupling capacitors.Quote from: NiHaoMike on September 18, 2019, 01:09:51 pmNah. Just urban myth. Typical 100m cat5e attenuation at 100MHz (max specified freq) is 22dB (Belden). Accordingly attenuation of 1.5m is 0.33dB (1/1.08) which is so small that can be ignored.

author: magic
author_rank: Super Contributor
timestamp: September 18, 2019, 08:14:52 pm
content: Short cables are certainly not a guarantee of autonegotiation failure because I use some too and they work.But it wouldn't occur to me that they may cause a failure, so thanks for the warning I guess.

author: CaptCrash
author_rank: Regular Contributor
timestamp: October 02, 2019, 01:01:20 pm
content: Quote from: ogden on September 18, 2019, 01:40:07 pmIn regards to your point about "no minimum cable length mentioned in IEEE 802.3.", thats correct. But that also means that there is no standard for minimum. So its up to each chipset maker to handle it in their own manner. That is the key to the issue.I came back to this thread as today at a customers, we were having an issue between a Cisco managed switch (older unit 2960 i think, but I'm not 100%) and a HPE Procurve 3810M managed switch (new install). The customer had configured a 4 port LAG group between the switches and was getting unreliable traffic throughput, with ports in the LAG being unreliable (link loss and packet corruptions).In testing I cable tested each of the cables, connected with my laptop to each switch with each cable. These tests all worked fine with a laptop to switch but not switch to switch.In troubleshooting, I swapped from 50cm cables to 2m cables. Issues with the LAG group stopped and traffic is now fine.Changing the cables between the two switches made a difference.

author: ogden
author_rank: Super Contributor
timestamp: October 02, 2019, 02:12:54 pm
content: Quote from: CaptCrash on October 02, 2019, 01:01:20 pmStill not buying it. Most likely it was timing/skew problem rather than signal strength. I bet single 50cm cable between switches would work w/o problems until end of the days (of any switch involved). Switch interoperability problems are results of bad karma. That's why you shall stick to one brand only and do not risk your network being cursed by salesman who lost his deal.

author: MrMobodies
author_rank: Super Contributor
timestamp: October 03, 2019, 10:28:35 pm
content: I had a similar issue a decade ago with a dual port gigabit Broadbcom 5703 controller that was onboard a Supermicro X5DL8 and I had two of those server boards where the link speed kept on changing randomly on those particular nics and it will do it with any cable but there were options to turn it off in the driver and I think was ethernet wirespeed. No problems after that I did my checks on throughput and no packet errors on the switch port statistics.