SocketCAN hardware timestamps

[etcan]

We were using the chardev driver before but want to change to SocketCAN. We also want to acquire hardware timestamps synchronized with the host, which worked flawlessly with the chardev driver with deftsmode=6.

Interface is a PCAN-PCI Express FD and driver version is the newest (8.18.0) compiled with NET=NETDEV_SUPPORT.

For the hardware timestamps with SocketCAN, we followed the tips mentioned here. We are getting hardware timestamps but they do not correspond to the system clock.

Code: Select all

stamp[0]: 1733835352882403801, stamp[2]: 251773583000
stamp[0]: 1733835352892418911, stamp[2]: 251783597000
stamp[0]: 1733835352902431868, stamp[2]: 251793610000
stamp[0]: 1733835352912451927, stamp[2]: 251803626000
stamp[0]: 1733835352922460315, stamp[2]: 251813639000
stamp[0]: 1733835352932477529, stamp[2]: 251823656000
stamp[0]: 1733835352942490505, stamp[2]: 251833668000
stamp[0]: 1733835352952503602, stamp[2]: 251843682000
stamp[0]: 1733835352962518030, stamp[2]: 251853696000
stamp[0]: 1733835352972531277, stamp[2]: 251863709000
stamp[0]: 1733835352982546979, stamp[2]: 251873724000

The hardware stamps (stamp[2]) seem to be just hardware timestamps of the interface not synchronized with the host. They are also restarted when the driver is reloaded with modprobe. Changing deftsmode to other values has no effect and explicitly setting drvclkref=0 does not help either.

[S.Grosjean]

Hello,

The hardware timestamps provided by the netdev interface of the PCAN driver are actually the raw one which are read from the device, without any further processing next. This has been done in order to return back the same timestamps than those returned by the mainline socket CAN drivers.

Therefore, defstmode has become useless in that netdev mode. If you need host timestamps, then you should set SO_TIMESTAMPING and read 1/ the software timestamp from stamp[0] 2/ the raw hardware timestamp from stamp[2].

Regards,

[etcan]

Hello Stéphane,

thank you very much for your quick response.

I do not understand the reason why deftsmode is ignored. Isn't the reason for the parameters to override the default behavior? For example, parameters like fdirqcl are working. Could you please consider to change this behavior? For us, the raw hardware timestamps are not very useful, since we want to synchronize to system time and other sensors, which are synchronized via PTP.

We have set SO_TIMESTAMPING to

Code: Select all

(SOF_TIMESTAMPING_SOFTWARE |
 SOF_TIMESTAMPING_RX_SOFTWARE |
 SOF_TIMESTAMPING_RAW_HARDWARE)
 

and we are getting software stamps for RX and TX, but no hardware stamp for TX (we get TX stamps as suggested here).
Setting SO_TIMESTAMPING to

Code: Select all

(SOF_TIMESTAMPING_RX_SOFTWARE |
 SOF_TIMESTAMPING_RAW_HARDWARE)
 

we get both hardware stamps, but of course no software stamps anymore. Is there any setting to get all four?

Best regards,
Thomas

[etcan]

Hello again,

I searched the forum a bit more and just found this post, suggesting the netdev should allow to change the timestamp behavior.

Best regards,
Thomas

[S.Grosjean]

Hi,

As said, this old behavior is no more supported. On the other hand, if you'd like to get it back, and since the driver is open source, then you are able to change this by yourself. Please download (for ex) https://www.peak-system.com/fileadmin/m ... 0.2.tar.gz to know how to operate (see pcan_netdev.c) or (try to) run that old version of the driver if you prefer.

Regards,

[etcan]

Hi Stéphane,

thanks for the suggestion. I copied over

Code: Select all

if (pf->flags & PCANFD_HWTIMESTAMP)
{
	struct skb_shared_hwtstamps *hwts = skb_hwtstamps(skb);

	// pqm->hwtv.ts_mode = PCANFD_OPT_HWTIMESTAMP_RAW;

	/* cook the hw timestamp according to ts_mode */
	pcan_sync_timestamps(dev, pqm);

	hwts->hwtstamp = timeval_to_ktime(pf->timestamp);

	skb->tstamp = hwts->hwtstamp;
}

and moved the #ifdefs in pcan_main accordingly. Now the hardware stamps are all 0. Is there something else I am missing?

I could not compile 8.10.2 unfortunately, presumably due to a too new kernel (6.8).

Best regards,
Thomas

[etcan]

Hi Stéphane,

I still do not understand why it is not possible to default the driver to deftsmode=3 and still make it possible to change its behavior with the parameter. Could you please elaborate on this decision?

Best regards,
Thomas

[S.Grosjean]

Hi Thomas,

The hardware timestamps provided by the netdev interface of the PCAN driver are actually the raw one which are read from the device, without any further processing next. This has been done in order to return back the same timestamps than those returned by the mainline socket CAN drivers.

Therefore, defstmode has become useless in that netdev mode.

Time management is a bit complex, because it has to handle clock drifts and also kernel clocks. This means that timestamp that is cooked in that way can no longer be consider as "hardware timestamp" in the way it is understood in socket-CAN.

Regards,

[etcan]

Hi Stéphane,

I am aware that time synchronization is quite complex. That is one of the reasons we want to make use of hardware timestamps.

I think I still do not understand fully. Does that mean, the cooked stamps were working up to 8.10.2 as "hardware timestamps"? As I said, we are using the hardware stamps of thechardev driver successfully and I wonder why they are not ok for SocketCAN? Did something change in SocketCAN after 8.10.2?

Best regards,
Thomas

[S.Grosjean]

Hi,

Nope, nothing as changed in socket-CAN meanwhile. But, as already said, the PCAN driver in netdev mode now gives the same hw timestamps that the mainline drivers do. It's just a question of consistency between PEAK-System drivers.

Regards,