Hi Miroslav,
Please find the below inline:
Ok, so there is a gPTP bridge between ECU1 and ECU2. What do you see
in its announce messages? Is the grandmaster identity changing over
time?
*Ans: *No, The "grandmasterclockidentity" is not changing, its always
contain the identity of the clock who i
On Mon, Sep 12, 2022 at 07:23:03PM +0530, Raj wrote:
> Yes, ECU1 sends Announce packet in every 2 sec , however the switch in
> between (NETGEAR GS724Tv4) sends Announce packet to ECU2 every 1 sec.
>
> I tried with "logAnnounceInterval 0" in both ECU1 & ECU2 and observed the
> same issue as me
Hi Miroslav,
Yes, ECU1 sends Announce packet in every 2 sec , however the switch in
between (NETGEAR GS724Tv4) sends Announce packet to ECU2 every 1 sec.
I tried with "logAnnounceInterval 0" in both ECU1 & ECU2 and observed the
same issue as mentioned above.
Thanks,
Raj
On Mon, Sep 12, 2022
On Sat, Sep 10, 2022 at 09:18:04PM +0530, Raj wrote:
> We are observing that When ECU1 is active ECU2 initially takes a long time
> (randomly 10 sec - 2min approx) to sync with ECU1(GM) and once ECU2
> successfully syncs with ECU1 then after that there is no issue. ECU2
> throwing "SLAVE to MASTER
On Fri, Jul 29, 2022 at 03:44:48PM +0600, - - wrote:
> Thanks for the help, I will try to change the driver.
> Can you also help:
> I periodically see this message from the slave side:
> port 1: UNCALIBRATED to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
The client has Announce messages timing o
Thanks for the help, I will try to change the driver.
Can you also help:
I periodically see this message from the slave side:
port 1: UNCALIBRATED to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
Which leads to a loss of synchronization.
I don't see an error on the master side. I have added a tx a
On Thu, Jul 28, 2022 at 04:38:52PM +0600, - - wrote:
> Yes, but it doesn't always work.
> I increased it to 100msec.
That driver, e1000e, uses a plain old "work" to process the Tx time
stamp. Plain "work' runs at the lowest priority in Linux. On a busy
system, even higher delays than 100 ms are
Yes, but it doesn't always work.
I increased it to 100msec.
Best regards,
Vyasheslav
ср, 27 июл. 2022 г. в 20:00, Richard Cochran :
> On Wed, Jul 27, 2022 at 04:20:48PM +0600, - - wrote:
> > ptp4l[402.740]: timed out while polling for tx timestamp
> > ptp4l[402.740]: increasing tx_timestamp_time
On Wed, Jul 27, 2022 at 04:20:48PM +0600, - - wrote:
> ptp4l[402.740]: timed out while polling for tx timestamp
> ptp4l[402.740]: increasing tx_timestamp_timeout may correct this issue, but
Did you try increasing tx_timestamp_timeout ?
Thanks,
Richard
___
