Losses during two streams with SCTP setup
Hi! I use SСTP connection setup as follows:
Server side:
cannelloni -S s -I can0 -l 20000 -p
Client side:
cannelloni -S c -I can0 -R 192.168.0.3 -r 20000 -p
I have a case where two streams of CAN frames are generated from the client side using cangen utility. One is a load stream of CAN-FD frames (ID 100) with a sending frequency of 0.5 ms, the second is a slow stream with CAN-FD frames (ID 200) with a sending frequency of 1000ms.
Client side:
cangen can0 -I 100 -g 0.5 -L 8 -f -b
cangen can0 -I 200 -g 1000 -L 8 -f -b
On the server side, I use the candump utility to register incoming frames.
So, after a short time, I observe randomly losses on the server side in a slow stream (frames with CANID 200).
When I stop the load stream (ID 100), the losses in the slow stream (ID 200) disappear.
Does your SCTP implementation support multiple streams? What recommendations can be made to eliminate losses?
Thank you for your attention
Is your can0 on either side a physical CAN bus, if yes at which speed does it run?
I couldn't immediately reproduce it with vcan interfaces:
- Start cannelloni on both CAN interfaces
- start
candumpon the receiving side:candump vcan1 > vcan1.log - start sending with both cangen instances
- wait and after a while stop the instances of cangen
- stop the instances of cannelloni, check the transmission summaries:
INFO:sctpthread.cpp[237]:run:Shutting down. SCTP Transmission Summary: TX: 102 RX: 0
INFO:canthread.cpp[169]:run:Shutting down. CAN Transmission Summary: TX: 0 RX: 9404
INFO:sctpthread.cpp[237]:run:Shutting down. SCTP Transmission Summary: TX: 0 RX: 102
INFO:canthread.cpp[169]:run:Shutting down. CAN Transmission Summary: TX: 9404 RX: 0
- stop candump
- check the amount of CAN frames:
wc -l vcan1.log
9404 vcan1.log
How do you measure the losses?
Does your SCTP implementation support multiple streams? What recommendations can be made to eliminate losses?
Yes, this is all handled already by SocketCAN, cannelloni only sends full packets with multiple CAN frames.
Hi Maximilian!
I couldn't immediately reproduce it with vcan interfaces:
Have you raised virtual interfaces on the same host machine?
Little more about my stand.
Let's call server side is "Machine 1" and client side is "Machine 2". "Machine 1" and "Machine 2" are different physicaly host systems.
On "Machine 1": connected physical CAN with follow details:
can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10000
link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0
can <FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000
bitrate 500000 sample-point 0.875
tq 25 prop-seg 34 phase-seg1 35 phase-seg2 10 sjw 1 brp 1
mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
dbitrate 2000000 dsample-point 0.750
dtq 25 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 1 dbrp 1
mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
clock 40000000
On "Machine 2": setup virtual CAN "vcan0"
What I'm doing step by step:
On "Machine 1":
- start Cannelloni:
cannelloni -S s -I can0 -l 20000 -p - start candump with filter frames and with "-td" option to see the frequency of incoming frames. Expected 1 sec:
candump -td can1,200:FFFFFFFF
On "Machine 2":
- start Cannelloni: cannelloni -S c -I vcan0 -R 192.168.0.3 -r 20000 -p
- start CAN generation by:
cangen vcan0 -I 100 -g 0.5 -L 8 -f -bcangen vcan0 -I 200 -g 1000 -L 8 -f -b -vv
That next:
On "Machine 1" I observe that the difference between incoming frames exceeds 1 second. I am comparing the payload of the sent ID frames from "Machine 2" and I do not see them on "Machine 1". They get lost.
I stop cangen vcan0 -I 100 -g 0.5 -L 8 -f -b on "Machine 2" and on "Machine 1" getting OK.
I start cangen vcan0 -I 100 -g 0.5 -L 8 -f -b on "Machine 2" again and on "Machine 1" losses again.
I think about rate limit how you explain in README. But could the physical interface theoretically be the reason in this case? Then "Machine 2" take packet is pass by way: ---->Ethernet--->Cannelloni--->SocketCan--->candump reading. So physical CAN doesn't participate in this process. Maybe I'm wrong?
Okay, I tried to check that too. I apply: sudo tc qdisc add dev vcan0 root tbf rate 2000000kbit latency 100ms burst 1000 But the result and behavior is same.
Is there anything else?
What happens in you start cangen on Machine 1 like this:
cangen can0 -I 100 -g 0.5 -L 8 -f -b
cangen can0 -I 200 -g 1000 -L 8 -f -b -vv
Do you mean in parallel with the scenario described above? Or stop all cangen from "Machine 2" and start the same from "Machine 1"?
Stop cangen from Machine 2 and even stop cannelloni.
Did you make any progress @TimurSuvorov?