Re: [lwip-users] Delayed HTTP POST TCP ACK

[Element Green]

Thank you for your input on this issue.  After a lot of debugging, I finally discovered that it was the HTTP POST operation itself that was taking a long time, since it had to do with some FLASH operations.  It didn't occur to me that the ACK would be held up by this, but it makes sense now and I went ahead and implemented manual window size updates, to help throttle the incoming data.  There was an issue when the window size was larger than the Ethernet receive FIFO size (2K), where packets were being dropped, but this was "fixed" when I made the window size smaller than 2K.  I'm not sure why packets were being dropped though, since it seemed like the data was being read very soon after the Interrupt occurred.  The Ethernet loop consumes any and all packets that are available in the Ethernet MAC and then re-enables the TX/RX interrupts, so I don't think it was a case of only reading one packet, when multiple ones are available.  The Ethernet driver isn't using DMA though from what I can tell, so that may very well be the issue.

Thanks again for the help.

Element Green

On Thu, Jan 9, 2014 at 9:04 AM, Zach Smith <address@hidden> wrote:

It is possible you are experiencing the typical problem of multiple Ethernet packets coming in but only getting one Ethernet interrupt.  Each time you get an Ethernet interrupt you want to make sure your RTOS task completely clears out all packets. If all packets aren’t cleared out they may sit in there until you receive the next interrupt which would explain the long delays.

 

From: lwip-users-bounces+zsmith=address@hidden [mailto:lwip-users-bounces+zsmith=address@hidden] On Behalf Of Element Green
Sent: Wednesday, January 08, 2014 9:45 PM
To: lwip-users
Subject: Re: [lwip-users] Delayed HTTP POST TCP ACK

 

I wanted to add an update to this issue.  By checking the interrupt status in the Ethernet interrupt I confirmed that an RX FIFO overrun error was indeed occurring with the HTTP POST request.  It seems the LM3S6965 receive FIFO is 2K.  I think something else is going on though, because even after adjusting the TCP_MSS to 960 and TCP_WND to 1920, there are still very long delays (about 1.2 seconds) between the received packets and the ACKs sent by the device running lwip.  At least there aren't any dropped packets or duplicate ACKs though.  I've attached a new packet capture.

 

This processor is running at 50MHz.  One noteworthy thing is how the lwip port related code is handling the Ethernet interrupt.  It uses a Queue to signal a FreeRTOS task when data is available from the Ethernet interface.  This task does the actual handling of the data received from the Ethernet MAC.  I scheduled this task as the highest priority one in the system, but it doesn't seem to make a difference.  The system is idle most the time, so I can't see how task priority would account for 1.2 seconds of ACK delay.

 

I turned off the naggle algorithm with the HTTP listen port, not sure if this also needs to be done with the accepted connections though.

 

Best regards,

 

Element Green

 

On Wed, Jan 8, 2014 at 5:12 PM, Element Green <address@hidden> wrote:

I'm developing an application on the Stellaris LM3S6965 platform with lwip 1.4.1, FreeRTOS 7.5.2 and Stellarisware 10636.

With a host Linux PC I'm sending a HTTP POST request (3011 byte payload) using wget connected to the target platform with a crossover cable.

 

I've attached a wireshark capture of the strange behavior.  It appears that 3 packets are sent from the HTTP post request without an ACK being sent by the lwip system, then several seconds later the host PC resends the first packet, some duplicate ACKs occur, etc.

 

I wrote a more concise analysis of this before, but Nabble ate my message after I uploaded the capture file..  First and last time I'm using that.

 

I did some debugging in the Ethernet interface driver receive function and it appears that not all of the packets are arriving.  Anyone have any ideas where to go from here?  I'm not very familiar with Ethernet hardware drivers, so I don't know how they buffer data and what would cause them to lose a packet.  Could I decrease my WND size to try and fix this?

 

Here are some of the TCP settings I have in my lwipopts.h file:

//#define LWIP_TCP                        1

//#define TCP_TTL                         (IP_DEFAULT_TTL)

#define TCP_WND                           4096    // default is 2048

//#define TCP_MAXRTX                      12

//#define TCP_SYNMAXRTX                   6

#define TCP_QUEUE_OOSEQ                   1

#define TCP_MSS                           1460     // default is 128

//#define TCP_CALCULATE_EFF_SEND_MSS      1

#define TCP_SND_BUF                       (2 * TCP_MSS)

//#define TCP_SND_QUEUELEN                (4 * (TCP_SND_BUF/TCP_MSS))

//#define TCP_SNDLOWAT                    (TCP_SND_BUF/2)

//#define TCP_LISTEN_BACKLOG              0

//#define TCP_DEFAULT_LISTEN_BACKLOG      0xff

 

Thanks in advance for any assistance.

 

Element Green

 

 

---

This email may contain information that is confidential and/or legally privileged in nature. The message is intended for the use of the individual(s) or entity listed above. If you are not the intended recipient, please do not read, copy, publish or distribute the communication; and notify the sender by replying to this message and deleting this copy and any copies that may be in your electronic system. Thank you for your compliance.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users