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