Sending rate cannot be faster than 300us

Question

Sending rate cannot be faster than 300us

Closed this issue 2 years ago · 12 comments

Hi,

I try to send the consecutive frame as fast as possible. (stmin =0 in the receiver)
I am noticing when using this ISTOP stack the best rate I can get is : Sending a consecutive frame each 350us.
But I can get up about 15us when using another ISTOP stack (running on windows)
Wondering what could cause this delay?

System information :
kernel : 5.10.90
CPU usage < 15%
Tx buffer 4000
Bit Rate 500kBit/s

How to preproduce the issue :
Send more few conductive frames using isotpsend where set stmin to 0 in the receiver.

Answer 1 · 2023-01-24T07:30:53.000Z

The 15us on Windows are simply fake.

Try to calculate a 500 kBit/s frame with 8 Bytes here:
https://www.esacademy.com/en/library/calculators/can-best-and-worst-case-calculator.html

The transmission on the wire itself lasts at least ~250us in the worst case > 300us.
When you have a not so performant SPI-attached CAN controller like the MCP2515 on a RasPi the frame rate is reduced even more.

Answer 2 · 2023-01-24T16:08:04.000Z

Thanks Oliver for your feedback, that make totally sense.

=> I suppose the windows reading are fake cause it's reading from the can buffer (before the data get sent)
I will set up a can sniffer on a third PC so I can get the real measurements.
Agree the transmission time will be in average [300us ] and I was getting 350us.
Once I got the setup to run the test will how fast Peak Can Windows driver comparing to Linux socket !

Answer 3 · 2023-01-27T15:10:11.000Z

Here is the update
From windows it takes in average 237us and with Linux socket it takes 311us / 8bytes consecutive frame

Answer 4 · 2023-01-27T20:34:19.000Z

Yes, that looks better!
Btw. what kind of CAN interface are you using with Linux?

Answer 5 · 2023-01-27T20:50:00.000Z

The interface is the native CAN socket and the device is a NXP CAN driver.

Answer 6 · 2023-01-27T21:09:07.000Z

I'm not aware of any NXP CAN driver.
What does ip -det link show can0 show? Can you post that here?

Answer 7 · 2023-01-27T21:11:57.000Z

Here it is :
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 100
link/can promiscuity 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 500
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 5
flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp_inc 1
clock 40000000 numtxqueues 1 gso_max_size 65536 gso_max_segs 65535

Answer 8 · 2023-01-27T21:14:40.000Z

I'm not aware of any NXP CAN driver.
I mean the hardware transceiver is from NXP.

Answer 9 · 2023-01-27T21:19:53.000Z

Ah, flexcan driver!
I would have assumed that this on-board CAN IP core does perform at least as good as a Windows CAN adapter.
Did you create the logfile/measurement for the Linux/Windows comparison with the same test equipment?

Answer 10 · 2023-01-27T21:27:52.000Z

Yes I am using a CAN sniffer (from PEAK )and comparing the average speed of 100 consecutives frames.
The sniffer is using a different CAN port, so it's reading from the CAN bus and not from the driver.
(I guess in the first test, the sniffer was reading directly from the driver buffer and not from the CAN bus)

Answer 11 · 2023-01-27T22:04:25.000Z

FYI : The Linux application is running inside a container, so I run a new test using isotpsend and isotpreceive out of the container I got an average of 298,93us / 8 bytes consecutive frame so slightly better than 311us but still slower than windows.

=> The current ISOTP performance is great for us, thank you for developing and sharing the can-isotp module it is very useful :)

Answer 12 · 2023-01-28T06:08:13.000Z

Thanks @SeifHadrich ! It is always very helpful and interesting to get some feedback of "real world" users and measurement results as seen above. Have fun & best regards, Oliver