lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #60402] Transmitting TCP packets stops after TCP windo


From: Peter Begella
Subject: [lwip-devel] [bug #60402] Transmitting TCP packets stops after TCP window update is received
Date: Fri, 16 Apr 2021 05:39:28 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36

URL:
  <https://savannah.nongnu.org/bugs/?60402>

                 Summary: Transmitting TCP packets stops after TCP window
update is received
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: begi
            Submitted on: Fri 16 Apr 2021 09:39:26 AM UTC
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 2.1.1

    _______________________________________________________

Details:

Hi lwIP developers,

First of all let me thank you your work.

Unfortunately I ran into an issue on Xilinx Zynq7000 system where we use
lwip211_v1_1 for transmitting large amount of data over TCP with at least
550Mbit/s throughput. 
This is easily achievable (max. is 930Mbit/s) however sometimes there is a
glitch somewhere which results in a 1s stop in the transmission. This happens
randomly and always comes after a received a TCP Window Update packet.
The only thing I was able to figure out that there are two type of issues
which might be caused by the same error.
1. In case TCP_WRITE_FLAG_MORE is not always passed to tcp_write() (for the
last portion of the buffer that is transmitted is not set) then the issue
comes with a TCP Spurious Retransmission beside the 1s glitch.
2. In case the TCP_WRITE_FLAG_MORE is always passed to tcp_write() then the
only symptom is the 1s stop.

Our TCP code is simple.
1. When data is available then send as many data as possible
using tcp_sendbuf() to learn the count then tcp_write() and then
tcp_output().
2. From the TCP send callback do the same until all data is acked.
3. Send next buffer if data is available

I have attached two small pcap logs where the issue can be seen.

Can you please suggest a way how to track the issue?

Thank you in advance!



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri 16 Apr 2021 09:39:26 AM UTC  Name:
tcp_1s_stop_and_retransmission_after_window_update.pcapng  Size: 58KiB   By:
begi

<http://savannah.nongnu.org/bugs/download.php?file_id=51276>
-------------------------------------------------------
Date: Fri 16 Apr 2021 09:39:26 AM UTC  Name:
tcp_1s_stop_after_window_update.pcapng  Size: 29KiB   By: begi

<http://savannah.nongnu.org/bugs/download.php?file_id=51277>

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?60402>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]