Hello,
I have configure one of my machines as a unicast BC which is synchronized
to the grandmaster clock via the first of it's two ports. The second port
is used to provide sync to another local machine. This setup works for a
few hours after which one of the ports (master port) is marked as faul
On 7 Jun 2021 at 11:42, Richard Cochran wrote:
>
> On Mon, Jun 07, 2021 at 02:01:28PM +, Geva, Erez wrote:
>
> > Jun 7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx
> > timestamp
> > Jun 7 15:44:07 ipc01 ptp4l: [673.869] increasing tx_timestamp_timeout may
> > correct this
On Mon, Jun 07, 2021 at 02:01:28PM +, Geva, Erez wrote:
> Jun 7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx
> timestamp
> Jun 7 15:44:07 ipc01 ptp4l: [673.869] increasing tx_timestamp_timeout may
> correct this issue, but it is likely caused by a driver bug
Try --tx_ti
...just my two cents worth, I haven't seen this error message for a
few years. I did get it back in 2017-ish on some older LOM NIC's by
Intel. The i210 has always been a workhorse for me.
This message is "local" = somewhere between the NIC HW and the
kernel-mode driver.
Then again, I'm not using th
Hi,
I see an issue with the ptp4l using an Intel I210 connected back to back to an
Intel i255.
I am not sure if the issue is Intel related or is it ptp4l.
Probably something wrong that I did.
I use a very simple configuration:
On client side:
[global]
delay_mechanism P2P
network_transport L2
tim
