socketCAN invalid rx timestamps

[martin.wagner]

Hi@all,

I'm having a problem with getting kernel/driver generated timestamps on PCAN USB Interface / socketCAN driver. After some time, the kernel timestamps of received messages are in the future compared to locally generated timestamps:

Code: Select all

clock_gettime: (2018-10-16 13:28:50.365177) kernel timestamp: (2018-10-16 13:28:50.364992)  can1  735   [1]  7F

wait approx. 15 minutes...

Code: Select all

clock_gettime: (2018-10-16 13:44:28.693404) kernel timestamp: (2018-10-16 13:44:28.693810)  can1  735   [1]  7F

The deviation gets more the longer my interface is up. With a few hours uptime it's in the 10s region. Resetting the interface clears the error.

With messages sent by another application, but on the same interface, timestamps work as expected:

Code: Select all

clock_gettime: (2018-10-16 13:44:29.906611) kernel timestamp: (2018-10-16 13:44:29.906535)  can1  701   [1]  7F

Any ideas what might cause this behaviour?

- Application: candump can1 -tA . Extended to print time when candump processes message, see attachment.
- Driver: peak-linux-driver-8.6.0, option NET=NETDEV_SUPPORT enabled to get socketCAN
- System: Debian 9, Kernel 4.14.0-0.bpo.3-amd64
- Device: PEAK System PCAN-USB
- 1 MBit bus
- message log is in attachment. COB IDs 0x701 and 0x7E5 are sent, all others received.

Thanks for your help!

[S.Grosjean]

Hello,

Unfortunately, the peak_usb driver doesn't handle any clocks drift in the so-called hardware timestamps it gives to the network layer, while the pcan driver does. Handling clocks drift in pcan for the PCAN-USB is recent. Such a feedback like yours helps us in including these improvements in the future version of the mainline driver.

Meanwhile, instead of using SO_TIMESTAMP socket option, use SO_TIMESTAMPING and consider stamp[0] in the cmsg received (see candump.c). You should get the so-called software timestamps instead.

Regards,

[martin.wagner]

Thanks for your reply!

Can you please give some more details? I've replaced SO_TIMESTAMP option with SO_TIMESTAMPING in candump.c, however now timestamping stopped working completely. I also don't have a variable stamp[0], neither in cmsg struct nor anywhere in candump.c.

Is this problem specific to USB devices? Do hardware timestamps work on pci/pcie devices?

[S.Grosjean]

Hi,

About candump.c, please see here:
https://github.com/linux-can/can-utils/ ... ump.c#L726

At the moment, only the pcan driver does handle the different clocks drift for all of our kind of USB and/or CAN-FD devices.

isa/pci/pcie CAN 2.0 *ONLY* devices (aka PCAN-ISA / PCAN-PCI / PCAN-PCIe) are not equipped to provide any hardware timestamps at all. You'll always get software timestamps from such devices.

To summarize, at the moment, if you need hardware timestamps (with clocks drift handling), please use any of our CAN-FD devices (100% compatible with CAN 2.0 a/b) or the PCAN-USB, with our "pcan" driver.

Regards,

[martin.wagner]

Thanks, the canutils repo moved home again...

I've played with TIMESTAMPING mode a bit, but I still can't get it to work properly. When I use this like in candump.c, I expect to get software timstamp in stamp[0] and hardware timestamp in stamp[2]. However, there is no difference between those two, and there is also no difference between timestamps in TIMESTAMP and TIMESTAMPING mode. The deviation from system time keeps in place.

The only difference between stamp[0] and stamp[2] that I can see is that there is no Tx timestamp.

Code: Select all

clock_gettime: (2018-10-22 14:22:38.300636) stamp[0]: (2018-10-22 14:22:38.300603) stamp[2]: (1970-01-01 01:00:00.000000)  can0  7E5   [8]  51 00 00 00 00 80 00 00
 clock_gettime: (2018-10-22 14:22:38.315550) stamp[0]: (2018-10-22 14:22:37.749868) stamp[2]: (2018-10-22 14:22:37.749868)  can0  74E   [1]  7F
 clock_gettime: (2018-10-22 14:22:38.332516) stamp[0]: (2018-10-22 14:22:37.756382) stamp[2]: (2018-10-22 14:22:37.756382)  can0  74D   [1]  7F
 clock_gettime: (2018-10-22 14:22:38.348477) stamp[0]: (2018-10-22 14:22:38.348439) stamp[2]: (1970-01-01 01:00:00.000000)  can0  701   [1]  7F
 clock_gettime: (2018-10-22 14:22:38.350499) stamp[0]: (2018-10-22 14:22:37.762740) stamp[2]: (2018-10-22 14:22:37.762740)  can0  757   [1]  7F
 clock_gettime: (2018-10-22 14:22:38.972557) stamp[0]: (2018-10-22 14:22:38.624192) stamp[2]: (2018-10-22 14:22:38.624192)  can0  756   [1]  7F
 clock_gettime: (2018-10-22 14:22:39.081521) stamp[0]: (2018-10-22 14:22:38.664128) stamp[2]: (2018-10-22 14:22:38.664128)  can0  741   [1]  7F

[S.Grosjean]

Hi,

Ok, if both timestamps are the same, there's maybe something wrong into the linux-can core itself. Please use the pcan driver in netdev mode while this issue is not fixed.

Regards,

[martin.wagner]

Hi,

I'm using the USB adapters to debug an embedded application on my desktop PC, as this simplifies development quite a bit. The SOC CAN module uses socketCAN, so I can't switch driver.

The SOC can driver (flexcan) produces valid software timestamps, however it doesn't implement hardware timestamps. So it seems to me that if this is a problem in linux core and not the PCAN driver, it is only triggered when the driver registers timestamping functions. Can I somehow disable (comment out before compiling?) those in PCAN driver?

[S.Grosjean]

Hi,

I'm sorry but it's confusing: you were talking about "kernel driver" and, also, about "PCAN driver".

To fix:

- the peak_usb driver is the mainline kernel driver that is part of the Kernel since v4.0 hat handles all PEAK-System USB interfaces
- the PCAN driver is a chardev or netdev interface out-of-tree driver that handles all PEAK System hardware

As told before, the peak_usb driver handles raw timestamsps from the hardware and doesn't handle any clock drift.

If you're using the PCAN driver in netdev mode, then you can tune handling of hw timestamps by using the "deftsmode" module parameter in /etc/modprobe.d/pcan.conf, as described in the user documentation.

For example, if you want software timestamps only, then use deftsmode=0:

Code: Select all

# pcan - automatic made entry, begin --------
# if required add options and remove comment
options pcan deftsmode=0
install pcan /sbin/modprobe --ignore-install pcan
# pcan - automatic made entry, end ----------

Regards,

[martin.wagner]

Hi,

thanks for your reply.

I'm using the 8.6.0 source driver in netdev mode and with socketCAN interface. Hope that is correct now

Adding "deftsmode=0" to pcan.conf file fixed the software timestamps for me. I've stopped reading docs at "install package" .

regards