|
From: | Kaufman, Michael |
Subject: | Re: [lwip-users] Delayed ACKs |
Date: | Thu, 28 Jan 2016 16:14:30 +0000 |
Hi Darius, >>Maybe, your system “send” driver not testing “data sending” state. So, new data “overrun” old data.
I doubt that. As far as I understand the wireshark capture, the problem is on the lwIP side. Actually this is the benchmarking tool from FNET stack project and it performs well with device running FNET stack. From: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden
On Behalf Of Darius Babrauskas Hi, >>When I add delay of 1ms and more between sending 1272 from PC application the problem disappears.
Maybe, your system “send” driver not testing “data sending” state. So, new data “overrun” old data.
From:
Kaufman, Michael
Sent: Thursday, January 28, 2016 12:30
PM To:
address@hidden
Subject: [lwip-users] Delayed ACKs I am testing lwIP 1.4.1 on Freescale Kinetis K60 tower under CMX OS. The test sends data in quants of 1272 bytes from the target (lwIP) to PC host over TCP. Almost immediately a lot of duplicated ACKs and TCP retransmissions pop out and the speed drops drastically. The same test over UDP works fine, also there is no problem with TCP in other direction (lwIP sends data to PC).
I tried to open debug output for TCP and saw a bunch of “tcp_fasttmr: delayed ACK” messages. When I add delay of 1ms and more between sending 1272 from PC application the problem disappears.
I started with default lwIP TCP settings and then tried to increase TCP window and segment size, but it doesn’t seem to help.
The capture file attached was with the following configuration:
#define TCP_QUEUE_OOSEQ 1
#define TCP_MSS (1500 - 40)
#define TCP_WND (20*TCP_MSS)
In the attached capture file 10.65.13.12 is a PC host and 192.168.103.48 is a target running lwIP.
I have not much experience with TCP, so if someone can point me to right direction I will apreciate it.
--
Michael Kaufman _______________________________________________ |
[Prev in Thread] | Current Thread | [Next in Thread] |