|
From: Cliff S. <th...@go...> - 2018-06-14 20:07:07
|
On Wed, Jun 13, 2018 at 12:28 AM Gwyn Gwrtheyrn <gwy...@gm...> wrote: > Furthermore, it displays messages 'waiting for ptp4l..' in the beginning when de ptp4l container is not yet up and running. *This does not even makes sense *since I am trying to synchronise the physical hardware clock to the system clock, so *why* should phc2sys have to wait for ptp4l in order to synchronise the physical hardware clock? The -w you're passing to phc2sys tells it to wait for ptp4l to be in a stable state. If you don't want phc2sys to wait, then you can just drop that option. Could you generally try "phc2sys -a -r -r -m" instead to have phc2sys automatically load configuration from ptp4l? You could later use manual configuration, but this will eliminate one source of potential errors. In general, when you're typing /dev/ptp* that is likely getting expanded by your shell into the list of matching files (e.g /dev/ptp* -> "/dev/ptp0 /dev/ptp2") before executing the command. -i only accepts one interface so I suspect that /dev/ptp*'s expansion is being entirely ignored by ptp4l. Maybe try running the slave ptp4l with software timestamping. If it works well, you'd get some confidence that the master is working correctly. With hardware timestamping, it's possible that the issue is a driver bug -- every driver I've encountered so far has had at least one hardware timestamping bug that I've had to fix. You may want to use wireshark on the slave to see what the incoming packets look like. |