Wolfgang, In general I am not aware of any issues regarding AS compatibility. We tried very had to follow the standard as closely as possible. Delio (on CC) might have more to say about this. He maintains his own AS branch on github.
https://github.com/audioscience/linuxptp I just briefly compared v1.4 with his asi1230-master, and nothing earth shaking stood out. On Mon, Oct 31, 2016 at 08:58:57AM +0100, Wolfgang Wallner wrote: > Do I need any further permissions for my sourceforge account to view the > archives? I just fiddled with the SF settings for the lists. Can you see it now? (I have been recommending gmane instead, but that site went down.) > LinuxPTP 802.1AS issues: > > 1) phc2sys does not work if transportSpecific is set to 1 > > When I set transportSpecific to 1 (as required by 802.1AS) in my config file, > the phc2sys tool does not work. > My test config file looks as follows: > > $ cat TestConfig.cfg > > [global] > transportSpecific 1 > > When I call ptp4l with "sudo ptp4l -f TestConfig.cfg -i enp2s0 -p > /dev/ptp0 -m" (without that config file) and phc2sys with "sudo > phc2sys -a -r -r -m -S 0.2 -F 0.2" it only prints > "phc2sys[5236.261]: Waiting for ptp4l..." every second. If I start > ptp4l without that config file or comment out that one line, phc2sys > works as expected. Can you try this instead? [global] [enp2s0] # # Not in the global section! # transportSpecific 1 This is bug where the gloabl transportSpecific setting is being applied to the UDS interface. I'll fix this soon. > 2) Differences in the BMC algorithm > > Is it possible to specify a different best master clock algorithm than that > of the default PTP profile? No, not yet. I have some patches in the works for allowing different BMC variants, because some profiles will require it. However, the AS mode should work fine with the default BMC... > The BMCA of the default PTP profile and 802.1AS are similar, but not the same. > Noticable differences are: > > *) There is no pre-master state in 802.1AS This only causes a master to wait an additional announce period before sending the first announce and sync messages. It doesn't affect how we inter-operate in a gPTP network. > *) There is no foreign master qualification in 802.1AS Again, this doesn't affect correctness WRT how we inter-operate. This only affects the slave, causing a short delay before starting (internal) synchronization. > *) If a master stops sending sync messages but still sends announce messages, > this should trigger a state change in the slave according to 802.1AS > (configured via syncReceiptTimeoutTime), while it is fine in default PTP. This is implemented. Did you test this? > 3) PDelay uses wrong clock > > 802.1AS specifies in 11.1.2 the following: > > "In practice, t1 and t4 are measured relative to the LocalClock entity of the > initiator time-aware system, and t2 and t3 are measured relative to the > LocalClock entity of the responder time-aware system." > > The LocalClock in 802.1AS is a local free running oscillator, in contrast to > the recovered clock that is created via PTP. > However, I see in the t2 and t3 timestamps of my LinuxPTP instances times > refering to the time that is transfered via PTP. No, the interval T3-T2 is converted into the local time base. See get_raw_delay(). > 4) Path Trace TLV > > Announce messages without a Path Trace TLV are ignored by my device if I set > path_trace_enabled to 1. > I think in 802.1AS a Path Trace TLV should be attached to announce messages, > but announce messages should not be dropped if a received message does not > have one. First you complain that we don't follow AS exactly, and then you complain that we *do* follow it exactly! Path Trace is specified in 10.5.3, and there is no hint of it being optional. In fact, this is required in the PICS. Any master who sends an Announce must conform. Look at page 240. MIMSTR-8 Does the Announce message body comply with the requirements in 10.5.3.1 and Table 10-7? @Delio, I see you allow announce without the TLV: https://github.com/audioscience/linuxptp/commit/0b6d8ca73332391af9bddc25177df254b066d669 Can you tell us why? > 5) The PPS signal produced by the i210 seems to be unreliable > > I know that the right place to discuss i210 problems would be LMKL, I just > mention this here as I assume several of you might have experience with this > chip. > I observe that if I enable the PPS signal on the software definable pins of > the i210 it initially works fine. > But if there are state changes in the PTP stack because I unplug/replug other > devices to the network, the PPS signal of the i210 can disappear. > Calling the corresponding ioctls again (and thus setting the register of the > i210 again) restores the signal. > Does this match your experience? Yes. You must stop and restart again whenever the time jumps. You should write a script to monitor ptp4l and restart when needed. Thanks, Richard ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
