CAN message reading delay in can.socket

Please provide the following info (check/uncheck the boxes after creating this topic):
Software Version
DRIVE OS Linux 5.2.6
DRIVE OS Linux 5.2.6 and DriveWorks 4.0
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
[+] NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version

Target Operating System
[+] Linux

Hardware Platform
[+] NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)

SDK Manager Version

Host Machine Version
[+] native Ubuntu 18.04

Hi team,
We are trying to read the CAN data through socket can (can2 and can6). We are using CAN interpreter sample for reading and parsing the CAN messages.

We tried with the sample code with ‘can.virtual’. when sample reads from default file and reading CAN message using ‘dwSensorCAN_readMessage’, its is taking 0 milliseconds only for reading one message. (when we tried with tic-toc around ‘dwSensorCAN_readMessage’).

But when we directly read from CAN devices (using device = can.socket) for reading one message using ‘dwSensorCAN_readMessage’ its taking 9 to 10ms. Is this behavior is expected? or are we doing something wrong here?
Just to make it clear, the data rate at which CAN messgaes are coming from devices is certainly less than 10ms (less than 1ms actually).
I shall summarize how we tested it in drive agx xavier.
We connected CAN 2 and 6 to our CAN devices. We modified the CAN interpreter code to read from actual CAN devices in real time then logged the time required for reading one CAN message using ‘dwSensorCAN_readMessage’.
Could you please give me your valuable suggestions?

Hi, @nithin.m1
Why did you need to modify sample_canbus_interpreter to read from the system CAN bus? Doesn’t it support can.socket?
Can you observe the issue with the default sample application (with only change for checking the time)?
Can you observe the issue with messages sent from a host with CAN bus USB adapter?

Hi @VickNV,

Sorry, It was an issue with our code. We rectified it in code and it is working now correctly. Sorry for the confusion.

Thank you for letting us know and good to hear you figured it out.