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.
> > 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
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
