0
\$\begingroup\$

I would like to ask if packet loss in p2p LAN is a normal behavior in LAN.

And now in more details:

I am connecting PC to target board with TI's chip and LAN9221 controller. I am doing a ping-pong test, with udp protocol:

  1. PC is sending the first packet.

  2. target wait for packet, and on receive, it send the same packet back to PC.

  3. PC wait, and on receiving send a new packet (increment data in the UDP packet), and so on....

Running the ping-pong test, I see that once in a while the target did not receive the packet correctly. It is easy to notice the failure because the ping-pong test stops whenever one of the side did not receive a packet. When the failure happens, I see that the first bytes the target detected is actually the the 5th byte that the PC send (I see in WIRESHARK).

I also observed that these failures always happens when a another packet is sent about the same time from PC as the packet from the test , as if a collision happened.

If I add firewall rules, which take care that only the ping-pong packets shall be delivered in the LAN, then there is no failure at all.

So, the question is if the collision failures is a normal behavior in LAN ?

EDIT: seems the problem was related to (sw) driver error, not to collision, thank you for the solutions, which emphasized that in p2p there are no collisions.

Thank you!

\$\endgroup\$
1
\$\begingroup\$

No. There is no collision or packet loss in p2p Ethernet network. We have not had collisions/packet loss since the introduction of Ethernet switches. If you are connected point to point Tx/RX with no switch in-between ...there simply cannot be packet loss on the wire (it's typically a software problem).

If you are connected through a switch, then you have a store and forward system, again with no potential for collisions or packet loss. If the store RAM gets close to filling then the switch sends a signal to the sender to stop sending.

If you are connected to a larger network there can be packet loss, but this is a decision making process in the network routers to drop packets (typically due to route congestion). Your software needs to react appropriately to this and handle it (usually with timeouts).

If you are dealing with partial packets (runts), this is typically a software problem in your stack. If you are doing ping-pong, then you should simply never see an Rx failure. You may have a poor hardware implementation (perhaps unmatched magnetics or noise).

\$\endgroup\$
  • \$\begingroup\$ Can it be related to HW rules of connecting the LAN to magnetic, etc, which can results in such behavior ? The software does not do anything except reading from registers. And the first read from the register gives a wrong byte (the 5th byte from the packet which was sent) whenever the "collision" happens. \$\endgroup\$ – ransh Nov 21 '17 at 17:22
  • \$\begingroup\$ Yes it can be unmatched magnetics. You may cure the problem by putting a switch in place between the peer members. Switches are usually extremely well designed and have greater signal level and noise tolerance than direct p2p connections. \$\endgroup\$ – Jack Creasey Nov 21 '17 at 17:25
  • \$\begingroup\$ Right, the problem was not related to collisions, but to bug in driver. I've edit the question. \$\endgroup\$ – ransh Nov 22 '17 at 13:07
1
\$\begingroup\$

Collision failures yes, but you haven't any of those in a p2p or switched setup.

I test with flood pings usually and any connection with a single dropped ping within a minute or so at least isn't good. It would work, though, as dropped packets should be resent by upper layers.

\$\endgroup\$
  • \$\begingroup\$ Do you say that in p2p it should never happen ? But the PC sends 2 packets about the same time, so maybe the other controller can't handle 2 packets which are about at the same time ? \$\endgroup\$ – ransh Nov 21 '17 at 17:11
  • \$\begingroup\$ How can you send 2 packets at the same time from the same source over the same interface? That's simply not possible. \$\endgroup\$ – Janka Nov 21 '17 at 17:16
  • \$\begingroup\$ Right, they are not at the same time, but maybe the other controller sense them about the same time, and a collision happens ? \$\endgroup\$ – ransh Nov 21 '17 at 17:17
  • \$\begingroup\$ You simply cannot have two packets on the wire at the same time. You either are not properly handling the output FIFO buffer for the controller or are somehow corrupting the DMA state machine in the controller. \$\endgroup\$ – Jack Creasey Nov 21 '17 at 17:29
  • \$\begingroup\$ @ransh: You have a misconception of current Ethernet, it seems. It has either separate RX and TX pairs (10BaseT,100BaseT) or echo compensation (1000Base). So there can't be collisions. \$\endgroup\$ – Janka Nov 21 '17 at 17:32
0
\$\begingroup\$

It is normal behavior. In fact any LAN technology which doesn't account for lost or dropped packets is basically useless. Consider sending duplicates after a certain time period with no reply, or use a transport protocol like TCP which establishes connections via acknowledgement packets.

\$\endgroup\$
  • \$\begingroup\$ NO. packet loss is not normal on a small network or single switch environment. Packet loss on the Internet (large network) does happen, but not the Op's question \$\endgroup\$ – Jack Creasey Nov 21 '17 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.