[Linuxptp-users] The List Has Moved
Dear LinuxPTP Users, New posts to this list has been disabled. If you want to continue to participate on the mailing lists, please subscribe to the new list at the Network Time Foundation. https://lists.nwtime.org/sympa/info/linuxptp-users Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] phc2sys always creates a -37000000011ns between system clock and phc
On Wed, Nov 29, 2023 at 10:27:54PM +0800, paulzhn via Linuxptp-users wrote: > I'm wondering why the offset exists. - Linux system clock is in UTC timescale. - PHC is in TAI timescale. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Slave takes VERY long to sync to Master using Automotive profile
On Mon, Nov 27, 2023 at 08:18:54AM +, Hopf, Daniel wrote: > Thanks Richard, > > Then maybe I misunderstood the output of ptp4l. > I am specifically confused about the lines indicating "master > offset" (which in my log started popping up after ~80 seconds, but > sometimes don't show up even after 15 minutes) - what changed in the > state of the synchronization that the logs suddenly changed from > reporting "rms ... max ... freq ..." lines to reporting "master > offset"? That is only the reporting of the offset. The offset reporting is rate limited by: summary_interval The time interval in which are printed summary statistics of the clock. It is specified as a power of two in seconds. The statis‐ tics include offset root mean square (RMS), maximum absolute offset, frequency offset mean and standard deviation, and path delay mean and standard deviation. The units are nanoseconds and parts per billion (ppb). If there is only one clock update in the interval, the sample will be printed instead of the statis‐ tics. The messages are printed at the LOG_INFO level. The de‐ fault is 0 (1 second). So when the Sync message period changes, the reporting format also changes. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Slave takes VERY long to sync to Master using Automotive profile
On Fri, Nov 24, 2023 at 02:59:25PM +, Hopf, Daniel wrote: > Following are the logs of a try where they synced up after ~80 seconds. > Here's the SLAVE log (I increased neighborPropDelayThresh from 800 to 8000 > and set tx_timestamp_timeout to 100 in my slave config file): > -(~/linuxptp-latest:$)-> sudo ./ptp4l -f ./configs/automotive-slave-DH.cfg -i > eth0 -m -l 7 > ptp4l[26253.262]: rms 25054 max 50349 <-- within 50 usec > ptp4l[26254.264]: rms 2904 max 3109 3 usec > ptp4l[26255.267]: rms 1722 max 2380 2 usec > ptp4l[26256.271]: rms 521 max 931 under 1 usec Why do you say it took 80 seconds? Log suggests client synchronized to within 50 microseconds after one second. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] LinuxPTP Software Timestamping only - PHC Concept
On Mon, Nov 20, 2023 at 12:54:03PM -0500, Jean-Sebastien Stoezel wrote: > When it comes to software timestamping, what is the PHC equivalent on the > device? Is it a hardware timer? Or is it purely software? ethtool is > reporting no PHC, and so I'd assume the PHC is some sort of software timer > somewhere in the kernel. With software timestamping, ptp4l adjusts the Linux system clock (CLOCK_REALTIME) directly. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Max number of PTP clients on a BC port ?
On Mon, Nov 13, 2023 at 06:41:49AM +0100, Surya Arby wrote: > Thanks for your quick reply! > > Would you be ok to tell me which commercial switches are very slow to > process ptp in the transparent mode ? I've made it my policy not to shame bad products, even though there are tons of them on the market. My advice is, try before you buy! > Our boundary clocks in each technical room will be based on mellanox > hardware (but not mellanox branded, it's OEM provided by our partner) with > one single Netgear 4350 attached to it, with a few devices connected to it > audio devices, probably less than 20 clients) ptp4l will easily scale to 20 clients. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Max number of PTP clients on a BC port ?
On Sun, Nov 12, 2023 at 09:57:56PM +0100, Surya Arby wrote: > we are considering the use of linux-based switches (hardware timestamping > provided in the ASIC, linuxptp will be used), the GM will be connected to > the switch, and all ports will be BC, In PTP land, switches and Boundary Clocks are not the same (as you probably already know, but you seem to conflate the two in this mail) > I was wondering if there was any known > limit to the number of PTP clients behind a BC port in the code ? (an > intermediate PTP-transparent switch will be used to connect several clients > to the BC port) There are no hard coded limits in the code. Because the program is single threaded, there is a practical upper limit somewhere. BC mode is essentially stateless WRT the number of clients, so that memory usage is not a concern. The only limitation is the rate at which Delay Requests can be handled, as the responses are serialized by the single threaded ptp4l program. TC needs a bit of state for each message needing residence time correction, and so memory use will increase with the number of PTP clients. Also, when ptp4l runs in TC mode, the frame residence time will likely be in the single digit millisecond range. Reducing that might be challenging, but maybe nobody cares about the residence time duration? (FWIW I've seen commercial Transparent Switches where the residence time is in the double digit millisecond range.) HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] The LinuxPTP-Users mailing list has moved
On Wed, Nov 08, 2023 at 03:28:34PM -0800, Steve Sobol NTF wrote: > The mailing lists and archives of the LinuxPTP Project are now fully > hosted at Network Time Foundation. Direct posting to the Sourceforge > lists has been disabled. Small correction: Posting to the SF lists has not yet been disabled. I will disable them on December 6, 2023 (one day after the next release). If you want to continue to participate on the mailing lists, please subscribe to the new lists at the NTF. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Linuxptp - Supported Hardware
On Mon, Sep 25, 2023 at 02:36:35PM +0100, Fernando Gomes wrote: > Is there a list of hardware that can be used with linuxptp to do > timestamping at the hardware level (on PHY or on MAC)? There are some phys > that support it, like the Vitesse / Microchip, etc., but is there a > compatibility list available? I used to maintain a list of hardware, but I gave that up years ago when the number of products became too large. Nowadays most new MACs have PTP support. The easiest way to find out your MAC's capabilities is: ethtool -T eth0 For PHYs, the main issue is that the Linux networking stack doesn't treat MACs and PHYs equally. If you really need to use a PTP PHY, then you will likely have to configure and even patch your kernel specifically for your hardware. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Fwd: First delay request message on GM failure
On Tue, Sep 05, 2023 at 04:45:14AM +0530, Karthick Gunasekaran via Linuxptp-users wrote: > Kindly let me know, if this waiting for 3 announce packets to send first > delay request can be modified (or) this is as per standard and cannot be > modified. This is specified in IEEE 1588. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Multiple interfaces with different PTP implementations
On Fri, Aug 11, 2023 at 12:32:24PM -0600, John Koch via Linuxptp-users wrote: > I was wondering what the best way to configure ptp4l and phc2sys in the > following configuration would be. > > There is a 1588 IPv4 PTP master present on the network. My computer has > several NICs which have PTP hardware support, one of them is plugged into > the network with the 1588 IPv4 master. I also have multiple devices which > are 802.1AS automotive slaves that I want to synchronize with the rest of > the devices on the 1588 network. Currently I have connected each of the > 802.1AS automotive slaves to an individual NIC on my computer and run an > instance of ptp4l and phc2sys for each slave. > > Is there a better way of doing this? If so could someone provide some > guidance? You can run: - one ptp4l instance as a Boundary Clock with 1588 on the slave port and gPTP on the master ports (using a configuration file) - one phc2sys in "automatic" (-a) mode with --boundary_clock_jbod That will make the gPTP clients synchronize to the 1588 IPv4 master. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] 3.1.1 -> 4.0 evolution?
On Mon, Jul 10, 2023 at 05:37:10PM +0200, jmfriedt wrote: > Is there a > rationale for preventing out of the box linuxptp from working with both > PTP 2.0 and 2.1 packets, since changing the constant in the header file > seems to make the protocol operational again? linuxptp works with both ptp v2.0 and v2.1 frames. Your hardware is rejecting v2.1 frames based on a field that is reserved in v2.0 Probably reserved fields should be ignored by PTP clients. That seems to be the expectation from the PTP standards. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] utc_offset: how does it work? Does it work with SW TS?
On Fri, Jun 30, 2023 at 07:58:15AM -0300, Elder Costa wrote: > Em qui., 29 de jun. de 2023 às 01:35, Richard Cochran > escreveu: > > Also, it isn't clear from this how ptp4l(M/HW) on SOM eth_am is configured. > > > > If not in BC mode, then you also should clear the ptpTimescale flag > > for that instance using pmc "set GRANDMASTER_SETTINGS_NP ..." > > I tried BC mode to no avail. I ended up using OC in all interfaces. > After some digging, I had the impression BC would require > specialized hardware, not my case, where the SOM has a Gbit > interface built-in and we had to add another one on the base board. You can run a BC on non-specialized hardware using the ptp4l 'boundary_clock_jbod' option togther with phc2sys "automatic" mode. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] utc_offset: how does it work? Does it work with SW TS?
On Wed, Jun 28, 2023 at 09:35:08PM -0700, Richard Cochran wrote: > On Wed, Jun 28, 2023 at 09:11:44PM -0700, Richard Cochran wrote: > > On Wed, Jun 28, 2023 at 06:37:42PM -0300, Elder Costa wrote: > > > System clock GM+--> System clock SOM --+ System clock AM > > >| | | ^ > > >| | | | > > >| | v | > > >|phc2sys phc2sys | > > >| | | | > > >| | | | > > >v | v | > > >ptp4l(M/SW) ptp4l(S/HW) ptp4l(M/HW) ptp4l > > > (S/SW) > > >| | | | > > >| | | | > > >v | v | > > > enp3s0 <> eth_head eth_am <-> eth0 (SW ts) Also, looking at this network, if it were me, I would let "SOM" be the GM. That would simplify the configuration and improve the synchronization quality. Just my 2 cents. Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] utc_offset: how does it work? Does it work with SW TS?
On Wed, Jun 28, 2023 at 09:11:44PM -0700, Richard Cochran wrote: > On Wed, Jun 28, 2023 at 06:37:42PM -0300, Elder Costa wrote: > > System clock GM+--> System clock SOM --+ System clock AM > >| | | ^ > >| | | | > >| | v | > >|phc2sys phc2sys | > >| | | | > >| | | | > >v | v | > >ptp4l(M/SW) ptp4l(S/HW) ptp4l(M/HW) ptp4l (S/SW) > >| | | | > >| | | | > >v | v | > > enp3s0 <> eth_head eth_am <-> eth0 (SW ts) Also, it isn't clear from this how ptp4l(M/HW) on SOM eth_am is configured. If not in BC mode, then you also should clear the ptpTimescale flag for that instance using pmc "set GRANDMASTER_SETTINGS_NP ..." Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] utc_offset: how does it work? Does it work with SW TS?
On Wed, Jun 28, 2023 at 06:37:42PM -0300, Elder Costa wrote: > I ran a test with the system below. GM and AM running SW timestamp. > The System clocks of the SOM and the AM synchronize with the GM's but > there is an offset of 37s (GM's 37s ahead the other two). I tried > using --utc_offset on the ptp4l instance running in the GM with no > success: no matter the value, the offset stays in 37s. What am I doing > wrong? On the GM, when you run ptp4l with SW time stamping, then it will serve UTC and so ptpTimescale will be 0 (false). IOW, your setup cannot use TAI at all. You need to configure phc2sys on host "SOM" with an UTC/TAI offset of zero using this option: -O [offset]sink-source time offset in seconds (0) So something like: phc2sys -m -q -O0 -S 0.001 -s eth_head phc2sys -m -q -O0 -S 0.001 -c eth_am -s CLOCK_REALTIME HTH, Richard > System clock GM+--> System clock SOM --+ System clock AM >| | | ^ >| | | | >| | v | >|phc2sys phc2sys | >| | | | >| | | | >v | v | >ptp4l(M/SW) ptp4l(S/HW) ptp4l(M/HW) ptp4l (S/SW) >| | | | >| | | | >v | v | > enp3s0 <> eth_head eth_am <-> eth0 (SW ts) > > > ___ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Newly Configured Machine Has Very Large Sys Offset
On Mon, Jun 26, 2023 at 09:42:27AM -0400, engn...@gmail.com wrote: > Created /etc/systemd/system/phc2sys_.service for each of the > above 6 ports I think you want just ONE instance of phc2sys running, not six. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] [Linuxptp-devel] Quarterly release schedule
On Tue, Jun 13, 2023 at 01:01:11PM +0200, Erez wrote: > Just so I am clear on the matter. > I simply suggest taking the same test you run with linuxptp-testsuite. > And run it in a github action. So we can all run it before we send patches. > In addition to the tests you run :-) I run the tests _before_ I push anything to github. Developers can and should run linuxptp-testsuite on their patches before posting to the list. You can add it into your pre-commit git hook, for example. Once a commit lands in github, then it is too late. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] [Linuxptp-devel] Quarterly release schedule
On Tue, Jun 13, 2023 at 08:02:29AM +0200, Erez wrote: > Hi, > > Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github > itself. "Simulated HIL" is an oxymoron. H stand for hardware. Don't get me wrong, I absolutely love linuxptp-testsuite, and I run it on every single patch. But simulation and actual hardware are two different worlds. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Quarterly release schedule
On Fri, Jun 09, 2023 at 07:14:31PM -0700, Richard Cochran wrote: > On Fri, Jun 09, 2023 at 09:44:04AM -0700, Bernie Gmail wrote: > > It would really be cool to read mode about your HIL setup. I would like to > > create a similar setup > > I'll publish the source code. https://github.com/richardcochran/hil There it is. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Quarterly release schedule
On Fri, Jun 09, 2023 at 09:44:04AM -0700, Bernie Gmail wrote: > It would really be cool to read mode about your HIL setup. I would like to > create a similar setup I'll publish the source code. The HIL depends strongly on the actual hardware that I happen to have, and I'm NOT trying to make a general purpose framework, but still you might find it useful. At the very least, I want to be transparent about how I am testing the code base. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] Quarterly release schedule
Dear linuxptp users and developers, Moving forward I am planning on making quarterly releases. The next target dates are as follows. September 5 2023 December 5 2023 March 5 2024 June 5 2024 Inspired by Miroslav's wonderful linuxptp-testsuite, for yesterday's release I developed a hardware in the loop (HIL) test framework. Previously I had had a collection of smoke tests in the form of notes with hardware setup, command lines, and expected results, and running the tests was a major chore. With the HIL framework in place, I am able run the smoke tests very easily, and that allows me to release the software with confidence. I think the version numbering will continue with 4.1, 4.2, and so on. We can bump the major version to 5 when we get to 4.12. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] ioctl SIOCETHTOOL failed: No such device
On Fri, Jun 09, 2023 at 12:28:29PM +0530, Tony Josi wrote: > tony@tony-IdeaCenter:~$ sudo ethtool -T enx0c379 > Time stamping parameters for enx0c379: > Cannot get device time stamping settings: No such device You don't have a network interface of that name. You can do cat /proc/net/dev to see the interfaces that exist on your system. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] ioctl SIOCETHTOOL failed: No such device
On Thu, Jun 08, 2023 at 09:34:33PM +0530, Tony Josi wrote: > How can I specify the PTP device, Isnt it the network interface that I have > already specified? Yes, you did specify the interface/ptp device, and that should work. What does this show? ethtool -T enox0c379 Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] [announce] version 4.0 released
low COMMAND action on non-UDS port. clock: Rename UDS variables to read-write. clock: Add read-only UDS port for monitoring. timemaster: Set uds_ro_address for ptp4l instances. sk: Don't return error for zero-length messages. Avoid unaligned pointers to packed members. pmc: Fix printed totalCorrectionField. Avoid undefined integer operations. Revert "phc2sys: Expand the validation of the PPS mode." tc: Fix length of follow-up message of one-step sync. clock: Reset state when switching port with same best clock. clock: Reset clock check on best clock/port change. port: Don't check timestamps from non-slave ports. port: Don't renew raw transport. clockcheck: Increase minimum interval. config: Add workaround for glibc getopt_long(). Fix quoting in ptp4l man page. lstab: Close file after reading. clock: Accept new UTC offset after leap second. clock: Print info message when leap flags change. clock: Clear leap flags after leap second. clock: Notify servo about leap second on UTC hardware clock. clock: Split update of leap status from clock_time_properties(). pmc: Initialize reserved field in management_tlv_datum. rtnl: Fix rtnl_rtattr_parse() to process max attribute. rtnl: Add function to detect virtual clocks. Add support for binding sockets to virtual clocks. config: Add port-specific phc_index option. port: Check for virtual clocks. tlv: Add PORT_HWCLOCK_NP. phc2sys: Use PHC index from PORT_HWCLOCK_NP. timemaster: Add support for virtual clocks. clockadj: Change clockadj_compare() to return errno. sysoff: Change sysoff_measure() to return errno. sysoff: Change log level of ioctl error messages. sysoff: Retry on EBUSY when probing supported ioctls. phc2sys: Don't exit when reading of PHC fails with EBUSY. port: Disable PHC switch with vclocks. sk: Handle EINTR when waiting for transmit timestamp. phc2sys: Add clocks after processing configuration. Drop support for old kernels returning zero frequency. Don't accept errors in clockadj_get_freq(). Extend clockcheck to check for changes in frequency. config: Fix -Wformat-truncation warnings. port: Avoid faults with vclocks and PHC from command line. Remove obsolete statement in ptp4l man page. Add refclock_sock servo. timemaster: Replace shm_segment with refclock_id. timemaster: Use refclock_sock servo with chrony. unicast: Avoid undefined integer shifts. port: Don't switch to PHC with SW timestamping. Clear pending errors on sockets. clock: Fix summary interval in free-running mode. Nikhil Gupta (1): lstab: Bring expiration up to date. Rahul Rameshbabu via Linuxptp-devel (2): Improve efficiency of nullf servo synchronization Fix SERVO_JUMP docstring comment Richard Cochran (78): Introduce the PMC agent module. pmc_agent: Rename pmc_node to something more descriptive. pmc_agent: Hide the implementation. Find a better home for the management TLV ID helper function. Find a better home for the management TLV data helper function. Clarify the documentation of the management TLV ID helper function. Introduce error codes for the run_pmc method. pmc_agent: Convert the subscribe method into the canonical form. pmc_agent: Simplify the update method. pmc_agent: Simplify logic in update method. pmc_agent: Remove bogus comparison between last update and now. pmc_agent: Perform time comparison using positive logic. pmc_agent: Rename the update method and attempt to document it. Avoid setting clock frequency when free running. Update the description of the time_stamping configuration option. rtnl: Fix trivial spelling error in the name of a helper function. phc2sys: Fix null pointer de-reference in manual mode. pmc_agent: Convert the method that queries TAI-UTC offset into the canonical form. pmc_agent: Convert the method that queries the port properties. pmc_agent: Generalize the method that queries the local clock identity. pmc_agent: Simplify the method that gets of the number of local ports. phc2sys: Don't duplicate the command line arguments. phc2sys: Rename PMC agent pointer from node to agent. phc2sys: Replace hard coded tests with a readable helper function. phc2sys: Validate the PPS mode right away. phc2sys: Expand the validation of the PPS mode. phc2sys: Replace magical test with a proper test. phc2sys: Replace yet another magical test with a proper test. phc2sys: Move static configuration to its own subroutine. pmc_agent: Let the update method poll for push events. phc2sys: Simplify the main loop. pmc_agent: Remove an obsolete method.
Re: [Linuxptp-users] gPTP and PTP on the same computer
On Tue, May 16, 2023 at 01:54:47PM +, Eric Decker wrote: > I have a question related to the question below. If you use a > boundary clock between gPTP and PTP, does the PHC have to be shared > by both NICs? Yes. > If each NIC has an independent PHC I think phy2sys has to be used > two synchronized two instances ptp4l but I am not sure how this > configuration could work as a boundary clock. Use phc2sys flag -a and maybe also -r From the man page: -a Read the clocks to synchronize from running ptp4l and follow changes in the port states, adjusting the synchronization direc‐ tion automatically. The system clock (CLOCK_REALTIME) is not synchronized, unless the -r option is also specified. -r Only valid together with the -a option. Instructs phc2sys to also synchronize the system clock (CLOCK_REALTIME). By default, the system clock is not considered as a possible time source. If you want the system clock to be eligible to become a time source, specify the -r option twice. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] gPTP and PTP on the same computer
On Tue, May 16, 2023 at 08:35:36AM +, Fueloep, Tamas via Linuxptp-users wrote: > Dear LinuxPTP mailing list participants, > > First of all, thank you very much for this amazing software - it > really makes life easier and it is fun to use. "fun to use?" hahaha that is new! > I would have a question, because I can't get a grasp on something. I > have a setup, where multiple sensors are connected to the same > computer, each of the sensors are connected to a dedicated network > interface. Some of the sensors are only compatible with gPTP and > some of them are only with PTP. The default configuration files that > come with the ptp4linux installation are working perfectly > independently, but I cannot make the sensors work in a parallel > way. I have tried to run multiple ptp4l instances and for the PTP > I've used the 'default.cfg' and for the gPTP the > 'automotive-master.cfg'. Obviously this does not work as expected, > but I am a bit lost on figuring out what would be the ideal setup in > this case. > Could you please help me what is the right concept to use in this situation? You can run ptp4l as a Boundary Clock on multiple interfaces at once, and you can freely mix and match profiles on the different ports. For example: ptp4l -m -q -i eth0 -i eth1 or in a configuration: [global] # ... [eth0] # eth0 options... [eth1] # eth1 options... The only thing I'm uncertain of is the Automotive Profile. Most of the configuration options are per-port, but you will probably not set the global option inhibit_delay_req. See the man page and/or config.c to learn which options are per-port. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Question about delay estimation and offset
On Fri, May 12, 2023 at 01:54:05PM +0200, Víctor Vázquez Rodríguez wrote: > We are doing some research based on ptp4l and I noticed that it > doesn’t perform delay estimation and offset estimation on the same > cycle. There is no such thing as a "cycle" in 1588. Sync/FollowUp and Delay_Req/Resp are on two independent schedules. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Question about delay estimation and offset
On Fri, May 12, 2023 at 01:54:05PM +0200, Víctor Vázquez Rodríguez wrote: > We are doing some research based on ptp4l and I noticed that it > doesn’t perform delay estimation and offset estimation on the same > cycle. That is, the client updates only the estimated delay when it > receives a DELAY_RESP and then updates the offset estimation (and > corrects the clock) when receiving next cycle’s SYNC message. Is > there a specific reasoning behind this implementation decision? This is specified in IEEE 1588. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Software timestamping delay - master offset drift
On Thu, May 11, 2023 at 01:01:54PM -0300, Elder Costa wrote: > The master offset increases, non monotonically but with a very definite > trend, whether with or without the step_threshold parameter. > What am I missing? Maybe you have ntpd or systemd timesync or chrony running on the client and/or the server? IIRC Ubuntu enables systemd thing by default, and it is hard to get rid of. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Trying to understand different behaviors of ptp4l
On Wed, May 10, 2023 at 05:10:10PM -0300, Elder Costa wrote: > Yes, I did read it. Several times. Unfortunately it is still not clear > what it really means. That line was exactly the reason why I thought > there would be some sort of clock resynchronization if there were a > bigger than threshold difference between the local and the master's > clock, in the first place. So, could you elaborate a little for mine > and maybe other novice users? Or point to a more detailed reference? step_threshold The maximum offset the servo will correct by changing the clock frequency (phase when using nullf servo) instead of stepping the clock. When set to 0.0, the servo will never step the clock ex‐ cept on start. It's specified in seconds. The default is 0.0. The ptp4l program estimates the client/server time offset by using the PTP. Once the offset estimate is obtained, an action is taken to correct the client's clock. There are two possible corrective actions: 1. Set (aka step aka jump) the client clock to match the server's clock. 2. Slew the client clock (by changing the frequency to make it run faster or slower) until it matches the server's clock. By default, the ptp4l program uses method #2. But if you set --step_threshold=X, the program will use method #1 whenever the estimated offset exceeds X. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Trying to understand different behaviors of ptp4l
On Wed, May 10, 2023 at 02:35:01PM -0300, Elder Costa wrote: > I think I am misusing the step_threshold parameter. What exactly this > parameter does? See the man page (ptp4l.8) Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] ptp4l passive phc synchronization with active phc in linux bonding
On Sun, Apr 16, 2023 at 01:54:20PM +0530, shashank varshney wrote: > *sfptpd supports PTP packets over bonded interfaces in an active/standby > mode. In addition, sfptpd also supports bonding over LACP (802.3ad) > bonding.* Looks like sfptpd is a hacked version of the old ptpd program. If that works for you, then great. > *Is there any plan to include a similar kind of working mechanism for PTP > over Linux Bonding for seamless switchover in case of failure of > active-slave port to passive-slave port when both slaves are on different > NICs with different PHCs?* I'm not aware of any plan for that. If you feel like adding it, then we'll look forward to your patches on the list... Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] 802.1AS management
On Thu, Apr 13, 2023 at 05:03:50PM +, Eric Decker wrote: > I am working on monitoring gPTP health for automotive products using 802.1AS. > According to 802.1AS-2020: > > 1. Section 10.6.1 "PTP Management Messages are not used in this standard. > They are specified in IEEE Std 1588-2019." > * Does this means gPTP does not support PTP management messages? Seems like it. > * If ptp4l is configured to use 802.1AS will it support management > messages? Yes. > 2. Section 15.1 "Managed objects are accessed via a virtual information > store, termed the Management Information Base (MIB). MIB objects are > generally accessed through the Simple Network Management Protocol (SNMP)." > * My understanding is that PTP management messages at not supported > and MIBs and SNMP should be used instead. > * Does Linux PTP support MIBs and SNMP? From what I can tell from the > code it does not. I looked at the mailing list and it appears SNMP support > was removed around March 2020 because it was not complete. It does not > appear it has been added back to the code base, at least not on the Git > master branch. Are there plans to support MIBs and SNMP in the future? SNMP is not supported, and there are no plans to add that. > 3. Does Linux PTP support "reverse sync" for monitoring, or will it > support it in the future? Yes, it supports the NetSync Monitor (NSM) protocol. See the 'nsm' program and its man page. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Wed, Apr 12, 2023 at 02:56:31PM +1000, Aris Theocharides wrote: > > >> LR actually have a slew of Industrial Ethernet (all multiport) on their > >> website. > >> > > Okay, so I guess this is not a true Intel i210 but some kind of > > strange clone. > > It would seem so, although I guess that some single port i210’s are also and > they seem to work ok with LinuxPTP. I'm trying to tell you that there is no such thing as a 4-port i210. See: https://www.intel.com/content/www/us/en/products/details/ethernet/gigabit-controllers/i210-controllers.html So your 4-port card is not an i210 at all. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Wed, Apr 12, 2023 at 12:24:21AM +1000, Aris Theocharides wrote: > LR actually have a slew of Industrial Ethernet (all multiport) on their > website. Okay, so I guess this is not a true Intel i210 but some kind of strange clone. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Tue, Apr 11, 2023 at 05:03:31AM +1000, Aris Theocharides via Linuxptp-users wrote: > > The card in question is a 4-port i210 PCIe - > https://www.lr-link.com/products/LRES3004PT.html That is a very strange looking card. I guess it has 4 i210 ASICs? What is under the giant heat sink? Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Tue, Apr 11, 2023 at 05:03:31AM +1000, Aris Theocharides via Linuxptp-users wrote: > > The card in question is a 4-port i210 PCIe - > https://www.lr-link.com/products/LRES3004PT.html > > It seems to behave for general use, but I can’t use it without PTP working. > > A single-port PCIe i210 behaves perfectly on the same mainboard, so I assume > that something interesting is happening in the i210 driver for this card. > > For interest, I have 2 of these cards, and both exhibit the same behaviour > (so, unlikely to be a failure of a specific card). A single-port i210 card > work perfectly. > > Not sure where from here. Maybe a full debug trace? Probably the generic work (see igb_ptp_tx_work()) is being delayed too much on your RT kernels. Try increasing tx_timestamp_timeout to a really large value, like 1000. Also try a non RT kernel. Proper fix is to let driver use ptp_aux_kworker/do_aux_work and set kernel thread to SCHED_FIFO at high priority. FWIW I have a box with three 1-port i210 PCIe cards that runs fine on vanilla kernel. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Layer 2 ptp on Nvidia Orin
On Mon, Apr 10, 2023 at 07:09:23PM +, Greiner, Andreas wrote: > We are using these versions: > > ptp4l: 3.1-00224-gd4adf87 > kernel: 5.10.104-tegra > > Are there any mistakes on our side? What else can we try? This is likely a bug in the vendor kernel. You should ask them to fix it for you. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Mon, Apr 10, 2023 at 10:31:05PM +1000, Aris Theocharides via Linuxptp-users wrote: > Intel Module (from SF, v 5.13.16): Can't comment on that, since not mainline linux. > Debian 12 Kernel Module (based on Linux 6.1.20 kernel, modified by Debian): > > > filename: > > /lib/modules/6.1.20-rt8/kernel/drivers/net/ethernet/intel/igb/igb.ko Hm, Debian is shipping a PREEMPT_RT kernel? That is news to me. > root@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H > ptp4l[11754.773]: selected /dev/ptp0 as PTP clock > ptp4l[11754.818]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[11754.818]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[11754.819]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[11760.857]: port 1 (enp3s0): LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[11760.857]: selected local clock 6cb311.fffe.663910 as best master > ptp4l[11760.857]: port 1 (enp3s0): assuming the grand master role > ptp4l[11761.868]: timed out while polling for tx timestamp > ptp4l[11761.868]: increasing tx_timestamp_timeout may correct this issue, but > it is likely caused by a driver bug Did you try this? ^^^ > AVNU Module (from AVNU): > > > filename: > > /lib/modules/6.1.20-rt8/kernel/drivers/net/igb_avb/igb_avb.ko > > version:5.3.2_AVB Can't comment on that, since not mainline linux. IMHO avnu driver stuff is of dubious quality. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] rogue peer delay response caused by port_synchronize()
On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote: > Hi Miroslav, > > We use Synopsys's IP, the driver is the same as stmmac Yeah, the stmmac driver is crazy bad. It is not clear to me whether setting the time when enabling time stamping is actually required by the IP core or not. But even if it were required, still the driver should attempt to keep the MAC unaltered by reprogramming the current MAC time. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] PTP Bouncing between Grandmasters
On Mon, Mar 20, 2023 at 07:43:00PM +, Chang, Benjamin via Linuxptp-users wrote: > Does anyone know why the switch may be bounding between the actual > grandmaster timesource and itself? That would be a question for the switch vendor. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Set currentUtcOffsetValid in configuration file
On Mon, Mar 13, 2023 at 10:29:55AM +0700, James Clark wrote: > Would it make sense to set currentUtcOffsetValid to 1 if the TAI > offset is set in the kernel to a non-zero value (which would typically > come from running an NTP server)? The time in the PHC is not necessarily connected to the Linux kernel time. If they are connected, for example by using phc2sys, then the same scripts that control phc2sys can also control pmc to set currentUtcOffsetValid appropriately. > currentUtcOffsetValid=0 also triggers very broken behaviour in the > Windows 11 PTP client: it will make it use a UTC offset of 0. (I would report that on the M$ PTP mailing list, assuming there is one ;^) Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Set currentUtcOffsetValid in configuration file
On Mon, Mar 13, 2023 at 01:31:56AM +0100, Georg Sauthoff wrote: > However, I'm curious, is this a deliberate design decision to not provide > a configuration setting for the currentUtcOffsetValid value, as well? > Or is such configuration simply missing because nobody has bothered adding > one? This is very much a design decision that was made on purpose. The UTC offset can only be valid if the computer has access to the global time distribution system (ie GPS or NTP) and monitors leap second announcements in real time. A hard coded configuration setting would be morally wrong! Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] How to simultaneously work l2 and l3 clients
On Tue, Mar 07, 2023 at 12:41:52PM +0200, Kamil Zaripov wrote: > I have a setup where master running on host with Intel I210 network > card and several slaves. Among them some can send PTP messages only > over UDP and some of them only over Ethernet. So I’m using two ptp4l > presses. One of them called with -2 command line argument and > another one with -4 and both of them use same port passed with -I > argument. Though I210 network card cannot concurrently timestamp two > packages. > > This lead to the race - if both of ptp4l processes will send Sync > messages at the same time with hw tx timestamp request to gib driver > only one of them will get timestamp and another one will timeout > waiting for the timestamp. > > Is it possible to sync ptp4l processes so they will not send Sync > messages simultaneously? No, but why not run one process configured with two interfaces? For example: ip link property add dev eth1 altname eth1a Then make a config. file: [eth1] network_transport UDPv4 [eth1a] network_transport L2 I think that should work for your use case. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] message rates on G.8275.1
On Fri, Feb 17, 2023 at 05:40:54PM +0530, Aditya Venu via Linuxptp-users wrote: > But I want domain number 24, announce/sync/delay to be 8/16/16 per second. > I've put these values in default.cfg but still it is not reflecting. Did you run: ptp4l -f default.cfg ? Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] IEEE802.1AS gPTP Boundary Clock
On Thu, Feb 09, 2023 at 01:32:14PM +0100, Miroslav Lichvar wrote: > Yes, but if you know the length of the chain and charateristics of all > clocks and their timestamping, you can tune the servos to minimize > their gain peaking for the synchronization of the last clock. This can > be done with the pi servo in ptp4l. Cool. Have you ever published examples of this? That would interest me. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] IEEE802.1AS gPTP Boundary Clock
On Wed, Feb 08, 2023 at 08:28:54PM +, Nemo Crypto wrote: > What does NIH mean? Not Invented Here? yes. ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] IEEE802.1AS gPTP Boundary Clock
On Wed, Feb 08, 2023 at 09:33:49AM +0100, Miroslav Lichvar wrote: > On Tue, Feb 07, 2023 at 07:39:48PM -0800, Richard Cochran wrote: > > Sure, if you have a chain topology of 15 hops, then you would start to > > see benefits from using TAB over BC. But who has that kind of network? > > > > Even then, would an 802.1as TAB outperform an ieee 1588 TC? > > The draft I saw claimed that the synchronization performance of the > network is identical to 1588 using P2P TCs. It's not clear to me what > advantages their approach has. gPTP is full of NIH, IMO. > BTW, synchronization with BCs can work better than TCs if the PLLs are > well implemented and tuned. TCs are the simpler and safer approach. There was a simulation study showing "gain peaking" from a long chain of servos. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] IEEE802.1AS gPTP Boundary Clock
On Tue, Feb 07, 2023 at 03:59:23PM +, Nemo Crypto wrote: > >As a practical matter, I don't see why you can't simply use linuxptp's > >BC mode, configuring the two ports with 802.1as settings. > > >Who could tell the difference? > Would the linuxptp's BC send all the TLVs required for 802.1AS? What TLVs do you mean? The ptp4l BC will append follow_up_info and PATH_TRACE, if you enable them. See the default gPTP.cfg. In my view, the whole TAB thing in 802.1as is of questionable value. If you have a single hop, as in your use case, I doubt you could even measure the difference in synchronization quality between TAB and BC. Sure, if you have a chain topology of 15 hops, then you would start to see benefits from using TAB over BC. But who has that kind of network? Even then, would an 802.1as TAB outperform an ieee 1588 TC? Color me skeptical. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] IEEE802.1AS gPTP Boundary Clock
On Tue, Feb 07, 2023 at 01:49:42PM +, Nemo Crypto wrote: > Then the actual question becomes, whether linuxptp has support for > IEEE802.1AS Time Aware Bridge (Time Relay)? No, TAB/Time Relay is not supported. There was some initial work done (check the archives), but that was never finished. As a practical matter, I don't see why you can't simply use linuxptp's BC mode, configuring the two ports with 802.1as settings. Who could tell the difference? Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] PTP4l: Next planned release date?
On Tue, Jan 24, 2023 at 07:13:01AM +, ramesh t via Linuxptp-users wrote: > Any idea when is the next planned release for ptp4l? Yes, I'm going to release version 4.0 with the current git HEAD plus a few more items. ETA February 14, 2023. > We are currently using 3.1.1 release, but we need fixes present in the > current base code. > Is it ok to take these missing fixes and merge into 3.1.1 local code base? Sure, you can patch your own 3.1.1 branch with any fixes you need. I will not be maintaining 3.1.x with bug fixes, unless a really serious bug appears. None of the fixes in current git HEAD would qualify. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Automotive Profile doesn't recognize Grandmaster presence
On Wed, Jan 18, 2023 at 08:37:20PM -0500, First Last wrote: > So, does this mean that when using the Automotive Profile, we can never > have ptpTimescale set to 1? If so, is there a reason for this? It is an oversight from the original automotive profile patch set. I also noticed that the pmc settings on the master side never take effect. I guess the author didn't really test this profile very much. And I haven't had time to fix it. Sorry, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Synchronizing cyclic tasks on two Linux systems
On Tue, Jan 17, 2023 at 09:05:47AM +, Wagner Florian (DC-AE/ESW2) via Linuxptp-users wrote: > But for synchronizing the phase of the schedulers, it would be > sufficient to synchronize the CLOCK_MONOTONICs relative to the cycle > time of our tasks. So if we could for example define, that the > offset between CLOCK_MONOTONIC and CLOCK_REALTIME can only be a > multiple of our cycle time (eg. 1ms), this would be sufficient. Is > there an option to do something like this? The realtime/monotonic offset is handled in the kernel. Setting CLOCK_REALTIME aka "wall clock" amounts to setting the variable wall_to_monotonic in the timekeeper data structure. There is no kernel interface to do what you what you propose. > If this is not the case, what would happen if we hard (re-)set the > offset during runtime of phc2sys to the closest multiple of our > cycle time? Would phc2sys overwrite this Yes, if allowed by the step_threshold configuration option. > or would it just adjust the > difference to the master clock that was introduced by this > manipulation by adjusting the frequency of > CLOCK_REALTIME/CLOCK_MONOTONIC? This is the likely case, when step_threshold == 0. > Do you have other recommendations to synchronize cyclic scheduling on linux > systems with a monotonic time source? Barring hacking the kernel, I think the easiest way would be to call t1 = clock_gettime(CLOCK_REALTIME); t2 = clock_gettime(CLOCK_MONOTONIC); t3 = clock_gettime(CLOCK_REALTIME); and figure the phase difference using (t1 + t3)/2 - t2 and then correct your monotonic timer so that it remains in phase with CLOCK_REALTIME. You only have to do this once at the beginning, then repeat whenever CLOCK_REALTIME is set (you can detect that with the timer API). HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] clock_gettime implementation in driver
On Wed, Jan 18, 2023 at 11:36:40AM +0530, Aditya Venu via Linuxptp-users wrote: > I am running my device as a master. Is it mandatory to implement driver > call backs for gettime and settime for master? > > I think the ptp4l program doesn't call clock_gettime() and clock_settime > but I'm not sure. Can you please clarify? I don't think ptp4l will call get/settime in master mode. strace will tell you for sure. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Slave's clock servo not going to locked state
On Fri, Jan 13, 2023 at 12:32:21PM +0530, Aditya Venu via Linuxptp-users wrote: > d) I'm using default config files for both master and slave(attaching them > for reference) You are NOT using the default configuration. You changed step_threshold from the default of zero. This is the reason for the oscillation between S0 and S1. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] PMC Response Time
On Thu, Jan 05, 2023 at 09:54:21AM -0500, Jason Lehmann wrote:
> Hello,
>
> I am polling pmc in a thread at 1hz in a program with the following command
> -
>
> statusResp = exec("pmc -u -s /var/run/ptp4lro -i /tmp/pmc.socket 'GET
> TIME_STATUS_NP'");
>
> It returns the status but takes about 100ms to execute. Is this time
> expected or is there a way to reduce it?
That doesn't sound unreasonable.
If you want better performance, you can script your own PMC client using:
https://github.com/erezgeva/libpmc
HTH,
Richard
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Multiple ports on each PTP instance
On Wed, Jan 04, 2023 at 08:55:51AM +0530, Gururaj Badiger wrote: > Could someone clarify why these multiple ports are getting created for each > PTP insace and what is the significance of these extra ports. The port numbering follows the requirements of IEEE standard 1588. If you run ONE ptp4l instance using both ports, then the port numbering will be what you are expecting. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Linux PTP on Raspberry Pi CM4 problems/workarounds
On Wed, Nov 30, 2022 at 07:14:01AM -0800, Richard Cochran wrote: > On Wed, Nov 30, 2022 at 02:27:19PM +0700, James Clark wrote: > > > I suppose problems 4 and 5 should be reported as kernel problems, but I'm > > not sure of the best place to do it. Should it be the raspberrypi/linux > > issue tracker or the kernel bugzilla? On second thought, problem 4 is perhaps a driver bug as well. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Linux PTP on Raspberry Pi CM4 problems/workarounds
On Wed, Nov 30, 2022 at 02:27:19PM +0700, James Clark wrote: > I suppose problems 4 and 5 should be reported as kernel problems, but I'm > not sure of the best place to do it. Should it be the raspberrypi/linux > issue tracker or the kernel bugzilla? The root cause of problem 4, like problems 1, 2, and 3, is the hardware. The issues appear to be fundamental design issues, and little or nothing can be done in software to work around them. Problem 5 sure sounds like a driver bug. I would contact the author of the driver. If the driver is mainline, the best way is to email the author with the netdev list on CC. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] can linuxptp run on a single system?
On Wed, Nov 23, 2022 at 03:12:36PM +0100, Miroslav Lichvar wrote: > This is not an issue with the protocol. As I understand it, the kernel > will normally not send or accept a unicast packet to itself over a > real network interface. It has the loopback interface for that. > > One way to get around that is to use multiple network namespaces. You can run 2x ptp4l, one on each port. If you use layer2 transport (-2 command line option) then it just works. If you want UDP transport, then you must configure the kernel networking stack to accept messages from itself: # In order to run PTP tests with two or more local interfaces, the # kernel must be told to accept packets from a local address. all="eth6 eth4 eth3" for x in $all; do echo 1 > /proc/sys/net/ipv4/conf/$x/accept_local done HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Current Linuxptp not compiling on compilers without enforced std version
On Wed, Nov 16, 2022 at 01:54:52PM +0100, Jakub Raczyński wrote:
> arm-linux-gcc -Wall -DVER=3.1-00176-ga115563-dirty -D_GNU_SOURCE
> -DHAVE_CLOCK_ADJTIME -DHAVE_POSIX_SPAWN -DHAVE_ONESTEP_SYNC -c -o tlv.o tlv.c
> tlv.c: In function ‘mgt_post_recv’:
> tlv.c:374:3: error: ‘for’ loop initial declarations are only allowed in C99
> or C11 mode
> for (int i = 0; i < umtn->actual_table_size; i++) {
Yeah that snuck past the review. Local variables belong at top of
function. Please submit patch to fix.
Thanks,
Richard
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] [Linuxptp-devel] Wrong Update of PHC time.
On Fri, Nov 04, 2022 at 03:36:14AM +, ramesh t via Linuxptp-devel wrote: > Hi, > > Observed a issue where PTP is running is fine with single digit rms value. > Due to error in switch/GM, there is wrong time update towards the ptp4l. This > results in wrong update on PHC time on the NIC. PHC time seems to be set to > 1970 or 2070 timeframe may be due to error condition in ptp4l. Though the GM > or switch starts sending proper time in sometime, PHC time on the NIC doesn't > get corrected. > > Quick Question: > Is there any fix provided in the latest code which handles case where > GM/Switch send wrong time momentarily? > After GM/switch recovered to proper time, is there a way for PHC to converge > faster to proper time? Please don't send such questions to the -devel list. The -devel list is for patches only. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel X722 maybe incompatible with IEEE1588 2.1
On Thu, Oct 20, 2022 at 12:27:06AM -0700, Cliff Spradlin via Linuxptp-users wrote: > I'm looking into it further, but it looks like the X722 (which uses > the i40e driver) does not record RX timestamps on layer 2 1588 event > packets But it does timestamp UDPv4 frames? > where the version is set to 2.1 rather than 2. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] (no subject)
On Mon, Oct 17, 2022 at 10:24:36AM +0200, Akash Munirathinam wrote: > > Hey guys, > I really would like to know the answer to this question that's bugging me. > I have a NIC I350 with 4 ports. is it possible to make one port as Master > and the other ports as slave? or do i need to have another NIC which can act > as a slave. If each of the 4 ports has its own PHC, then you can run one ptp4l instance on each port. The easiest way is with layer2 (-2) transport. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] ioctl on /dev/ptpX
On Sat, Oct 15, 2022 at 01:46:08PM -0700, todd freed wrote:
> All the information I am interested in is available from pmc -u 'GET
> CURRENT_DATA_SET'. But I am not keen to run this operation in a
> separate process.
>
> It seems that pmc is talking to ptp4l roughly by,
>
> socket(AF_UNIX, SOCK_DGRAM, 0) = 3
> bind(3, {sa_family=AF_UNIX, sun_path="/var/run/pmc.789975"}, 110)
> sendto(3, ...)
> recvfrom(3, ...)
>
> All well and good ; is there documentation about the data structures
> sent and received in this manner?
See the management facility in IEEE 1588. That standard defines and
documents the GET CURRENT_DATA_SET request+response messages.
> It would be even simpler if I could make ioctls against the open
> /dev/ptpX fd. It does seem like some such ioctls might exist [1] but I
> can't find documentation for those, either.
No, the device driver implements basic clock operations, like gettime
and settime, and it has nothing at all to do with the PTP.
Thanks,
Richard
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX (2022)
On Sat, Oct 15, 2022 at 02:37:06PM -0700, todd freed wrote: > Question about the technique for converting PHC timestamps into > monotonic deadlines. > >clock_gettime(CLOCK_MONOTONIC, t1); >clock_gettime(phc, t2); >clock_gettime(CLOCK_MONOTONIC, t3); >offset = ((t3 - t1) / 2) - t2 > > Using code like this, I seem to observe a drift of about ~1 > microsecond per second. That is, the offset from the system monotonic > clock to the PHC clock grows by ~1000 nanoseconds each second. > > That is not what I would expect .. both domains have nanosecond > precision. That's quite a lot of drift to compensate for. Any ideas? Unless you syntonize CLOCK_REALTIME with the PHC, drift is expected and normal. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] (no subject)
On Fri, Oct 14, 2022 at 04:33:11PM +0530, Gururaj Badiger wrote: > Hellow, > > Trying to make this query a bit simple: > > When *ClockClass* is set to 248, ptp4l, currently, goes into Ordinary > Clock(OC) mode. By that, it can switch to either Leader or Follower based > on availability of GM in the domain. > However, during some usecases, I would like to inhibit Slave state when > clockClass is set to 248. > > To achieve this, I'm looking for a flag which can be set in the config file > to inhibit slave state. Does such a flag exist? Why not use this? --free_running=1 This prevents synchronization unconditionally, regardless of port state. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Question regarding ptp4l
On Thu, Oct 06, 2022 at 06:44:29PM +, vignesh shanmugam via Linuxptp-users wrote: > Can you point me some clues what could cause this? What is the MAC? Does it use software time stamping? Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] PTP1 and PTP2 in LEADER and both remain ACTIVE
On Thu, Oct 06, 2022 at 08:40:54PM +0530, Gururaj Badiger wrote: > However, when Two LEADERS are running in the same domain then one of them > goes to "PASSIVE" state as there can be only one Best Master in the domain. > In that case, though there are two ports and they are configured to the > same domain, I was expecting the same behavior in my set-up too. Only if the networking stack does not drop UDP frames from other interface on same host. This is the default on Linux. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] PTP1 and PTP2 in LEADER and both remain ACTIVE
On Thu, Oct 06, 2022 at 02:32:18PM +0530, Gururaj Badiger wrote: > Used two commands on two terminls: > > TERMINAL:~# ptp4l -i eth1 -m -f > /home/root/ptp-manager/source/linuxptp_config_0.conf > TERMINAL:~# ptp4l -i eth2 -m -f > /home/root/ptp-manager/source/linuxptp_config_1.conf You are running two instances on two network ports in two different networks. So both ports will assume the PTP "master" role. This is both correct and expected. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX (2022)
On Sat, Oct 01, 2022 at 08:47:53PM -0700, todd freed wrote: > Could you say just a bit more about why it shouldn't be implemented? I'm only saying that the potential benefit is very meager and does not justify the implementation effort. > I'm a professional software engineer, and I had thought I might take a > look at implementing it myself. But if you wouldn't recommend such a > thing, I will avoid spending any time on it. Before you do anything, I recommend reading these threads from archives from 2016: 31.Aug'16 Kieran Tyrrell Re: [Linuxptp-users] one-shot alarm 31.Aug'16 To Kieran Tyrre └─> 31.Aug'16 Dale Smith ├─>Re: [Linuxptp-devel] [Linuxptp-users] one-shot alarm 09.Sep'16 Kieran Tyrrell └─>Re: [Linuxptp-users] one-shot alarm 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX timer interface 12.Sep'16 To Kieran Tyrre └─> 12.Sep'16 Kieran Tyrrell ├─> 12.Sep'16 To Kieran Tyrre│ └─> 15.Sep'16 Kieran Tyrrell │ ├─> 15.Sep'16 To Kieran Tyrre│ │ └─> 15.Sep'16 Kieran Tyrrell │ │ └─> 18.Oct'16 Kieran Tyrrell │ └─>igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX ti 18.Oct'16 To Kieran Tyrre│ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement PO 18.Oct'16 To Kieran Tyrre│ ├=>Re: igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement 19.Oct'16 Keller, Jacob E│ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement 13.Sep'16 Kieran Tyrrell └─> 13.Sep'16 To Kieran Tyrre └─> 15.Sep'16 Kieran Tyrrell └─> 15.Sep'16 To Kieran Tyrre └─> 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] igb: add timer (alarm) functionality 12.Sep'16 To Kieran Tyrre └─> 13.Sep'16 Kieran Tyrrell └─> 13.Sep'16 To Kieran Tyrre └─> 14.Sep'16 Kieran Tyrrell └─> 15.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH V2] ptp and igb: implement POSIX timer (alarm) 03.Oct'16 To Kieran Tyrre └─> 06.Dec'16 To Kieran Tyrre└─> Especially this last message ^^^ shows the poor performance of a PCIe card: TL;DR graph... https://linuxptp.sourceforge.net/phc-timer/phc-timer-vs-nanosleep.png Good luck, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX (2022)
On Sat, Oct 01, 2022 at 10:10:37AM -0700, todd freed wrote: > I gather from the ENOTSUPP return that it's also not implemented > today. I'm running linux 5.19.7. Just wanted confirmation on that > point? Correct. Will not ever happen. Big can of worms. > I could run phc2sys on these hosts and then sleep against > CLOCK_MONOTONIC. But I had wanted to avoid that, simply because some > of the devices (desktop pcs) are being used for things other than this > specific application, and I'd not like to takeover the systemwide > clock. If you really can't/won't use phc2sys, then you can also do clock_gettime(CLOCK_MONOTONIC, t1); clock_gettime(phc, t2); clock_gettime(CLOCK_MONOTONIC, t3); and calculate offset = ((t3 - t1) / 2) - t2 every once in a while, then use linear interpolation to convert deadlines from the PHC time scale into monotonic deadlines. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] PPS Error: PTP_EXTTS_REQUEST2 failed
On Mon, Sep 26, 2022 at 05:02:28PM +, Deshpande, Yash wrote: > 4. sudo ts2phc -c /dev/ptp0 -s generic -m > > ts2phc[17625.163]: PTP_EXTTS_REQUEST2 failed: Operation not > supported > failed to arm PPS sinks That is because the i210 only supports "both edges" and not the default "rising". ts2phc.extts_polarity The polarity of the external PPS signal, either "rising" or "falling". Some PHC devices always time stamp both edges. Set‐ ting this option to "both" will allow the ts2phc program to work with such devices by detecting and ignoring the unwanted edge. In this case be sure to set 'ts2phc.pulsewidth' to the correct value. The default is "rising". See configs/ts2phc-generic.cfg for a configuration that works with i210. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] [Linuxptp-devel] Planning release 3.2
On Tue, May 04, 2021 at 04:46:59AM -0700, Richard Cochran wrote: > On Mon, May 03, 2021 at 05:09:09PM +0200, Michael Walle wrote: > > did I miss something or wasn't there a 3.2 release? > > You didn't miss anything. I have been delayed in pushing out the 3.2 > release. Next release will be 4.0 and will include (most) of the current back log of patches. I won't release a 3.2 version. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] BMCA: ECU takes long time to Sync to Master
On Fri, Sep 23, 2022 at 08:25:22AM +0530, Pramod wrote: > Its confirmed that the announce packets from ECU1 do arrive in ECU2. But > for some reason, looks like ptp4l is not able to consider it and there is > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES. > > Do you have any ideas or suggestions as to why this may happen and for us > to investigate this problem? Probably your logAnnounceInterval and/or announceReceiptTimeout are misconfigured. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] linuxptp result doesn't match 1PPS measurement
On Fri, Sep 09, 2022 at 08:45:19AM +0800, Hamilton Alex wrote: > Hi, Richard: > I am not quite understand. I am using Calnex master-->board slave, if the > linuxptp print out is correct, that means local clock > has the same frequency and phase as master clock, then the 1PPS out should > near the reference 1PPS. > > why path asymmetry would affect the 1PPS out? You reported a 40 nanosecond phase offset. One possible cause is path asymmetry. The PTP assumes the Tx and Rx transmission delays are exactly equal. However, this is almost never true. Any real asymmetry results in a phase offset that is uncorrectable by the PTP. Because your 40 ns phase offset is very small, you might very well have path asymmetry somewhere in your system. For example, your PHY might delay frames longer on Tx than on Rx. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Help with what is undoubtedly a problem with my configuration
On Thu, Sep 08, 2022 at 10:21:09PM +, Brian Lilly wrote: > This is on a Kria K26 SOM, though granted, it's the development board KV260 > version and not the production SOM. I can test on a production SOM if that's > an issue. I would ask the vendor if/how they tested and validated the PTP feature. Good luck, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Help with what is undoubtedly a problem with my configuration
On Thu, Sep 08, 2022 at 02:39:13PM -0700, Jacob Keller wrote: > > > On 9/8/2022 7:14 AM, Brian Lilly wrote: > > I’m building a Petalinux image (Xilinx’ Yocto project based build system > > thing) that includes linuxPTP. I have it starting as a service, and > > subsequently, I also have phc2sys running to synchronize the system > > clock to the clock from eth0 and my PTP master. This seems to be > > working, to some degree. > > > > > > > > Problem is that the behavior is erratic, to say the least. > > > > > > What hardware? This looks a lot like bad driver or hardware causing the > clock on the ethernet device to behave erratically. Brian had said: "Xilinx' Yocto project based build system thing" FWIW PTP in the Zynq is broken and cannot be made to work. I think the next gen. chip does fix the issues, however. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Help with what is undoubtedly a problem with my configuration
On Tue, Sep 06, 2022 at 08:20:48PM +, Brian Lilly wrote: > Some background: > > I'm building a Petalinux image (Xilinx' Yocto project based build system > thing) that includes linuxPTP. I have it starting as a service, and > subsequently, I also have phc2sys running to synchronize the system clock to > the clock from eth0 and my PTP master. This seems to be working, to some > degree. > > Problem is that the behavior is erratic, to say the least. > > For example: > phc2sys[46.726]: CLOCK_REALTIME phc offset-93776 s2 freq +32031 delay > 1020 > phc2sys[47.727]: CLOCK_REALTIME phc offset-83999 s2 freq +32168 delay > 1020 > phc2sys[48.727]: CLOCK_REALTIME phc offset -119501 s2 freq +27423 delay > 1020 > phc2sys[49.727]: CLOCK_REALTIME phc offset -479032 s2 freq -13320 delay > 1020 > phc2sys[50.727]: CLOCK_REALTIME phc offset -1923240 s2 freq -176973 delay > 1020 > phc2sys[51.727]: CLOCK_REALTIME phc offset -3395674 s2 freq -358174 delay > 1020 > phc2sys[52.727]: CLOCK_REALTIME phc offset -3394547 s2 freq -392006 delay > 1010 > phc2sys[53.728]: CLOCK_REALTIME phc offset -2828314 s2 freq -363666 delay > 1010 > phc2sys[54.728]: CLOCK_REALTIME phc offset -2187172 s2 freq -321424 delay > 1020 > phc2sys[55.728]: CLOCK_REALTIME phc offset -1661911 s2 freq -285517 delay > 1020 Are you sure no other program is fiddling with CLOCK_REALTIME? ntpd? chrony? > ExecStart=/usr/sbin/phc2sys -w -s eth0 -c CLOCK_REALTIME -P 0.1 -I 0.01 -m Maybe weights are making PI controller unstable? Defaults for SW time stamping are: #define SWTS_KP_SCALE 0.1 #define SWTS_KI_SCALE 0.001 Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] [Linuxptp-devel] linuxptp result doesn't match 1PPS measurement
On Thu, Sep 08, 2022 at 01:56:59PM +0200, Luigi 'Comio' Mantellini wrote: > - How is the 1PPS driven? Is there any reclocking logic? You need to ask > your FPGA-experts. +1 The circuit the produces the 1 PPS could well delay the signal by ten or more nanoseconds. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] linuxptp result doesn't match 1PPS measurement
On Thu, Sep 08, 2022 at 06:40:26AM -0700, Richard Cochran wrote: > On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > > > however, the 1pps time error is around 40 NS, which means my board is > > ahead of the reference for about 40NS, which doesn't match the result > > dumped by ptp4l. > > > > anyone has met similar issue before? how to debug such issue? > > This is likely due to path asymmetry. Oh, and Miroslav is correct, 9 usec path delay is huge. It should be only 5 ns per meter of cable. Good luck, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] linuxptp result doesn't match 1PPS measurement
On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > however, the 1pps time error is around 40 NS, which means my board is > ahead of the reference for about 40NS, which doesn't match the result > dumped by ptp4l. > > anyone has met similar issue before? how to debug such issue? This is likely due to path asymmetry. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] linuxptp servo can't converge
On Sat, Sep 03, 2022 at 08:09:14AM +0800, Hamilton Alex wrote: > I didn't use custom vendor linux driver, Zarlink provided steps to adjust > its DPLL frequency and I implement > it by my self. Oh, well, in that case, probably your own custom driver has a bug. Good luck, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] linuxptp servo can't converge
On Fri, Sep 02, 2022 at 08:38:08AM +0800, Hamilton Alex wrote: > Hi, my friends: > I got an issue for linux ptp servo. my board is using zarlink DPLL, I'm not familiar with "zarlink DPLL". I guess this is using a custom vendor Linux driver? If so, your issue is likely a bug in the driver and/or hardware itself. Good luck, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Management messages support
On Wed, Aug 10, 2022 at 02:18:20PM +0530, Gururaj Badiger wrote: > Is there any example of this type of message implemented in ptp4l code? If > so, could you help me with what is the name of the currently supported > MANAGEMENT type of message? Start with msg.c|h and tlv.c|h HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Syntax to use PMC with SET command
On Mon, Aug 08, 2022 at 10:17:49AM +0200, Miroslav Lichvar wrote: > On Mon, Aug 08, 2022 at 01:18:11PM +0530, Gururaj Badiger wrote: > > I understand that for some of the parameters such as PRIORITY1, > > PRIORITY2, PORT_DATA_SET_NP etc., PMC command provides the option to SET > > the values to ptp4l. > > > > Could you help me with the syntax on how to use the PMC SET command via > > shell. > > Here are some examples: > > # pmc -u 'SET PRIORITY1 130' > # pmc -u 'SET PORT_DATA_SET_NP neighborPropDelayThresh 1000 asCapable 0' +1 In general, you can send the GET command and then copy the output as a template for the SET command. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Questions about a transport option
On Mon, Aug 01, 2022 at 07:03:31PM +0900, Minseok Choi wrote: > Hello, > > My system configuration has 7 computers and the NIC installed on each > computer supports IEEE-1588. > And each computer is connected by an general unmanaged 10GbE L2 switch. > I want to use one computer as master and the others as slaves. > I wouldl like to know if I can use ptp4l with a option of '-2'(IEEE 802.3 > network transport) under my environment. Or, is it better to use a > option '-4'( UDP transport) because my switch doesn't support 1588? > Here is the configuration of the options I think. ptp4l -A -4 -i > eth0 ptp4l -A -2 -i eth0 > > Is there anything I should consider? There should be no difference between -2 and -4 in your setup. I would just use the default of -4. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] How to interpret the global ptp4l statistics at the bottom of the output?
On Sat, Jul 30, 2022 at 08:59:19PM +0200, Jukolas Juk wrote: > I am getting the following output from the ptp4l command on a slave PTP > node. When I terminate it (with Ctrl+C), some global statistics are printed > out at the bottom, That must be some hacked version. My program does not do this. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
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 out. (Announce does not get a time stamp at all) Maybe message rate config mis-match? HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] more Linux PTP documentation online
Dear list, Just found this, authored by Intel: TSN Documentation Project for Linux https://tsn.readthedocs.io/index.html It includes a chapter on synhcronization. Just FYI. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] FYI - TX Timestamp Timeout Fix
On Thu, Jul 28, 2022 at 09:31:34AM +0200, Miroslav Lichvar wrote: > On Wed, Jul 27, 2022 at 01:41:23PM -0700, Cliff Spradlin via Linuxptp-users > wrote: > > I just wanted to share the results of an investigation on TX timestamp > > timeout problems my project has been experiencing. The tl;dr is that > > the pfifo_fast qdisc suffers from data ordering bugs which can cause > > outgoing packets to get forgotten / stuck in the outgoing buffer. > > Those may have been fixed in newer kernel versions, but my solution > > was to switch to the pfifo qdisc which uses much less sophisticated > > codepaths. > > Very interesting. Thanks for sharing. Yes, and please also share on the netdev list (if you haven't already). Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
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 possible. The way to fix this is change the driver to use the PTP kworker thread by moving the "work" code to the .do_aux_work callback. Then you can set the kernel thread's schedule to SCHED_FIFO at high priority using the chrt command. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
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 ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] 3 announce messages to switch LISTENING to UNCALIBRATED
On Mon, Jul 25, 2022 at 05:46:16PM +, Oleg Obleukhov via Linuxptp-users wrote: > Hi team, > I noticed that ptp4l expects 3 announce messages to arrive before switching > LISTENING to UNCALIBRATED on RS_SLAVE. > Can somebody point out why this is a requirement See FOREIGN_MASTER_TIME_WINDOW and FOREIGN_MASTER_THRESHOLD in 1588. > and if it’s possible to configure, not really Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] How to dynamically enable / disable PTP ports?
On Mon, Jul 25, 2022 at 11:43:52AM +, Osterried Markus (ETAS-DAP/XPC-Fe3) via Linuxptp-users wrote: > Are there plans to implement these functionalities in ptp4l and pmc? None. > If not officially implemented, can anybody give hints how to implement it? > How to create events EV_DESIGNATED_ENABLED / EV_DESIGNATED_DISABLED - or what > else has to be done? The code really was never designed for ports magically disappearing or re-appearing again. So you will have to carefully consider the side effects, of which there might be many. FWIW I gave up early on trying to make dynamic changes at run time (too many issues!) Instead, I just do killall ptp4l; ptp4l --new-config-options Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Adding software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) capability to driver
On Wed, Jul 20, 2022 at 04:37:55PM +, Keller, Jacob E wrote: > Right that's what I was afraid of: its basically just the same as software > timestamping. Actually it is way worse than SW timestamping. WiFi has collisions. Many of them. Multicast frames have zero priority and are *not* re-transmitted when corrupted by collision. So the only way to do "regular" PTP (meaning without the FTM) is by setting up unicast between the WiFi clients and the AP. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Adding software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) capability to driver
On Tue, Jul 19, 2022 at 04:55:35PM -0700, Jacob Keller wrote: > > > On 7/19/2022 2:13 PM, Mohammad wrote: > > Hello, > > > > i am using Ath9k driver to implement Wifi-ptp . This won't work. Better to simply use NTP instead. > > in the README.org is is written adding this capability entails adding a > > single line of code to the device driver. > > > > Which Code of line and where should be this line added? That statement only applies to Ethernet MAC drivers. > I am not sure how accurate a software timestamp for a wifi device would > be, given the potential delay between timestamp and actual transmission. WiFi on Linux is never going to support PTP. The issue is the closed source radio firmware. End of story. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] PTP Control Field bug
On Thu, Jul 14, 2022 at 02:25:14AM +, joy_bhattacha...@arcadyan.com wrote: > It is strange how the ptp4l slave can select a non-conformant GM as best > master but not a conformant GM. Unfortunate that such non-conformance would > be allowed to go undetected. Whatever. ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] instable mapping of ptp device to interface
On Wed, Jul 13, 2022 at 04:22:31PM +0200, Fabian wrote: > Hi, > > I had the same issue, systemd configurations did not affect the order of > ptpX devices. I use chrony however. My script is attached. It's not the > cleanest or nicest code but it works. +1 Using 'ethtool' is way to discover the mapping. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
