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 <[email protected]>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 [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
