PEAK-System Forum

Hello,

We have a PCAN-PCI Express FD Four Channel card on a Lubuntu 18.04.3 PC. I have written a small test program to send CAN messages from one channel and receiving on another while logging timestamps (std::chrono::high_resolution_clock::now()) just before write() and after read() respectively to estimate the typical round-trip latency. The interfaces were set to 1 Mbit/s. I tried with both the netdev (mainline) and the chardev (8.9.3) driver with 5.3-generic, 5.3-lowlatency, and 5.4.-rt-xanmod Kernels. Aside from different intermittent max spikes all setups show similar results with a mean round-trip latency between 7-800 µs. Is this a good value or is it worthwhile to further investigate possible optimizations?

I hope I have provided all information.

Best regards
et

What I forgot to add: The jitter of the round-trip latency seems rather high between about 200 µs and 1.4 ms (disregarding intermittent peaks of a few ms).

Hello,

First, it would help if you gave us the source file of the test program.

Anyway, you can't really trust the way you measure your time difference: AFAIU this is rather "the time between the moment you place your message in the driver's outbound queue and the moment you went to read its inbound queue". Thus, this delay depends also on your host arch and the cpu load,...

Does this delay change when, for example, you decrease the speed of the CAN bus?

Regards,

Hello Stéphane,

thank you very much for your reply.

You are absolutely correct, that the time we are measuring is "on a high level", but this is the time we are interested in. Or rather the other way around: in the target system we will get a message and have to send our response within 2 ms. This should be possible with the delays I have measured, but i wondered if we could get better to have a higher safety margin. Especially because the minimum delay we measured is around 200 µs. Do you have any experience on your systems what would be the best achievable mean delay? Is it perhaps possible to set the driver's queue to minimum delay instead of maximum throughput?

At 500 kbit/s we get about the same mean delay.

Is it possible to send the code to you via e-mail?

Regards,
Thomas

Hi Thomas,

According to your tests, it seems that the CAN bus is not the bottleneck of your testbed.
Moreover, these delays are quite identical whatever the drivers or the kernels are.

The pcan driver behavior can be configured to answer a bit quicker to the PCIe FD hw interrupts:

Code: Select all

$ modinfo pcan.ko
...
parm:           fdirqcl: PCIe FD IRQ Count Limit (default=16) (uint)
parm:           fdirqtl: PCIe FD IRQ Time Limit (default=10) (uint)

fdirqcl defines the limit of pending frames above which the HW generates a hw interrupt, while
fdirqtl defines the time limit above which the HW generates a hw interrupt.

Roughly, with the above defaults, a HW interrupt is generated if at least 16 CAN frames have been received by the controller, or after 10 x 100 µs if less have been received.

Lowering these values should increase the responsiveness of the driver. For example, to change fdirqtl to 500 µs, change /etc/modprobe.d/pcan.conf like this:

Code: Select all

# pcan - automatic made entry, begin --------
# if required add options and remove comment
# options pcan type=isa,sp
options pcan fdirqtl=5
install pcan modprobe --ignore-install pcan
# pcan - automatic made entry, end ----------

Then unload then reload the driver:

Code: Select all

$ sudo rmmod pcan
$ sudo modprobe pcan

Regards,

Hi Stéphane,

great, this sound exactly what I was looking for.

I made some further tests and when I lower the rate of sending CAN-messages the mean latency also increases to up to about 1.3 ms, which seems to be in line with the 10x100 µs you mentioned.

Right now I use the mainline driver of the kernel and I cannot get a modinfo on pcan.ko and /etc/modprobe.d/pcan.conf does not exist. Are these settings also possible with the mainline driver or do I have to compile the driver?

Best regards,
Thomas

Hi Thomas,

Unfortunately, up to now, module parameters weren't allowed with mainline drivers. Thus, the peak_pciefd one runs with the same default values than the pcan driver.
Except if you are able to rebuild your Kernel and change by yourself these default values, you'll have to run with the pcan driver instead.

Regards,

Hi Stéphane,

perfect, with a setting of fdirqtl=1 i get a mean round-trip latency of about 400 µs

Thank you very much for the fast and competent support.

Best regards and have a nice weekend,
Thomas

... and with fdirqcl=1 it gets below 250 µs

PEAK-System Forum

Typical round-trip latency

Typical round-trip latency

Re: Typical round-trip latency

Re: Typical round-trip latency

Re: Typical round-trip latency

Re: Typical round-trip latency

Re: Typical round-trip latency

Re: Typical round-trip latency

Re: Typical round-trip latency

Re: Typical round-trip latency