Ethernet TCP, delay on send()

[arnogir]

Hello

I'm working on the tower K60n512 with MQX4.1.1.

I init the RTCS like following:

RTCS_Create();
ENET_initialize(..)
RTCS_if_add(..)
RTCS_if_bind(..)
socket(PF_INET, SOCK_STREAM, 0)
bind(..)
listen(..)
accept(..)
setsockopt(.. SOL_TCP, OPT_SEND_NOWAIT, true..) 
setsockopt(.. SOL_TCP, OPT_SEND_TIMEOUT, 10..)

Then in cyclic task (5s) I call
:

send(.., buffer, 5) with buffer is a counter incremented on each send call.

I make toggle a pin just before call send(). After check with oscilloscope, the call to "send()" is really done every exactly each 5s.

I link Ethernet to my laptop with wireshark.

The received frame is not cyclic of 5s. Sometime a delay of 2s can occurs!

32 14:48:58.708895000       192.168.1.125 192.168.1.122       TCP 60 502?60226 [PSH, ACK] Seq=61 Ack=1 Win=4380 Len=5
33 14:48:58.926112000       192.168.1.122 192.168.1.125       TCP 54 60226?502 [ACK] Seq=1 Ack=66 Win=16428800 Len=0


34 14:49:03.571633000       192.168.1.125 192.168.1.122       TCP 60 502?60226 [PSH, ACK] Seq=66 Ack=1 Win=4380 Len=5
35 14:49:03.574697000 Dell_02:63:cd IcannIan_a8:01:7d ARP 42 Who has 192.168.1.125? Tell 192.168.1.122
36 14:49:03.777609000       192.168.1.122 192.168.1.125       TCP 54 60226?502 [ACK] Seq=1 Ack=71 Win=16427520 Len=0

37 14:49:04.573087000 Dell_02:63:cd IcannIan_a8:01:7d ARP 42 Who has 192.168.1.125? Tell 192.168.1.122
38 14:49:04.573365000 IcannIan_a8:01:7 d Dell_02:63:cd ARP 60 192.168.1.125 is at 00:00:5e:a8:01:7d


39 14:49:10.081473000       192.168.1.125 192.168.1.122       TCP 60 502?60226 [PSH, ACK] Seq=71 Ack=1 Win=4380 Len=5
40 14:49:10.298146000       192.168.1.122 192.168.1.125       TCP 54 60226?502 [ACK] Seq=1 Ack=76 Win=16426240 Len=0
41 14:49:12.086411000       192.168.1.125 192.168.1.122       TCP 60 [TCP Retransmission] 502?60226 [PSH, ACK] Seq=71 Ack=1 Win=4380 Len=5
42 14:49:12.086479000       192.168.1.122 192.168.1.125       TCP 54 [TCP Dup ACK 40#1] 60226?502 [ACK] Seq=1 Ack=76 Win=16426240 Len=0

43 14:49:13.571434000       192.168.1.125 192.168.1.122       TCP 60 502?60226 [PSH, ACK] Seq=76 Ack=1 Win=4380 Len=5
44 14:49:13.777004000       192.168.1.122 192.168.1.125       TCP 54 60226?502 [ACK] Seq=1 Ack=81 Win=16424960 Len=0

Twrk60 has ip = 192.168.1.125

Laptop has ip = 192.168.1.122

I see a good frame #32 and #33 (Request from tower/ Ack from laptop)

Same for #34 and 36

But the #39 should arrive at time 14:49:08.xxxx ut arrive at 14:49:10.xxxx so there are in late! (very late! 1s...)

#43/#44 has the good time.

I don't understand why this frame is send with this late,  why Retransmission is done 2s later? (#41)

For my application, I would have to send frame with a very speed (every 10 or 100ms...) but with simple test (one frame every 5s) sometime some frame are very delayed!.

Have you an idea why?

Note: nothing else is done on K60. Only Ethernet load the µC..:smileyplain:

[RadekS]

It is hard to say what could be reason for this behavior.

From your description it seems that packet was dropped at some lower layer of RTCS stack and after that it tries sending it again.

Unfortunately TCP doesn’t have specified any delivery time. It is save protocol, but without any time guarantee.

Did you set OPT_SEND_TIMEOUT to 10ms? Or there missing some zeros?

Could you please place here full wireshark log and describe your network (it is just board-PC connection, or connected to some bigger LAN)?

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[arnogir]

OPT_SEND_TIMEOUT was set with 10ms.

But problem occurs with or without this setting.

I need to do some test with my computer software (Docklight)

May be some time this soft put in buffer data to send and received to really sent its or display received...

But With wireshark, I see many time a realy response with very big latence time.

I need to reproduce exactly and with a sure maner the problem.

I will back to you

:smileywink:

[arnogir · Accepted solution]

Hello,

TO close this point, it was my PC tool which wait some data to send a bigger packet.

After test, the response time is ok!