PEAK-System Forum

Hi to all,
I have encountered a performance bottleneck using a PCAN Peak device, and opened a new issue on the python-can's github page:
h**ps://github.com/hardbyte/python-can/issues/1685
Since in my opinion it seems that the problem is outside of Python, I'll post it here as well. I don't want to spam, it's just to get some more insight on what might be going on. Here is the copy-paste (sort of) of the github issue:

Describe the bug
To put it simply, I have a python script that implements a simple protocol to flash a device via canbus. I'm using the python-can library, and have access to a PCAN peak and a VN1630 from Vector. Very easy to use, just change the interface and channel (at a speed of 500k, can non-fd, every other setting is the default) and the script works flawlessly with both hardware devices.
The problem I'm having is actually with performance: with no modifications to the script (except obviously to the channel and interface), with the PCAN Peak the bus usage sits at around 30%, and with the VN1630 at around 74%. Obviously the latter finishes much quicker. I tried profiling using cProfile and Snakeviz to visualize the results, and here they are:

Using the PCAN Peak:


Using the Vector VN1630:


As you can see, the vast majority of the time in both cases is spent inside the `_winapi.WaitForSingleObject` call; and in fact, being called approx. 82k times in both cases, with the Peak the "percall" time is much higher than with the VN1630.

Am I missing something? Is this due to some driver implementation detail? Can this be fixed/improved/circumvented without touching the device's drivers?

To Reproduce
I'll link both `.prof` files in case anyone else want to take a look at it:
h**ps://github.com/hardbyte/python-can/files/13166237/programperf.zip

Expected behavior
The performance of both devices should match, or at least not be so great.

Additional context

OS and version: Windows 10
Python version: 3.11.3
python-can version: 4.2.2

Edit by Admin ** read Forum Rules - external links are NOT allowed **

Hi,

which PCAN Interface, driver, firmware and API version do you use in your tests. Next we can't support any 3rd party python solutions. So as a test, please use our PCANBasic python interface and do your tests again with that API.

regards

Michael

Hi, sorry for the lack of information in the first post. I use the PCAN Peak non-fd adapter, with serial IPEH-002022-259836 (I actually have multiple but this is the one I used for this specific test). The device driver version is: PCAN_USB 4.4.0.16619 (KMDF 1.15, x64, Universal). Regarding the "PCANBasic.py" file, it is dated with "Last change: 2022-11-23". The .dll version is 4.7.0.793, dated 03/03/2023. I have run again the script, this time adapting it to use directly the PCANBasic.py API as you suggested, but the results are kinda the same. The bus doesn't get fully used, and sits at around 30% usage at 500k bitrate. The vast majority of the time is spent outside of python and inside the "PCANBasic.py:544(Read)" function, as you can see in this new .perf file: h**ps://uploadnow.io/it/share?utm_source=Z5dKx6D . I'll also include a screenshot of the profiling: h**ps://ibb.co/8BNymq0 . As you can see, most of the time is spent inside that Read function, but this time the program is making A LOT more calls, more than 28 million! The script I'm using is a very simple one, and is calling directly the ".Read" function of the instantiated "PCANBasic()" object instantiated. Hope this helps!

EDIT: the script is based on this flashing script from Texas Instruments:
h**ps://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/09_00_00_35/exports/docs/api_guide_am263x/EXAMPLES_DRIVERS_SBL_CAN_UNIFLASH.html
it's included in the latest MCU+ sdk. It's customized (to remove the tqdm progress bar and other stuff) but other than that it's the same. The .perf file uploaded in this post refers to this script.

Edit by Admin ** read Forum Rules - external links are NOT allowed **

Hi,

our software developers will have a look on that topic to check where the performance get lost. Stressing the driver/CPU with too much "empty" Read() calls could also be an issue.

regards

Michael

Thanks in advance for the help. I couldn't find how to contact you directly via private message, I could send you privately the concerned script.
Riccardo

Hi,

you can send it by email using our support email address.

regards

Michael

Hi,
I have just sent and email to "support@peak-system.com" with the attachments.
Riccardo

Thanks,

we received your files.

Hi,
I don't mean to be pushy, I just wanted to know if there are any updates on the matter and/or if there is anything else I can do to help debug the problem.
Thanks,
Riccardo

Hello Riccardob,

riccardob wrote: ↑

Tue 14. Nov 2023, 16:30

I don't mean to be pushy, I just wanted to know if there are any updates on the matter

we have some preliminar investigation using own tests and tools and we cannot see any problems. Nevertheless, we have included an investigation using your python tests in our todo list, but this may take some weeks until we get resources for this.

Regarding your initial post,

riccardob wrote: ↑

Wed 25. Oct 2023, 15:42

As you can see, the vast majority of the time in both cases is spent inside the `_winapi.WaitForSingleObject` call; and in fact, being called approx. 82k times in both cases, with the Peak the "percall" time is much higher than with the VN1630.

Am I missing something? Is this due to some driver implementation detail? Can this be fixed/improved/circumvented without touching the device's drivers?

WaitForSingleObject calls are made not in the DLL but in the caller. If there is a problem with this, is maybe the way how APIs are getting messages from the Read functions. In PCAN-Basic, each call to CAN_Read match only one CAN message. We do not know how Vector behaves, but we assume that it works similar to our professional API, CanApi4, in where each call to CAN_Read just get as much message as avilable in the reception queue, as an array of messages. This can make a difference since for PCAN-Basic you should poll until the queue is empty each time you get the read event triggered.

riccardob wrote: ↑

Tue 14. Nov 2023, 16:30

if there is anything else I can do to help debug the problem

Your help is appreciated and we will contact you if we need anything else.