3

I have a quite newbie question : assume that I have two devices communication via Ethernet (TCP/IP) at 100Mbps. In one side, I will be feeding the device with data to transmit. At the other side, I will be consuming the received data. I have the ability to choose the adequate buffer size of both devices.

And now my question is : If data consumption rate from the second device, is slower than data feeding rate at the first one, what will happen then?

I found some, talking about overrun counter.

Is there anything in the ethernet communication indicating that a device is momently busy and can't receive new packets? so I can pause the transmission from the receiver device.

Can some one provide me with a document or documents that explain this issue in detail because I didn't find any.

Thank you by advance

geniant
  • 117
  • 2
  • 10
  • 1
    It´s TCP´s [flow control](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control) that will take care of that. The physical layer does not care, it will, at most, use a CRC to check for errors within a frame and other frame related checks, nothing related to rate of transmission. – C. Gonzalez Jan 17 '18 at 12:58
  • thanks for the helpful comment, also this link http://www.brianstorti.com/tcp-flow-control/ explains in details what I was looking for. The key work was TCP´s flow control – geniant Jan 17 '18 at 15:33
  • TCP/IP and ethernet are two different stacks, please find my answer below. – Milind Deore Jan 17 '18 at 16:29
  • You want to look up flow control there is in band and out of band in general depending on the interfaces, ideally you want have flow control tell the sender to stop sending you stuff temporarily as you are full. if you dont then depending on the design you will overflow in some form, ideally some buffer starts dropping packets. And sometimes you can set the high water mark in that buffer that determines at what level it starts to do that. – old_timer Jan 17 '18 at 20:03
  • THEN once packets go missing so long as you dont hang up the sender or receiver by filling up buffers and backpressuring, protocols like TCP/IP dont care that packets went missing they retry. There are protocols that do not retry... – old_timer Jan 17 '18 at 20:04

1 Answers1

3

Ethernet protocol runs on MAC controller chip. MAC has two separate RX-ring (for ingress packets) and TX-ring(for egress packets), this means its a full-duplex in nature. RX/TX-rings also have on-chip FIFO but the rings hold PDUs in host memory buffers. I have covered little bit of functionality in one of the related post

Now, congestion can happen but again RX and TX are two different paths and will be due to following conditions

  1. Queue/de-queue of rx-buffers/tx-buffers is NOT fast compared to line rate. This happens when CPU is busy and not honer the interrupts fast enough.
  2. Host memory is slower (ex: DRAM and not SRAM), or not enough memory(due to memory leak)
  3. Intermediate processing of the buffers taking too long.

Now, about the peer device: Back-pressure can be taken care in the a standalone system and when that happens, we usually tail drop the packets. This is agnostics to the peer device, if peer device is slow its that device's problem.

Definition of overrun is: Number of times the receiver hardware was unable to handle received data to a hardware buffer because the input rate exceeded the receiver’s ability to handle the data.

I recommend pick any MAC controller's data-sheet (ex: Intel's ethernet Controller) and you will get all your questions covered. Or if you get to see device-driver for any MAC controller.

TCP/IP is upper layer stack sits inside kernel(this can be in user plane as well), whereas ARPA protocol (ethernet) is inside MAC controller hardware. If you understand this you will understand the difference between router and switches (where there is no TCP/IP stack).

Milind Deore
  • 2,887
  • 5
  • 25
  • 40