and the I219-LM rev. The working 219 chip reports rev
10 where the one that reports an error is rev 11. It seems like a
driver would be the most likely problem. A quick look at the Intel
website indicates that the e1000e drivers have changed to a kernel-only
support model.
Jason
On 2023-06
1968528885 freq +2399 +/- 0
delay -41795176 +/- 7986159
ptp4l[1070.939]: port 1 (eno1): SLAVE to UNCALIBRATED on
SYNCHRONIZATION_FAULT
Thanks,
Jason
On 2023-06-20 00:41, egg car wrote:
Hi,
Can you provide more info to reproduce the problem? E.g, your
configuration, the network
sults.
Any thoughts as to why the errors would continue to grow on the one
interface and not the other?
Thanks,
Jason
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
e a way to reduce it?
Thanks,
Jason
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Hi Martin,
This is exactly the info I needed to make the pmc call work!
Thanks,
Jason
On 10/3/2022 9:52 AM, Martin Pecka wrote:
Hi Jason, that's what the readonly UDS socket is for. With default
configuration and PTP4L master branch, this is how you can query
TIME_STATUS_NP without
27;ve seen some of the messages saying a patch was applied to PMC to
allow running without elevated privileges. Has this been implemented as
of yet? If so, how could I find the patch to build the project and
configure it?
Thanks,
Jason
___
Linu
So it would seem that while that dummy entry stops the " port 1: received SYNC
without timestamp" messages, it doesn't do much good afterwards.
-Original Message-
From: Miroslav Lichvar
Sent: Monday, November 8, 2021 01:09
To: Brooks, Jason
Cc: linuxptp-users@lists
, November 5, 2021 05:53
To: Brooks, Jason ;
linuxptp-users@lists.sourceforge.net
Subject: [External]Re: [Linuxptp-users] running ptp4l under vmware
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know t
1. And when using this system as an ntp source on another system it shows as
a stratum 2 system. Shouldn't this be a stratum 1, given the ptp0 clock?
2. A lot of messages in /var/log/messages:
* [44:enp0s25] port 1: received SYNC without timestamp
Thank you for your time!
0080ea.fffe.842b60
pmc -u -b 0 -f /etc/ptp4l.conf "GET current_data_set"
sending: GET CURRENT_DATA_SET
005056.fffe.be1c0f-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET
stepsRemoved 1
offsetFromMaster 0.0
meanPathDelay0.0
expected amount of time. I do have the step adjust enabled at startup
though.
I wonder if there is any way to delay the start of ptp4l synchronization
just long enough to allow all time information from the master to be
received by the NIC?
Thanks,
Jason
On 1/21/2021 5:40 PM, Jacob
nt at this point. A few moments later the correct time
will be detected on its own and then ptp4l will slew to the correct time
taking a few minutes or more. Is there a configuration setting that may
handle this disable/enable network jump scenario?
Thanks,
12 matches
Mail list logo