Your packet are duplicated very fast – my opinion, that this occurs in driver
level.
Try find other send driver code, which using TxBD buffer descriptor. Maybe,
code must have parts which waiting for transmit is completed.
//Your chip errata
Errata type:
Errata
Description:
If the ready bit in the transmit buffer descriptor (TxBD[R]) is previously
detected as not set
during a prior frame transmission, then the ENET_TDAR[TDAR] bit is cleared at a
later time,
even if additional TxBDs were added to the ring and the ENET_TDAR[TDAR] bit is
set. This
results in frames not being transmitted until there is a 0-to-1 transition on
ENET_TDAR[TDAR].
Workaround:
Code can use the transmit frame interrupt flag (ENET_EIR[TXF]) as a method to
detect
whether the ENET has completed transmission and the ENET_TDAR[TDAR] has been
cleared. If ENET_TDAR[TDAR] is detected as cleared when packets are queued and
waiting
for transmit, then a write to the TDAR bit will restart TxBD processing.
>>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.
//////////////////////////////////////////////////////////////
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: [email protected]
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
--------------------------------------------------------------------------------
_______________________________________________
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
