Re: [Linuxptp-devel] Virtual machines
On Sat, Oct 12, 2019 at 09:06:53PM -0700, Richard Cochran wrote: > A PHC device representing the host clock will appear in the guest. > Then, for example: > > To configure Chronyd to use PHC refclock, add the > following line to its configuration file: > > refclock PHC /dev/ptpX poll 3 dpoll -2 offset 0 > > Where /dev/ptpX is the kvmclock PTP clock. As an alternative to chrony, you could also use our very own phc2sys, if I am not mistaken. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Virtual machines
On Tue, Oct 01, 2019 at 05:48:41AM +0200, Hans-Heinrich Hansen wrote: > are there any ideas how LinuxPTP could be used in virtual machines? > > It would be sufficient to be able to use the exact time generated by PTP, > e.g. with LinuxPTP running on the host system. On the VM host, simply run ptp4l, ntpd, or chrony etc, as normal. On the VM guest, enable PTP_1588_CLOCK_KVM (since 4.11), or use Microsoft Hyper-V guest support (also 4.11+) in a Windows host. A PHC device representing the host clock will appear in the guest. Then, for example: To configure Chronyd to use PHC refclock, add the following line to its configuration file: refclock PHC /dev/ptpX poll 3 dpoll -2 offset 0 Where /dev/ptpX is the kvmclock PTP clock. (I have never used this myself, but it is supposed to work!) HTH, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 3/3] unicast: Enable sharing master tables between ports.
On Thu, Sep 26, 2019 at 03:54:32PM +0200, Miroslav Lichvar wrote:
> @@ -250,6 +252,45 @@ out:
> return err;
> }
>
> +static void free_master_table(struct unicast_master_table *table)
> +{
> + struct unicast_master_address *address;
> +
> + while ((address = STAILQ_FIRST(&table->addrs))) {
> + STAILQ_REMOVE_HEAD(&table->addrs, list);
> + free(address);
> + }
> + free(table->peer_name);
This needs test for table->peer_name != NULL ...
> + free(table);
> +}
> +
> +static struct unicast_master_table *
> +clone_master_table(struct unicast_master_table *table)
> +{
> + struct unicast_master_address *address, *cloned_address;
> + struct unicast_master_table *cloned_table;
> +
> + cloned_table = malloc(sizeof(*cloned_table));
> + if (!cloned_table)
> + return NULL;
> + *cloned_table = *table;
> + STAILQ_INIT(&cloned_table->addrs);
> + memset(&cloned_table->list, 0, sizeof(cloned_table->list));
> + if (table->peer_name)
> + cloned_table->peer_name = strdup(table->peer_name);
... doesn't it?
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/3] port: Don't leak transport when unicast initialization fails.
On Thu, Sep 26, 2019 at 03:54:30PM +0200, Miroslav Lichvar wrote: > Signed-off-by: Miroslav Lichvar Applied, but I also fixed two other goto labels further down. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/3] port: Avoid calling freed servo after switching PHC.
On Thu, Sep 26, 2019 at 03:54:31PM +0200, Miroslav Lichvar wrote:
> In port_synchronize(), when the clock returned SERVO_UNLOCKED and
> port_dispatch() triggered a switch of the PHC, the variable "s" would
> point to a servo which was already freed and the following call of
> servo_offset_threshold() would read invalid memory.
>
> Don't save the servo before dispatching the port.
>
> Signed-off-by: Miroslav Lichvar
> Fixes: 3f5f5653d796 ("port: Add interval update mechanism.")
Applied.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/2] phc_ctl: display all capability information
On Thu, Sep 26, 2019 at 10:47:21AM -0700, Jacob Keller wrote: > @@ -320,12 +320,16 @@ static int do_caps(clockid_t clkid, int cmdc, char > *cmdv[]) > " %d programable alarms\n" > " %d external time stamp channels\n" > " %d programmable periodic signals\n" > - " %s pulse per second support", > + " %d configurable input/output pins\n" > + " %s pulse per second support\n" > + " %s cross timestamping support\n", > caps.max_adj, > caps.n_alarm, > caps.n_ext_ts, > caps.n_per_out, > - caps.pps ? "has" : "doesn't have"); > + caps.n_pins, > + caps.pps ? "has" : "doesn't have", > + caps.cross_timestamping ? "has" : "doesn't have"); On an older kernel: Building m68k /home/richard/git/linuxptp/phc_ctl.c: In function 'do_caps': /home/richard/git/linuxptp/phc_ctl.c:318:2: error: 'struct ptp_clock_caps' has no member named 'cross_timestamping' make: *** [: phc_ctl.o] Error 1 Probably the easiest way to handle this is to cast to a local structure definition that is up to date... Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 0/2] pmc: Support querying TLV_PORT_PROPERTIES_NP
On Thu, Sep 12, 2019 at 11:06:28AM +, Petr Machata wrote:
> In commit 424bbde8fcca ("Custom management TLV PORT_PROPERTIES_NP"), a new
> TLV was added that allows introspection into PTP ports, and in particular
> translation from PTP port identifiers to system netdevice names. The TLV
> was added for phc2sys, and correspondingly pmc support was not added.
>
> However, translating from port IDs to netdevices is as useful to phc2sys as
> to end users. Besides just visually correlating what's what also for ad-hoc
> scripting and writing automated tests.
>
> This patchset therefore extends pmc to understand this TLV. In patch #1, a
> new helper is added that allows human-readable rendering of timestamping
> type, which is one of the reported properties. Patch #2 then extends pmc.
>
> Petr Machata (2):
> util: Add a function to render timestamp type
> pmc: Support querying TLV_PORT_PROPERTIES_NP
Series applied.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] port: Deal with higher-order sync/follow-up reordering
On Tue, Oct 01, 2019 at 10:00:42AM +0200, Miroslav Lichvar wrote: > On Mon, Sep 30, 2019 at 07:17:23PM -0700, Richard Cochran wrote: > > The delay between the Tx time stamp on the GM and the Rx time stamp > > must not exceed a small fraction of the sync. period, otherwise the > > servo on the slave becomes unstable. See Eidson 5.2.2. > > I think that depends on the servo and its configuration. I'm sure it's > possible to configure the PI servo to be stable with a delay of up to > an expected number of sync intervals. Whether it is possible is not the point. The analysis in the book shows that stable PI controllers can become unstable with excessive delay. Since the T in TC stands for "transparent", the expectation is that slaves will synchronize just as well when the GM is reached through the TC. If our TC implements queuing for HW that can't keep up with the Sync rate, then someone will be surprised when their well-tuned slave does not converge suddenly. That would make the linuxptp stack user-unfriendly indeed, and for this reason I won't support it. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Fri, Oct 11, 2019 at 07:23:38AM +, Y.b. Lu wrote: > I'm just not familiar how applications use 802.1AS synchronized time. I don't know of any open source applications using 802.1AS either! > For physical clock adjustment, I know we have /dev/ptpx device to access for > time. > For free running clock, I can see master_local_rr is used for master/local > rate ratio which makes sense for TC to synchronize frequency, > but for OC/BC/end instance, where to find the synchronized time. Is the > TIME_STATUS_NP info enough for applications? Given master_offset at ingress_time and cumulativeScaledRateOffset, you can calculate the remote time. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
