Hi Stéphane,
ok, thanks for clarifying. In that case, I understand even less why you don't allow your users to change the behavior with the deftsmode parameter. Changing parameters with the mainline driver is not allowed anyway.
Best regards,
Thomas
Search found 13 matches
- Wed 18. Dec 2024, 15:14
- Forum: Linux
- Topic: SocketCAN hardware timestamps
- Replies: 10
- Views: 10861
- Tue 17. Dec 2024, 11:50
- Forum: Linux
- Topic: SocketCAN hardware timestamps
- Replies: 10
- Views: 10861
Re: SocketCAN hardware timestamps
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 hardwa...
- Wed 11. Dec 2024, 14:13
- Forum: Linux
- Topic: SocketCAN hardware timestamps
- Replies: 10
- Views: 10861
Re: SocketCAN hardware timestamps
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
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
- Wed 11. Dec 2024, 14:08
- Forum: Linux
- Topic: SocketCAN hardware timestamps
- Replies: 10
- Views: 10861
Re: SocketCAN hardware timestamps
Hi Stéphane, thanks for the suggestion. I copied over 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 = tim...
- Wed 11. Dec 2024, 09:04
- Forum: Linux
- Topic: SocketCAN hardware timestamps
- Replies: 10
- Views: 10861
Re: SocketCAN hardware timestamps
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
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
- Wed 11. Dec 2024, 08:58
- Forum: Linux
- Topic: SocketCAN hardware timestamps
- Replies: 10
- Views: 10861
Re: SocketCAN hardware timestamps
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...
- Tue 10. Dec 2024, 14:46
- Forum: Linux
- Topic: SocketCAN hardware timestamps
- Replies: 10
- Views: 10861
SocketCAN hardware timestamps
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 w...
- Fri 31. Jan 2020, 17:56
- Forum: PCAN-PCI Express FD
- Topic: Typical round-trip latency
- Replies: 8
- Views: 10843
Re: Typical round-trip latency
... and with fdirqcl=1 it gets below 250 µs 

- Fri 31. Jan 2020, 17:20
- Forum: PCAN-PCI Express FD
- Topic: Typical round-trip latency
- Replies: 8
- Views: 10843
Re: Typical round-trip latency
Hi Stéphane,
perfect, with a setting of fdirqtl=1 i get a mean round-trip latency of about 400 µs
Thank you very much for the fast and competent support.
Best regards and have a nice weekend,
Thomas
perfect, with a setting of fdirqtl=1 i get a mean round-trip latency of about 400 µs

Thank you very much for the fast and competent support.
Best regards and have a nice weekend,
Thomas
- Fri 31. Jan 2020, 16:34
- Forum: PCAN-PCI Express FD
- Topic: Typical round-trip latency
- Replies: 8
- Views: 10843
Re: Typical round-trip latency
Hi Stéphane, great, this sound exactly what I was looking for. I made some further tests and when I lower the rate of sending CAN-messages the mean latency also increases to up to about 1.3 ms, which seems to be in line with the 10x100 µs you mentioned. Right now I use the mainline driver of the ker...