Ethernet frame length issue

[kqian]

Hi, I got a problem when I use the Ethernet TCP stack and hope someone can help me figure it out.

I am using tcpecho protocol to communicate between PC and the board. PC send the command and board response with the data. If I just send 64 bytes, as:

netconn_write(newconn, TCPResponse, 64, NETCONN_COPY);

Everything looks good, I can see the PC receives the response as :

but since my message is over the 64 bytes, I change it to 128 in the function as

netconn_write(newconn, TCPResponse, 128, NETCONN_COPY);

Then the response become much slower. It takes more than half second to received the response.

Looks like I got the "TCP out of order", Is there any way can allow 128 bytes message in the TCP stack?

Please help me out of it. Thanks for that

[kqian]

Cannot add the picture here, Please see the attached file for the message information. Thanks

[kqian]

Sorry, forget to mention the MCU is STM32F767

[TDK]

Why is your screenshot a DOCX file?

netconn_write should allow an argument of 128 bytes. The problem is likely elsewhere. The ST implementation of LwIP isn't great. Not sure what you're using.

[kqian]

TDK,

When I set the 128 bytes, it talks, but much slower for some reason. Do I need to change anything to make it faster? I found there was a bug for the H7 as https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet. not sure if F7 LWIP has the bug for 128 bytes argument.

Here is the Message got from sharkwire which shows the message timestamp.

64 bytes length

128 bytes

[alister]

>When I set the 128 bytes, it talks, but much slower for some reason <snip> there was a bug for the H7...

The question is speculating if a problem in the F7 driver could cause 128 byte packets to be transmitted much much slower than 64 byte packets.

It's very unlikely. But very easy to test. Forget TCP for a moment. The STMF7 won't care. Just use ICMP (ping). E.g. from Windows...

C:\Users\alister>ping 192.168.0.1
 
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
 
Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
C:\Users\alister>ping 192.168.0.1 -l 1000
 
Pinging 192.168.0.1 with 1000 bytes of data:
Reply from 192.168.0.1: bytes=1000 time<1ms TTL=64
Reply from 192.168.0.1: bytes=1000 time<1ms TTL=64
Reply from 192.168.0.1: bytes=1000 time=1ms TTL=64
Reply from 192.168.0.1: bytes=1000 time<1ms TTL=64
 
Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

Instrument your lwIp to determine where it's spending time. Then, when you find it, search the web for reasons for what you determined and its fixes.

Perhaps you can do nothing but search the web, and be lucky. E.g. a Google of "tcp transmit very slow lwip" (without the quotes) finds these and others...

http://lwip.100.n7.nabble.com/Slow-sending-speed-td7346.html

https://forums.xilinx.com/t5/Welcome-Join/zynq-lwip-transmitting-speed-issue/td-p/735522

https://lists.gnu.org/archive/html/lwip-users/2003-11/msg00009.html

But you'd still have to read the hits, and whenever you read a plausible cause, devise some experiments to confirm if that's your problem.

Also study TCP tuning for lwIP, e.g. https://lwip.fandom.com/wiki/Tuning_TCP.