Cycle time fluctuating on Windows 10 (using Vector inferface)

[ALPfulben]

Describe the bug

The cycle times of CAN messages are fluctuating under Windows when using the send_periodic() function.
Expected cycle time 0.02s; Actual cycle time: 0.015s, 0.035s, 0.038s, 0.015s,...

When using Linux (Raspberry Pi) with the same Python code the cycles times are very accurate.

To Reproduce

bus = can.ThreadSafeBus(interface="vector", channel=0, app_name="CANoe", bitrate=500000)
msg_relay_ctrl_00 = can.Message(arbitration_id=0xABC, is_extended_id=False, data=[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00])
bus.send_periodic(msg_relay_ctrl_00, 0.02)  # 20ms 

Expected behavior

Cycle time of the CAN message should be 20ms +- 10%.

Observed behavior

Measured cycle times are fluctuating (e.g. 0.014940s, 0.036936s, etc.), see log below.

Additional context

When executing a CPU intensive task (for example watching a video) the cycle time is more accurate.

OS and version: Windows 10 Enterprise 2016
Python version: 3.9 (64-bit)
python-can version: 4.0.0
python-can interface: vector

Log & Code snippet

Some measured cycle times (average of the value is approx. 0.02s). Measured with CANoe.

0.014940
0.016039
0.037955
0.015012
0.016029
0.014916
0.016187
0.037411
0.015168
0.016315
0.015999
0.015839
0.036936
0.015417
0.015179
0.016255
0.015503
0.037425
0.014502
0.016747
0.014950
0.015247
0.038727

bus = can.ThreadSafeBus(interface="vector", channel=0, app_name="CANoe", bitrate=500000)
msg_relay_ctrl_00 = can.Message(arbitration_id=0xABC, is_extended_id=False, data=[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00])
bus.send_periodic(msg_relay_ctrl_00, 0.02)  # 20ms 

[zariiii9003]

Hello, thank you for reporting.
Can you please compare the timing between python-can 3.3.4 and 4.0.0?

4.0 is using a waitable timer, while 3.3.4 used time.sleep() on Windows.

[ALPfulben]

Hello zariiii9003,
I will test it tomorrow and let you know. Thanks for your fast reply!

[christiansandberg]

In general Windows has quite poor real time performance so I would not expect to get a decent accuracy unfortunately.

[ALPfulben]

Hello @zariiii9003,

here are the measurements:
cycle_time_log.txt
There are indeed some differences.

@christiansandberg: you're probably right :(, altough 20ms should be nothing for a "modern" system ;).

[zariiii9003]

The target was 20ms for both measurements? Is 3.3.4 even worse?

Can you check if this improves the timing? Maybe it only affects timers, i'm not sure.

import time
from ctypes import windll, wintypes

import can

if __name__ == '__main__':
    windll.winmm.timeBeginPeriod(wintypes.UINT(1))

    bus = can.ThreadSafeBus(interface="vector", channel=0, app_name="CANoe", bitrate=500000)
    msg_relay_ctrl_00 = can.Message(arbitration_id=0xABC, is_extended_id=False, data=[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00])
    bus.send_periodic(msg_relay_ctrl_00, 0.02)  # 20ms

    time.sleep(10)

    windll.winmm.timeEndPeriod(wintypes.UINT(1))

You can also increase process priority with pywin32:

pid = win32api.GetCurrentProcessId()
handle = win32api.OpenProcess(win32con.PROCESS_ALL_ACCESS, True, pid)
win32process.SetPriorityClass(handle, win32process.HIGH_PRIORITY_CLASS)

[ALPfulben]

Yes, the target is 20ms. It seems like 3.3.4 is worse (average is far away from 20 ms).

windll.winmm.timeBeginPeriod() does have an impact. The cycle time is much more accurate:

cycle_times_with_timeBeginPeriod().txt

[zariiii9003]

That's probably the best you can achieve on Windows.

But i don't know whether python-can can do anything here. Libraries should not change system settings.
We could mention it in the docs though.

[ALPfulben]

I understand. I will use you're workaround for the moment :). Thanks for the great support!