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

[Alain Mouette]

Are you aware that there are no more Luminary chips???

Luminary was bought by Texas Instruments, which with caracteristic customer care simply stopped producing it.
I am moving a product in production (gladly only one) to ST...

I intend to use the external PHY from Microchip ENC424J600, but I asked for help to find an LWIP driver but got no answer :(

Alain

Em 09-01-2014 02:45, Element Green escreveu:

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

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