Ethernet Collisions Not handled

[mlu]

I have been testing i.MX6Q Ethernet functionality on a Nitrogen6x board and am seeing a problem at 10 Mbps half duplex running Linux release L3.0.35_4.0.0 (also tested with L3.0.35_12.09.01_GA).  I'm seeing occasional collisions when using a 10Mbps half duplex hub between a Linux-PC and the Nitrogen6x board, which is expected, however the Nitrogen6x board seems to lose the ping every time the hub's collision light blinks.  It should be automatically resending the packet after the collision, but the retransmission does not seem to be happening.  I've tried the same test between the Linux-PC and a Windows-PC and am seeing the same occasional collisions however there is no packet loss.  I can cause 100% packet loss by doing a simultaneous tftp transfer of a large file across the same hub, which greatly increases the likelihood of collisions.  Other devices tested are not affected by collisions generated by the tftp transfer.

To increase the likelihood of generating a collision I'm sending 100 large (30k) packets using the command:

ping -c 100 -s 30000 192.168.1.10

The result after 100 pings is:

--- 192.168.1.10 ping statistics ---

100 packets transmitted, 96 packets received, 4% packet loss

round-trip min/avg/max = 50.463/75.662/1118.729 ms

I'm not sure if this is a hardware of software issue.  The Ethernet on this board is the i.MX6Q ENET (FEC) and a Micrel ksz9021rn PHY.

Has anyone else tested Ethernet on an i.MX6Q (Sabre Lite, Nitrogen6x, or similar) at 10 Mbps half duplex?    Any ideas where to look for the cause?

[YixingKong]

Mike, if your questions had been answered by Jozef, please click Correct Answer/Helpful Answer. We woudl like to close the DI in 3 days if no activity happens.

Thanks,

Yixing

[cyborgnegotiato]

This situation might be an often event when we use a hub with 10Mbit half-fuplex mode with high load. MAC will wait backoff time when a collision occurs and then try to retransmit the frame. If the collision occurs after 16 consequent retransmission, the MAC reports an excessive collision condition and discards the frame (IEEE 802.3 standard). In this situation you can lost packets (layer 3) - it depends on protocol/retransmission on OSI level 4 behaviour and it's (ICMP will be lost, TCP will by retransmitted due to behaviour of stack).

I made a short test for comparison my IMX6Q-SDB with another Linux box and results was almost the same (similar amount of lost packets).

[mlu]

I have done much testing on this problem and believe KSZ9021RN and KSZ9031RNX PHYs do not signal packet collisions to the Ethernet controller at 10Mbps half-duplex and therefore no retransmissions occur.  Packets are lost on collisions at very light bandwidth utilization where layer-3 retransmissions should correct the issue. I have tested an IMX6Q-SDB board which has an Atheros AR8031 PHY and find that it handles collisions and layer-3 retransmissions occur.

This problem is masked somewhat as many protocols, such as TCP, will retry at higher OSI layers, as you point out, but with very poor performance due to the significantly longer retry period of these higher layers.  I test with ICMP ping specifically because it does not have a higher-layer retry mechanism.