Hi Colin, I did now. Zero errors in TCP. One dropped IP frame on more than 2000 received. This only reinforces the argument that the problem is on the driver level.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Colin Telfer Sent: Monday, February 01, 2016 4:17 PM To: 'Mailing list for lwIP users' Subject: Re: [lwip-users] Delayed ACKs Have you looked at the TCP statistics after delayed ACKs? You can see these in lwip by calling TCP_STATS_DISPLAY(). If the target cannot keep up with the incoming data, frames will be dropped, and you should TCP error counts incrementing. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kaufman, Michael Sent: February-01-16 8:05 AM To: Mailing list for lwIP users Subject: Re: [lwip-users] Delayed ACKs Sergio, Thanks a lot! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sergio R. Caprile Sent: Monday, February 01, 2016 2:58 PM To: [email protected] Subject: Re: [lwip-users] Delayed ACKs > There are restrictions on threading, and that depends on the API you > use, and if you use NO_SYS=0 or =1. lwIP is single-threaded, you can't call the RAW API functions from the main loop and an interrupt handler. Some functions are safe, but the general rule is to avoid the easy shortcut of pushing incoming frames from the Eth chip handler. The socket API and the netconn API do not present this restriction (and that is all I know about them). Since you have NO_SYS=0 and an OS, you should check how your OS amd your port handle the polling and frame extraction from the Eth chip. I didn't really dig into your problem but since you report problems at low delay multiframe input, that looks consistent with the typical problem: a frame arrives the chip signals a frame has arrived the OS fires a task to poll the chip the task extracts the frame out however, if another frame comes in before the first one is extracted, the chip might not signal for a new frame arrival, since it already has one. The driver must extract all frames inside the chip, and many driver writers do not do this. a frame arrives the chip signals a frame has arrived the OS fires a task to poll the chip another frame arrives the task extracts the first frame out the second frame stays there until a third frame arrives, one of the frames can be lost or overwritten. Search the list on this subject, there are some examples on this bug. It may or not apply to your problem, but my best guess is to start digging there. -- Sergio R. Caprile, Human Being, Bs.As., Argentina http://www.scaprile.ldir.com.ar/ _______________________________________________ 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 _______________________________________________ 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
