Sending rate cannot be faster than 300us

[SeifHadrich]

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.

[hartkopp]

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.

[SeifHadrich]

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 !

[SeifHadrich]

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

[hartkopp]

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

[SeifHadrich]

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

[hartkopp]

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

[SeifHadrich]

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

[SeifHadrich]

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

[hartkopp]

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?

[SeifHadrich]

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)

[SeifHadrich]

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 :)

[hartkopp]

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