+CC: Richard Cochran <richardcochran@xxxxxxxxx>
(Resend, this time puting Richard in CC for real).
On Mon. 27 Jun. 2022 at 00:34, Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote:
> On 26.06.2022 22:40:13, Vincent MAILHOL wrote:
> > > > > I'm currently playing around with hardware timestmaps in the mcp251xfd
> > > > > driver and the other day I stumbled over commit 741b91f1b0ea ("can: dev:
> > > > > can_put_echo_skb(): add software tx timestamps") and I was thinking
> > > > > which tool you're using to test this. :)
> > > > >
> > > > > Once the hardware timestamps are running stable, this is exactly the
> > > > > tool I need! Thanks for sharing this.
> > > >
> > > > Does the mcp251xfd use the host clock to do its hardware timestamp?
> > >
> > > It uses an external 40 MHz oscillator, usually each device has it's own.
> > >
> > > > (Not sure how SPI hardware works and if they have their own quartz or
> > > > if they share it with the host system). If it is indeed the same clock
> > > > you can have even more precise statistics.
> > >
> > > No, the device clock is not shared with the host system and thus drift
> > > apart. But you can synchronize the device's clock against the system
> > > clock with phc2sys of linuxptp. As soon as the code is stable I'll send
> > > the patches around.
> >
> > This sounds really exciting. I also wanted to play with linuxptp but
> > never had time to start.
>
> I started with adding the basic callback for /dev/ptpX to show up and
> "work", i.e. not crash :). What probably most CAN devices lack is the
> possibility to fine tune the oscillator, but I figured out, there is a
> ptp clock multiplexer in the kernel that does the fine tuning in
> software. I ported that code and now I can run phc2sys on the mcp251xfd.
>
> What does phc2sys do? It's used to synch a PTP Clock to the Linux system
> clock or vice versa. The only sensible use case of this all is to sync
> from the Linux system clock to the mcp251xfd device clock. This way the
> hardware timestamps are within µs of the Linux system clock.
>
> > With the device clock synchronized, you can have decent timestamping
> > between different hardware (potentially of different brands).
>
> So far I only synchronize the Linux system clock into the mcp251xfd
> clock. I could synchronize a 2nd CAN adapter implementing a /dev/ptp on
> the same system, too.
>
> > The drawback is that you would lose a bit of precision: the hardware
> > timestamp have an accuracy around 1 microsecond. After using PTP, I
> > would expect the precision to degrade to roughly 100 microsecond
> > (which is still way better than what software timestamping can offer).
>
> Synchronizing time via CAN between different systems would be the next
> logical step. But linuxptp needs code to map the PTP messages to CAN
> frames. This will not work with raw CAN, as the messages are too long.
> Maybe CAN-FD or ISO-TP can help. But I haven't looked into this.
This is already a solved problem. I suggest having a look at the
existing standards.
My top recommendation would be AUTOSAR Classic Platform’s Time
Synchronization over CAN:
https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_SWS_TimeSyncOverCAN.pdf
(I haven't studied it so I am not yet able to explain).
Another candidate would be PTP over DeviceNET over CAN from Annex G of
IEEE 1588, c.f.
https://lore.kernel.org/all/20210112021420.GA18703@xxxxxxxxxxxxxxxxxx/
(I never used DeviceNET and never read IEEE 1588, I just recalled this
message from Richard)
> > > What does tcpdump show on a Ethernet if you enable TX timestamps?
> >
> > I never went so far.
> >
> > For tcpdump, the interested flags are:
> > * -J (a.k.a. --list-time-stamp-types)
> > * -j tstamp_type (a.k.a. --time-stamp-type=tstamp_type)
> >
> > But I never went so far to make them work. If you want to try it,
> > first be sure that the driver of your network interface calls
> > skb_tx_timestamp() in its xmit() function.
>
> I think some interfaces on our compile cluster support PTP.
>
> > > > I also guess there is no official support but then,
> > > > I am wondering how hard it would be to hack the error queues to expose
> > > > them to the privileged processes.
> > >
> > > Maybe there's general interest of pushing error queue data via packet
> > > socket, too. As this is not a CAN specific issue.
> >
> > I think so. This is just a niche topic, so we need to find the code
> > snippet which will put some light on this. I am convinced that some
> > solution should exist, just do not have enough time to investigate.
> > Studying the source code of tcpdump is probably one of the best idea I
> > can think of right now.
>
> sound like the right direction
Another interesting tool for network interface timestamps which I
forgot to mention is:
ethtool -T
But I guess you already started to use it in mcp251xfd because you
will need it to advertise the PTP hardware clock to the userland.
Yours sincerely,
Vincent Mailhol
