lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Delayed ACKs


From: Colin Telfer
Subject: Re: [lwip-users] Delayed ACKs
Date: Mon, 1 Feb 2016 09:17:18 -0500

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: address@hidden
[mailto:address@hidden 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: address@hidden
[mailto:address@hidden On Behalf
Of Sergio R. Caprile
Sent: Monday, February 01, 2016 2:58 PM
To: address@hidden
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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]