PEAK-System Forum

Hello,

I'm using your PCAN-Wireless Gateway together with the Virtual PCAN-Gateway on a Windows laptop.

The network connection is a direct connection to the gateway (ad hoc mode).

When using TCP as protocol, there are some delays when receiving the messages via PCAN-View on the laptop.

Test procedure:
There are 7 messages sent on the CAN bus, then there is 1 sec. delay, then the same 7 messages are sent again and so on.

CAN trace on the CAN bus:

(1439969833.493952) can0 0FF#0101010101010101
(1439969833.496198) can0 0FF#0202020202020202
(1439969833.498758) can0 0FF#0303030303030303
(1439969833.501307) can0 0FF#0404040404040404
(1439969833.503848) can0 0FF#0505050505050505
(1439969833.506427) can0 0FF#0606060606060606
(1439969833.508981) can0 0FF#0707070707070707

The messages are sent within 15msec.

On the receiving side (PCAN-View), I get:


36 5504.662 DT 00FF Rx 8 01 01 01 01 01 01 01 01
37 5716.738 DT 00FF Rx 8 02 02 02 02 02 02 02 02
38 5716.739 DT 00FF Rx 8 03 03 03 03 03 03 03 03
39 5716.740 DT 00FF Rx 8 04 04 04 04 04 04 04 04
40 5716.740 DT 00FF Rx 8 05 05 05 05 05 05 05 05
41 5716.740 DT 00FF Rx 8 06 06 06 06 06 06 06 06
42 5716.741 DT 00FF Rx 8 07 07 07 07 07 07 07 07
43 6519.573 DT 00FF Rx 8 01 01 01 01 01 01 01 01
44 6721.838 DT 00FF Rx 8 02 02 02 02 02 02 02 02
45 6721.840 DT 00FF Rx 8 03 03 03 03 03 03 03 03
46 6721.840 DT 00FF Rx 8 04 04 04 04 04 04 04 04
47 6721.841 DT 00FF Rx 8 05 05 05 05 05 05 05 05
48 6721.841 DT 00FF Rx 8 06 06 06 06 06 06 06 06
49 6721.842 DT 00FF Rx 8 07 07 07 07 07 07 07 07

There is a delay of 200msec between 43 and 44.

Using UDP with 15 frames, there is no delay:

22 17657.740 DT 00FF Rx 8 01 01 01 01 01 01 01 01
23 17658.464 DT 00FF Rx 8 02 02 02 02 02 02 02 02
24 17660.328 DT 00FF Rx 8 03 03 03 03 03 03 03 03
25 17661.849 DT 00FF Rx 8 04 04 04 04 04 04 04 04
26 17663.597 DT 00FF Rx 8 05 05 05 05 05 05 05 05
27 17665.386 DT 00FF Rx 8 06 06 06 06 06 06 06 06
28 17667.124 DT 00FF Rx 8 07 07 07 07 07 07 07 07
29 18672.240 DT 00FF Rx 8 01 01 01 01 01 01 01 01
30 18673.555 DT 00FF Rx 8 02 02 02 02 02 02 02 02
31 18675.225 DT 00FF Rx 8 03 03 03 03 03 03 03 03
32 18677.128 DT 00FF Rx 8 04 04 04 04 04 04 04 04
33 18678.849 DT 00FF Rx 8 05 05 05 05 05 05 05 05
34 18680.604 DT 00FF Rx 8 06 06 06 06 06 06 06 06
35 18682.442 DT 00FF Rx 8 07 07 07 07 07 07 07 07


Do you have any idea, what could cause this delay when using TCP protocol?

Attached are the two trc files from PCAN-View.

Do you have also some infos about expected message loss, depending on CAN bus load and/or other environment parameters (especially when using UDP)?

Thanks and best regards!

Hello,

in principle delays could have different reasons when using TCP. At first the TCP stack usually caches some data and sends it with some delay in a single packet. You can disable that behavior if you set the “tcpdelay“ option of the according route in the configuration file to “0” manually. Note: this will increase the CPU load dramatically and thereby decrease the overall throughput of the gateway. Since the generated TCP packets need to be acknowledged this applies also a bit to the receiving part (Windows laptop in your case). The UDP doesn’t cache or acknowledge any data so this kind of delays will not appear in UDP case. TCP messages might also be delayed if one or more packets need to be retransmitted.

When TCP is used the loss of messages on Network layer should be avoided. In case of UDP the loss highly depends on the environmental conditions so there is no valid statement to make about this case. If there is nothing that disturbs the transmission you might be able to receive all packets there too.

Best Regards,
Stephan

Thanks for the quick answer.

I exported the device configuration from the gateway and changed the lines:

tcpdelay = TRUE

to

tcpdelay = FALSE

and remported the changed file.

Then I didn't observe any extra delay. But in high traffic situations, something still goes wrong when using TCP. I have to have a look what's happening.

Thanks and best regards!

Hello,

it seems that two messages are lost in this situation (high load message burst from the CAN bus to LAN)

trace from CAN bus:

1166978.177 18c72681 8 10 ff fc 7f e0 7f ff ff
1166978.196 1cc88126 8 15 10 b1 3f 00 00 e7 00
1166978.196 18c82681 8 16 10 b0 3f 00 00 e7 00
1166978.196 18c72681 8 01 f8 0f ff ff f8 07 ff
1166978.196 18c72681 8 02 fc 7f e0 7f ff ff f0
1166978.196 18c72681 8 03 17 ff ff fa 07 ff fc
1166978.196 18c72681 8 04 7f e0 7f ff ff fc 47
1166978.196 18c72681 8 05 ff ff f9 9f ff fc 7f
1166978.196 18c72681 8 06 e0 7f ff ff ff 47 ff
1166978.196 18c72681 8 07 ff f9 bf ff fc 7f e0
1166978.196 18c72681 8 08 7f ff ff fc 47 ff ff
1166978.196 18c72681 8 09 f9 1f ff fc 7f e0 7f
1166978.196 18c72681 8 0a ff ff fc 47 ff ff f9
1166978.196 18c72681 8 0b 9f ff fc 7f e0 7f ff
1166978.196 18c72681 8 0c ff fc 47 ff ff f9 1f
1166978.196 18c72681 8 0d ff fc 7f e0 7f ff ff
1166978.196 18c72681 8 0e fc 47 ff ff f9 1f ff
1166978.196 18c72681 8 0f fc 7f e0 7f ff ff fc
1166978.202 18c72681 8 10 47 ff ff f9 1f ff fc
1166978.222 1cc88126 8 ff ff ff ff ff 00 e7 00

trace from PCAN-View (virtual PCAN)

18431 41511.565 DT 18C72681 Rx 8 10 FF FC 7F E0 7F FF FF
18432 41519.637 DT 1CC88126 Rx 8 15 10 B1 3F 00 00 E7 00
18433 41526.231 DT 18C82681 Rx 8 16 10 B0 3F 00 00 E7 00
18434 41527.034 DT 18C72681 Rx 8 01 F8 0F FF FF F8 07 FF
18435 41527.996 DT 18C72681 Rx 8 02 FC 7F E0 7F FF FF F0
18436 41529.323 DT 18C72681 Rx 8 03 17 FF FF FA 07 FF FC
18437 41529.323 DT 18C72681 Rx 8 04 7F E0 7F FF FF FC 47
18438 41536.173 DT 18C72681 Rx 8 05 FF FF F9 9F FF FC 7F
18439 41537.367 DT 18C72681 Rx 8 06 E0 7F FF FF FF 47 FF
18440 41537.368 DT 18C72681 Rx 8 07 FF F9 BF FF FC 7F E0
18441 41537.368 DT 18C72681 Rx 8 08 7F FF FF FC 47 FF FF
18442 41537.368 DT 18C72681 Rx 8 09 F9 1F FF FC 7F E0 7F
18443 41537.368 DT 18C72681 Rx 8 0A FF FF FC 47 FF FF F9
18444 41537.369 DT 18C72681 Rx 8 0B 9F FF FC 7F E0 7F FF
18445 41537.369 DT 18C72681 Rx 8 0C FF FC 47 FF FF F9 1F
18446 41537.369 DT 18C72681 Rx 8 0F FC 7F E0 7F FF FF FC
18447 41537.369 DT 18C72681 Rx 8 10 47 FF FF F9 1F FF FC
18448 41545.665 DT 1CC88126 Rx 8 FF FF FF FF FF 00 E7 00


The messages with first byte 0x0D and 0xOE are lost.

You mentioned that setting tcpdelay to FALSE, will "increase the CPU load dramatically". I guess that the two messages were not lost during WLAN transmission (we use TCP), but there was sort of an "overrun" from the CAN bus side and the gateway didn't have enough resources to fetch them from the CAN bus and transmit them over the network.

So generally, using UDP might be better in my environment. Do you think so too?

Thanks and best regards!

Hello,

that depends on your use case. TCP in normal mode might be the best option in most cases. Usually the latency will decrease in case of steady CAN traffic. If you need a low latency and you're in an environment that allows you to use UDP that might be the better option.

BR,
Stephan