On Wed, Jul 13, 2022 at 01:28:18AM +, joy_bhattacha...@arcadyan.com wrote:
> Even under the erroneous presumption that what you claim is correct,
Sorry, I am going to ignore you now.
As I said before, linuxptp ignores the control field, and so the
control field difference, zero vs five, is
On Wed, Jul 13, 2022 at 01:28:18AM +, joy_bhattacha...@arcadyan.com wrote:
> Attached PDF document " IEEE Standard for a Precision Clock
> Synchronization Protocol for Networked Measurement and Control
> Systems" from the " IEEE Instrumentation and Measurement Society"
> for your perusal.
On Tue, Jul 12, 2022 at 02:29:22AM +, joy_bhattacha...@arcadyan.com wrote:
> Therefore, there is no such thing as an 'incorrect value' for the control
> field as long as it is PTP V2.
You are mistaken. Please read IEEE 1588. You will find the following
specification:
13.3.2.10
On Mon, Jul 11, 2022 at 01:42:14AM +, joy_bhattacha...@arcadyan.com wrote:
> Slave is running ptp4l, GM is running custom time-sync solution
> (G8275.1). GM has already been tested with Calnex Paragon Neo and
> has passed the test so compliance with 1588 should not be the issue
> here.
How
On Fri, Jul 08, 2022 at 01:08:04AM +, joy_bhattacha...@arcadyan.com wrote:
> Hi,
>
> Using a binary built on v3.1, I'm trying to synchronize a Slave
> device with a Grandmaster but the Slave does not accept the
> Grandmaster as Master. It does not lock or synchronize either.
Which node is
On Thu, Jul 07, 2022 at 01:52:32AM +, Gao Meitao（高玫涛） wrote:
> Does ptp4l has a feather that only adjust time offset not freq ?
Yes, see the man page.
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
On Wed, Jul 06, 2022 at 06:07:40AM +, Gao Meitao（高玫涛） wrote:
> Hi all:
>
>I try to test ptp as slave for my evb borad, and found that it seem
> not work properly , as you can see from below logs
> First run, it seem be out of control by ptp, after run again, thing
> seem work
On Wed, Jun 29, 2022 at 12:29:16PM +0200, Miroslav Lichvar wrote:
> If I understand it correctly, it's about exchanging hidden information
> for controlling botnets etc. In PTP it could be in the timestamps,
> sequence numbers and other fields in the header, or TLVs. It cannot be
> prevented.
On Tue, Jun 28, 2022 at 03:21:02PM +0200, Martin Pecka wrote:
> - according to one user, for P2P to work over this switch, it might be
> required to connect a host CPU to the MII port. I don't quite understand why
> it should be a different port that would be creating the PDelay messages on
>
On Tue, Jun 28, 2022 at 01:30:32PM +, Deshpande, Yash wrote:
> I would like to ask the second part of the question once again. I
> dont wish to synchronize the two ports. I know that their relative
> offset is constant as they are running on the same oscillator. This
> is also reported by the
On Tue, Jun 21, 2022 at 11:12:45AM +0800, 这个 不太冷 wrote:
> The parameter “duration” represent the subscribe client whether in the
> validity period?
> If duration time is expired ptpt4l will remove it and the client need to
> re-subscribe it?
Yes, duration is given in seconds.
> Another
On Mon, Jun 20, 2022 at 10:32:55PM +0800, 这个 不太冷 wrote:
> Thanks very much.
> I also want to knowhow can I subscribe to receive PORT_DATA_SET and
> TIME_STATUS_NP via the push method?
> Could you help me some example and guidance? Thanks a lot.
pmc is your friend...
root@ctm:~# pmc -b0 -u
On Mon, Jun 20, 2022 at 11:59:02AM +0800, 这个 不太冷 wrote:
> Thanks for your quick reply.
> Q1.I have known the monitor socket should be created by the mointor, like PMC.
>
>
> ptp4l --slave_event_monitor=/tmp/foo
> pmc -u -i /tmp/foo
When I run those ^^^ commands, I see:
On Mon, Jun 20, 2022 at 12:23:02AM +0800, 这个 不太冷 via Linuxptp-users wrote:
> Q1. How do I use the this configuration item “slave_event_monitor”？
> But I can not understand how it communicate with the
> ptp4l, I do not see the code about ptp4l send message to the
> monitor. According to my
On Fri, Jun 10, 2022 at 06:21:38AM +, Kirchhoff, Philip wrote:
> Actually, it is not PTP over PRP, but PTP over two networks, on which PRP is
> also running.
> However, as you can see, the PRP driver assigns an identical MAC
> address for both network interfaces. We wondered if this would be
On Thu, Jun 09, 2022 at 05:14:20AM +, Wengler, Alexander wrote:
> So the first question is: is it possible to use ptp in such a configuration
> at all?
PTP über PRP? Das ist vielleicht Neuland...
Gruß,
Richard
___
Linuxptp-users mailing list
On Fri, Jun 03, 2022 at 12:40:15PM +, Barbaros Kazan via Linuxptp-users
wrote:
> ptp4l[2698.347]: selected local clock aabbcc.fffe.ddee27 as best master
> ptp4l[2699.143]: port 1: unicast request timeout
> ptp4l[2699.144]: port 1: time to renew unicast subscriptions
> ptp4l[2699.144]: port 1:
Abby,
On Mon, May 23, 2022 at 01:27:29PM -0500, Abby Marsh wrote:
> I'm a researcher working on a project that's confirmed a viable covert
> channel in the current version of linuxptp. I'd like to report this; is it
> best to do so here, or on another list?
What is a "viable covert channel", and
Dear list,
I put together a little guide on how to use the hardware signals on
the Intel i210 Ethernet controller cards.
http://linuxptp.sourceforge.net/i210-rework/i210-rework.html
Enjoy!
Thanks,
Richard
___
Linuxptp-users mailing list
On Mon, Apr 18, 2022 at 08:24:17PM +, Cole Walker wrote:
> Would you be open to me proposing a fix for this in ts2phc or do you think
> this issue should be addressed by adjusting the driver priority?
After a PPS event, the ts2phc program needs to determine the ToD of
that event. It does so
On Tue, Apr 12, 2022 at 02:35:17PM -0700, Richard Cochran wrote:
> There are patches floating around that convert the tty stuff into a
> proper kthread that can be given sched_fifo priority. You'll have to
> port those or do something similar yourself.
Once upon a time, there was a lo
On Tue, Apr 12, 2022 at 08:22:26PM +, Cole Walker wrote:
> Given that I am running on a real-time system, do you think there is any
> chance that this could be contributing? How would I go about testing this?
A busy preempt_rt system can easily delay background work like uart
for a LONG
On Wed, Apr 06, 2022 at 10:15:34AM +0530, Sunil Kumar wrote:
> I would like to know what is the timeline for release of Linux PTP stack
> which adheres/supports to IEEE802.1AS-2020
No timeline and no plans to support that.
Thanks,
Richard
___
On Mon, Apr 04, 2022 at 01:25:19PM -0400, PATRICK KEROULAS wrote:
> This looks simple indeed. Though, I'm not sure about the rationale
> for exposing 2 sockets. Is the intention to accommodate both trusted
> (GET+SET) and untrusted (GET) applications?
Yes, and that is already merged. The new
On Thu, Mar 31, 2022 at 02:56:28PM -0400, PATRICK KEROULAS wrote:
> Hello,
> What happened to this feature?
> https://www.mail-archive.com/linuxptp-devel@lists.sourceforge.net/msg05061.html
Would it be of practical value to you?
If so, I'll gladly put it in the queue...
Thanks,
Richard
On Thu, Mar 31, 2022 at 10:03:10AM +0200, Martin Pecka wrote:
>
> > On Wed, Mar 30, 2022 at 04:57:14PM +0200, Martin Pecka wrote:
> > > That works, but it loses the beauty of having a "public" RO port and a
> > > root-only RW port.
> > You can make two global options, one for each flavor.
>
>
On Wed, Mar 30, 2022 at 04:57:14PM +0200, Martin Pecka wrote:
> That works, but it loses the beauty of having a "public" RO port and a
> root-only RW port.
You can make two global options, one for each flavor.
Thanks,
Richard
___
Linuxptp-users
On Wed, Mar 30, 2022 at 01:10:23PM +0200, Martin Pecka wrote:
>
> > Right, the config sections are for network interfaces only.
> >
> > > Is there a way to configure the RO socket without having this side-effect?
> > What are you trying to accomplish?
>
> That goes along with my proposal (on
On Tue, Mar 29, 2022 at 09:29:06PM +0200, Martin Pecka wrote:
> I added the following to my config to set some properties of the read-only
> UDS port:
>
> [/var/run/ptp4lro]
> # options
>
> However, when I start ptp4l, it creates a superfluous socket that brings in
> many problems:
Right, the
On Mon, Mar 28, 2022 at 12:05:08PM +0530, Raj wrote:
> Does anyone have any suggestions for the below query !.
Don't use masteronly.
Just set the priority1/2 fields of the three units appropriately.
For example:
Unit priority1
---
GM-1 126
GM-2 127
OC128
Thanks,
Richard
On Sat, Mar 26, 2022 at 10:25:43AM +, Federico Murciano wrote:
> Do you have concrete instrucctions that I could try in master and
> slave in order to correct this? Do you think it is possible that due
> to the setups where I just plug in the device to electricity and
> other setup that is
On Tue, Mar 15, 2022 at 04:06:31PM +0100, Marco Davids (SIDN) via
Linuxptp-users wrote:
> I have a setup with an interface being a PTP client (HW timestamping, a nice
> Meinberg GM and such) and phc2sys supplying time from it to another
> interface's PHC in the same server.
>
> Is there anything
On Tue, Mar 15, 2022 at 06:11:26AM -0700, Axel Simon wrote:
> Is there something I'm missing here? Is there any documentation or
> recommendation regarding the design of a high-accuracy linuxptp-based system?
No, you stated the facts well enough.
If you want to make a single port GM, then you
On Sun, Mar 13, 2022 at 07:01:28PM +0100, Andre Puschmann wrote:
> Are you using the HW, i.e. the TSSDP register or configure the SDP as input
> and update the value in the ISR?
>
> For example, taking a PPS output (in my case 5V), level shifted to 3.3 and
> feeding it to, e.g. SDP3, of the
On Fri, Mar 11, 2022 at 06:30:49AM -0800, Axel Simon wrote:
> Sorry, I checked again and I stand corrected. We saw some offsets
> before we were able to monitor our system properly and it's still in
> my head that we can't get better than 2µs of noise. We are
> synchronizing the PTP clocks
On Thu, Mar 10, 2022 at 09:47:21PM +0100, Andre Puschmann wrote:
> > We found that ptp4l can only synchronize NIC clocks (e.g. i210) to an
> > accuracy of ~2µs due to the latency PCIe transactions. If you want better
> > synchronization, ptp4l with off-the-shelf NICs is not a solution.
FUD
On Tue, Feb 22, 2022 at 01:50:39PM -0600, David Jedynak wrote:
> For use case orientation: Embedded system installed on a remote (no
> internet) infrastructure, receives GPS w/PPS, sets time from power-up
> (e.g. 1970) and acts as PTP grandmaster for the entire local
> infrastructure. Hardware
On Tue, Mar 08, 2022 at 12:38:46PM +0100, Andre Puschmann wrote:
> Dear all,
>
> we are trying to build a PTP grandmaster with linuxptp to provide sync
> signals to telco equipment.
>
> So far we've only used the internal oscillators of the NIC for a bunch of
> cards, Intel based and also
On Tue, Mar 08, 2022 at 06:38:50PM +0530, Raj wrote:
> We used "clock_settime(clockid_t clockid, const struct timespec *tp)" to
> update the ptp clock in every second based on dsp time.
That is surely the wrong way.
> We have also tried to adjust the ptp clock frequency and step using
>
On Fri, Mar 04, 2022 at 10:35:05PM +0530, Aditya Venu via Linuxptp-users wrote:
> I run another dpdk based application. The dpdk application routes all the
> data to *queue number 3* of my same HW. once I run this application, ptp4l
> stops sending sync follow_up and announce(I am checking in
On Mon, Feb 28, 2022 at 04:17:26PM -0600, David Jedynak wrote:
> Was hoping to see some responses on these questions. Anything?
You are asking the right questions.
Kinda busy right now, so no time for adequate response.
Sorry,
Richard
___
On Fri, Feb 25, 2022 at 09:18:14AM +0100, Nils Fürste wrote:
> I attached some more detailed info. Any ideas what it can be or how I can
> debug this problem? Any advice is appreciated! Thanks in advance!
Look at the three call sites of:
port_dispatch(p, EV_SYNCHRONIZATION_FAULT, 0);
On Fri, Feb 25, 2022 at 08:36:06AM +0100, Marco Davids (SIDN) via
Linuxptp-users wrote:
> I created a unicast setup. It was an experiment to verify if I could make my
> PTP-service more resilient against 'rogue' masters on the same VLAN that
> (falsy) claim to be the best master.
A back actor
On Mon, Feb 21, 2022 at 06:53:09AM -0800, Richard Cochran wrote:
> 1. Ask the vendor to fix their switch FW.
>
> 2. Don't re-start the switch when snooping is enabled.
>
> 3. Don't make snooping a persistent setting, but rather enable it via
>scripting after restarting
On Sun, Feb 20, 2022 at 05:52:17PM +0100, Jakub Raczyński wrote:
> You misunderstand. I am gonna repeat myself:
> "So basically ptp4l will only work on switch with IGMP snooping if it has
> been started after the switch, while any restart of switch will cause all PTP
> traffic to be blocked
On Sat, Feb 19, 2022 at 12:05:29AM +0100, Jakub Raczyński wrote:
> I cannot say on which precisely, would need more studying of Linux kernel.
> Seems that newer version of 4.9 has this implemented.
> Basically, problem originates from this
>
On Fri, Feb 18, 2022 at 11:05:05PM +, Keller, Jacob E wrote:
> As far as I can tell, the default settings since a long time is to
> re-transmit an unsolicited join request with a random interval
> between 0 and 10 seconds as of the 2.6 git history. I couldn't find
> any data from before that.
On Fri, Feb 18, 2022 at 10:08:20AM +0100, Jakub Raczyński wrote:
> I disagree. As far as I can tell, IGMP resending is done by kernel
> from version 4.9 upon notification. So basically, ptp4l will not
> work with any switch using IGMP in any way on older kernels.
What do you mean?
Are kernels
On Fri, Feb 18, 2022 at 05:42:57PM +, Keller, Jacob E wrote:
> (in fact, there is no real interface to do this in the socket
> options.. There's simply a join and leave group option, but no
> mention of needing to re-join periodically or what attempting to
> join an already joined group would
On Thu, Feb 17, 2022 at 05:26:15PM +0100, Janusz Użycki wrote:
> From our observations for IPv4 (L4) E2E it still applies to ptp4l. On Cisco
> and Netgear switches (even L3 set as L2 switch) IGMP snooping must be
> disabled for proper PTP multicast work.
So their "IGMP snooping" feature is
On Thu, Feb 17, 2022 at 11:29:03PM +, Keller, Jacob E wrote:
> I think we at least need to re-send these when the link changes,
We do, because the link down/up causes the transport to be closed and
opened again.
> though
> we perhaps were thinking that the kernel does this for us? Maybe
On Mon, Feb 07, 2022 at 04:26:45PM +, ramesh t wrote:
> hi Richard,
>
> > Feb 7 09:35:20 ptp4l: [610991.536] port 2: send sync failed
> > Feb 7 09:35:20 ptp4l: [610991.536] port 2: MASTER to FAULTY on
> > FAULT_DETECTED (FT_UNSPECIFIED)
> > Feb 7 09:35:20 ptp4l: [610991.557] port 2: link
On Mon, Feb 07, 2022 at 10:47:51AM +, ramesh t wrote:
> Did few more iterations of testing (ptp4l in BC mode) by resetting TestUnit.
> Still observing "send sync error" with txtimeout of 100ms.
>
> Question:
> 1) ptp4l is running in BC mode providing clock to other connected TestUnits
> and
On Fri, Jan 28, 2022 at 05:18:07PM +0800, 藍彥凱 wrote:
> I am learning to use linuxptp
>
> I would like to try changing the sync time like 1 second to 2 seconds to 4
> seconds ..
>
> I changed logAnnounceInterval 2in configs/default.cfg
> but nothing changed
You need to specify your new
On Mon, Jan 17, 2022 at 08:25:06AM +, ramesh t wrote:
> Please suggest.
1. Make sure your ptp4l has these five patches:
a082bcd clockcheck: Increase minimum interval.
6df8425 port: Don't renew raw transport.
e117e37 port: Don't check timestamps from non-slave ports.
262a49b
On Thu, Jan 13, 2022 at 09:44:50AM +0100, Peter Bergin wrote:
> Backporting relevant stuff of this patch to my 5.4 kernel solved the padding
> problem.
Cool. Glad it was a driver issue and not a bug in silicon!
Cheers,
Richard
___
Linuxptp-users
On Wed, Jan 12, 2022 at 03:57:55PM +0100, Peter Bergin wrote:
> I have a setup with TI processor using the cpsw driver from Linux mainline,
> kernel version 5.4. I'm using IEEE 802.3 network transport and sending PTP
> frames on Ethernet. When sending SYNC, FOLLOW_UP and DELAY_REQ that has a
>
On Wed, Jan 12, 2022 at 03:12:15PM +0100, Martin Pecka wrote:
> So from the setup point of view, everything seems correct to me.
Yes sounds like it.
You said this is an Nvidia vendor kernel on the jetson?
I would try a mainline kernel without their hacks.
Thanks,
Richard
On Tue, Jan 11, 2022 at 04:57:25PM +0100, Martin Pecka wrote:
> So it seems the card timestamps FOLLOW_UP and DELAY_RESP packets, but does
> not timestamp SYNC packets. Why could this be? Can it somehow mismatch SYNC
> and FOLLOW_UP messages in the chip and stamp the wrong one? (I think
>
On Fri, Jan 07, 2022 at 07:32:39AM +, ramesh t wrote:
> ptp4l: [325744.430] clockcheck: clock jumped forward or running faster than
> expected!
> ptp4l: [325744.430] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
See this? ^
> Please suggest.
I
On Thu, Jan 06, 2022 at 05:24:48PM +0100, Martin Pecka wrote:
> Is there any other way to test the timestamping? E.g. a short C snippet to
> compile and figure out if the stamps are coming if requested?
In the linux kernel source tree:
tools/testing/selftests/net/timestamping.c
HTH,
On Wed, Jan 05, 2022 at 07:34:07PM +, ramesh t wrote:
> On resetting of the testing unit, observing ptp port state of the
> interface connected to BC/GM going to PS_FAULTY temporarily though
> it shouldn't be impacted due to reset of testing unit.
Why does BC/GM port go to PS_FAULTY? Link
On Wed, Jan 05, 2022 at 07:34:07PM +, ramesh t wrote:
> hi,
>
> Running ptp4l in BC mode, with clock_type set to BC and boundary_clock_jbod
> set to 1. Have connected one NIC port to BC/GM and another NIC port to
> testing unit (TU). Following is the ptp4l command.
>
> ./ptp4l -2 -A -w -i
On Wed, Dec 15, 2021 at 10:32:06PM +0800, 藍彥凱 wrote:
> Sync_Message and Delay_Req Message originTimestamp always 0 (seconds &
> nanoseconds)
This is normal and expected. See IEEE 1588 to understand the meaning
of the message fields.
Thanks,
Richard
On Wed, Dec 15, 2021 at 04:04:30PM +0800, 藍彥凱 wrote:
> Dear Richard
>
> I use wireshark to check ptp packets.
>
> I found that I didn't see Delay_Req Message .
>
> Sync_Message and Delay_Req Message originTimestamp always 0 (seconds &
> nanoseconds)
>
> screenshot can’t seem to be uploaded.
>
On Mon, Dec 13, 2021 at 10:50:56AM +0800, 藍彥凱 wrote:
> Sorry,how should I make sure them?
Wireshark and/or tcpdump are your friends!
Thanks,
Richard
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
On Sun, Dec 12, 2021 at 06:21:10PM +0800, 藍彥凱 wrote:
> Hello, I tested ptp4l on two PC. The master clock display is correct,
> but from the clock display to port 1: LISTENING to UNCALIBRATED on
> RS_SLAVE, there is nothing to do. The master offset is not displayed.
> What is the problem?
The
On Fri, Dec 10, 2021 at 11:29:25AM +0100, Marco Davids (SIDN) via
Linuxptp-users wrote:
> Hi there,
>
> Here's a newcomers question.
>
> I am working out a setup with two master clocks (one GM/leader, one
> slave/follower, depending on what BMCA decides) and two boundary clocks that
> both
On Fri, Dec 10, 2021 at 12:51:10PM +, Kirchhoff, Philip wrote:
> Ok, but do I need to configure anything explicitly for this? How does the Lib
> know that it should act as GM.
You can run the DUT with --clientOnly (aka -s)
Or you can bump the --priority1 or --priority2 on the GM.
Thanks,
On Thu, Dec 09, 2021 at 09:08:12AM +, Kirchhoff, Philip wrote:
> I may have expressed myself in a misleading way. I do not want to simulate a
> clock network.
> I have an embedded device that should synchronize its time via PTP. Since I
> don't have a HW clock available, I want my PC (or
On Wed, Dec 08, 2021 at 07:32:10AM +, Kirchhoff, Philip wrote:
> Hi,
>
> I was wondering if it is possible with linuxptp to simulate a PTP masterclock
> on a PC. I realize that I can't achieve reasonable accuracy with it. It is
> only about the simulation of the protocol.
Sure, you can run
On Tue, Dec 07, 2021 at 11:27:19AM +0100, Maximilian Kirchner wrote:
> Hello,
>
> I hope someone may be able to help me here. I have trouble syncing two Linux
> systems using PTP.
>
> Setup:
>
> Two PCBs with a BegleCore module and a DP83640 PHY are connected with each
> other over Ethernet.
On Tue, Dec 07, 2021 at 06:30:32AM -0500, Dan Geer wrote:
> So, I'm into the phyter device driver... What's the next step?
The phyter generates special frames that carry the time stamps. These
frames are delivered to the host. Because the frames appear to be PTP
frames, the networking stack
On Mon, Dec 06, 2021 at 07:27:54AM -0500, Dan Geer wrote:
> I would like to start with my thanks for the support of the Linux PTP
> Project. The tools are a great success, and keep getting better!
>
> I'm developing a custom SBC that works perfectly approximately 90% of the
> time. However,
On Sat, Dec 04, 2021 at 05:07:07PM +0100, Arfaoui Mahdi wrote:
> Hi,
> Can anyone help me please.
As you guessed, it is likely a buggy driver in your A7.
Ask your vendor to fix their driver.
Good luck,
Richard
___
Linuxptp-users mailing list
On Sat, Dec 04, 2021 at 02:53:09PM +0200, Vladimir Oltean wrote:
> Would this even be PTP, as in, IEEE 1588?
No, it wouldn't be PTP.
The Wifi standards do specifiy a precise synchronization method, but
AFAICT no radio firmware implements it. It would also need work in
the 802.11 layer in Linux.
On Fri, Dec 03, 2021 at 12:21:34PM +0100, hesolium wrote:
> Hi Team,
>
> theoretically, having 3 radio transceivers, it is possible to synchronize
> time with an accuracy of several dozen microseconds without using TX
> timestamps.
> One can take advantage of the fact that the reception of the
On Mon, Nov 22, 2021 at 10:13:30AM +, Mikael Arvids wrote:
> Could you explain what I would use the TIME_STATUS_NP.ingress_time for when
> monitoring the end station?
For example:
- If ingress time does not increase: lost frames or lost GM
- If delta(ingress time) unreasonable: broken GM
On Thu, Nov 18, 2021 at 08:50:36AM +, Mikael Arvids via Linuxptp-users
wrote:
>
> 1. Is this the expected behavior when using the automotive profile
> (especially the inhibit_announce option set to true)?
Yes, looks about right to me. Remember, without Announce messages,
the GM
On Sun, Nov 07, 2021 at 04:22:52PM +0200, Vladimir Oltean wrote:
> On Sun, Nov 07, 2021 at 04:19:55PM +0200, Vladimir Oltean wrote:
> > On Sun, Nov 07, 2021 at 05:55:43AM -0800, Richard Cochran wrote:
> > > On Sun, Nov 07, 2021 at 01:32:59PM +0200, Vladimir Oltean wrote
On Sun, Nov 07, 2021 at 01:32:59PM +0200, Vladimir Oltean wrote:
> 1. ptp4l in the role of a GM appears to listen for GRANDMASTER_SETTINGS_NP
>PTP management messages on the local r/w UDS socket and that's how it
>updates its ANNOUNCE message contents. Who is supposed to construct and
>
On Wed, Nov 03, 2021 at 07:44:06AM +, Christian Leeb wrote:
> Yes it works. Also master failover. Basically we get an OC with multiple
> ports.
Great. How about a patch to demote pr_warning to pr_debug?
Thanks,
Richard
___
Linuxptp-users
On Tue, Nov 02, 2021 at 03:32:04PM +, ramesh t wrote:
> hi,
>
> Any suggestion for the below mentioned issue? Please let me know.
Looks like a HW and/or driver issue.
I would start by validating the HW/driver. For example, a long term test of
phc_ctl eth0 get
HTH,
Richard
On Tue, Oct 12, 2021 at 09:47:21PM +0200, Peter Bergin wrote:
> Hi,
>
> I'm currently working on a network product using gPTP configuration for PTP
> sync. The device shall be a AVB endpoint handling audio and according to
> Avnu specifications all endpoint shall be capable of being master on the
On Mon, Oct 04, 2021 at 03:12:57PM -0300, Lucas Gonçalves Martins via
Linuxptp-users wrote:
> Ok, the problem is with the master branch version. Checking out to v3.1.1
> makes it work again.
That is very strange. Can you do "git bisect" between v3.1.1 and
master to identify the bad commit?
On Thu, Aug 19, 2021 at 07:03:36AM +, ramesh t via Linuxptp-devel wrote:
> hi,
>
> We are planning to upgrade ptp4l to latest version (3.1.1), had few questions
>
> 1) From which release onwards of ptp4l IEEE 1588-2019 is supported?
all published versions from v1 onward
> 2) Is IEEE
On Tue, Sep 28, 2021 at 08:09:48PM +0800, 廖書華 wrote:
> I'm curious about is that for the HW timestamping, *"**all
> (HWTSTAMP_FILTER_ALL)" *is the mandatory option that the NICs need to
> support ?
No, it is not mandatory. If you have HWTSTAMP_FILTER_PTP_V2_EVENT
that should work.
I don't know
On Wed, Aug 18, 2021 at 12:14:19PM +, Chang, Benjamin wrote:
> I just wanted to follow up and see if there was any resource that
> pointed out what each Parameter definition was for the PMC
> management IDs. The resource I found only pointed out a handful.
The standardized messages exactly
On Sat, Aug 14, 2021 at 06:18:25PM +, ramesh t via Linuxptp-devel wrote:
> hi,
>
> Debugging a ptp4l issue, observed its getting blocked while writing into
> /var/log/messages file. Blocking of ptp4l can vary from few minutes to
> forever.
That is too bad. Your system is seriously FUBAR.
On Thu, Aug 12, 2021 at 01:10:24PM +, Chang, Benjamin via Linuxptp-users
wrote:
> Hello,
>
> I am trying to understand the Management ID parameters. I can't seem to find
> any definitions for them except for the couple listed here (stepsRemoved,
> offsetFromMaster, etc.)
>
On Wed, Aug 11, 2021 at 05:13:45PM +0200, JP wrote:
> I'd like to be able to use both domains as if they were Linux clocks like
> CLOCK_REALTIME. That is, I want the functionality of clock_gettime, but
> also other system calls like timer, timerfd, nanosleep, hrtimer etc.
The PHCs support
On Tue, Aug 10, 2021 at 05:47:44PM +0200, JP wrote:
> I guess I will only be able to make use of one domain "the standard way"
> (i.e. use phc2sys to synchronize CLOCK_REALTIME, and then use standard Linux
> clock system calls with CLOCK_REALTIME).
right.
> Is there a best practice when it comes
On Thu, Aug 05, 2021 at 03:49:15PM +0200, JP wrote:
> Is it possible to do PTP on multiple domains, at the same time, using ptp4l?
yes
> I assume I'd run a separate instance for each domain, both using the same
> interface, and explicitly tell each instance which PHC to synchronise
> to/from?
On Tue, Aug 03, 2021 at 12:47:08PM +, ramesh t via Linuxptp-users wrote:
> Please suggest, if this is supported or not.
Your question doesn't make sense to me. The BC implementation
operates exactly as described in the 1588 standard.
What more do you need to know?
Thanks,
Richard
On Thu, Jul 29, 2021 at 12:15:05PM +0530, Karthick Gunasekaran via
Linuxptp-users wrote:
> Hi Experts,
>
> Is there anyway to make ptp4l work in ptpv1 mode so that i can test the
> compatibilty with ptpv2 version?
> Kindly provide pointers for the same if this is possible.
Sorry, but ptp4l is
On Wed, Jul 07, 2021 at 03:02:39PM +0300, Дмитрий Кандыбка wrote:
> I've met with ptp4l timesync issue. Master send SYNC packets without
> timestamp and slave doesn't handle this case when twoStepFlag set to 1. The
> IEEE 1588 standard says that SYNC messages in 2-step ptp don't need
> timestamp.
Dear list,
Now that the embargo period has expired, I published fixes for:
CVE-2021-3570 linuxptp: missing length check of forwarded messages
CVE-2021-3571 linuxptp: wrong length of one-step follow-up in transparent
clock
The fixes have been published to SourceForge and to GitHub:
On Thu, Jun 24, 2021 at 05:19:35PM +, Chang, Benjamin via Linuxptp-users
wrote:
> I'm trying to setup my RHEL computer to sync to a NTP server with PTP
> abilities.
What on Earth is that?
NTP, PTP, not the same thing!
Thanks,
Richard
___
On Thu, Jun 24, 2021 at 10:31:56AM +0300, Joseph Matan wrote:
> I'm familiar with NICs that support HW timestamps for PTP. But I want to
> work with an external NIC that I can just plug in to my laptop with USB
> connection (and works with Linux).
Don't think there is anything out there. Sounds
On Thu, Jun 10, 2021 at 09:59:46PM +, Cole Walker wrote:
> host1:~# cat /etc/centos-release
> CentOS Linux release 7.6.1810 (Core)
>
> host1:~# uname -r
> 3.10.0-1160.15.2.rt56.1152.el7.tis.4.x86_64
Pretty old kernel, ...
> host1:~# ethtool -i ens787f3
> driver: i40e
> version: 2.14.13
101 - 200 of 655 matches
Mail list logo
