Menu
▾
▴
linuxptp-users
|
From: Nemo C. <nem...@gm...> - 2023-02-06 15:21:40
|
Hi Linuxptp-users, I am using gPTP 802.1AS profile for my network. My simplified network topology looks like this, TimeLeader --> Eth Switch (802.1as Time Aware Bridge)-->Processor (BC?)--->TimeFollower In the above topology, The processor runs linuxptp (ptp4l & phc2sys) has 2 interfaces. One interface should act as 802.1AS TimeFollower and other should act as 802.1AS TimeLeader. I know that IEEE1588 BoundaryClock has this feature. But I am not sure if 802.1AS (gPTP) has similar feature. Can you please share me details? If this is supported by LinuxPTP, can you please help me how would the configuration file look like? Thanks,Nemo |
|
From: Miroslav L. <mli...@re...> - 2023-02-06 16:01:59
|
On Mon, Feb 06, 2023 at 03:21:25PM +0000, Nemo Crypto wrote: > Hi Linuxptp-users, > I am using gPTP 802.1AS profile for my network. My simplified network topology looks like this, > TimeLeader --> Eth Switch (802.1as Time Aware Bridge)-->Processor (BC?)--->TimeFollower > In the above topology, The processor runs linuxptp (ptp4l & phc2sys) has 2 interfaces. One interface should act as 802.1AS TimeFollower and other should act as 802.1AS TimeLeader. I know that IEEE1588 BoundaryClock has this feature. But I am not sure if 802.1AS (gPTP) has similar feature. > > Can you please share me details? If this is supported by LinuxPTP, can you please help me how would the configuration file look like? IIRC gPTP has time-aware bridges which are equivalent to PTP boundary clocks. ptp4l as a boundary clock doesn't require any special configuration. For a gPTP example see configs/gPTP.cfg in the linuxptp tarball/repository. If your interfaces don't share a PTP clock, you will need to enable the boundary_clock_jbod option and run phc2sys to keep the two PHCs synchronized. However, that might not meet the gPTP requirements on accuracy. -- Miroslav Lichvar |
|
From: Nemo C. <nem...@gm...> - 2023-02-08 20:29:03
|
What does NIH mean? Not Invented Here?
On Wednesday, 8 February, 2023 at 10:18:21 am GMT-5, Richard Cochran <ric...@gm...> wrote:
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
|
|
From: Richard C. <ric...@gm...> - 2023-02-09 04:58:09
|
On Wed, Feb 08, 2023 at 08:28:54PM +0000, Nemo Crypto wrote: > What does NIH mean? Not Invented Here? yes. |
|
From: Miroslav L. <mli...@re...> - 2023-02-09 12:32:27
|
On Wed, Feb 08, 2023 at 07:18:17AM -0800, Richard Cochran wrote: > > 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. 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. The linreg servo has significant gain peaking and is not configurable, i.e. unsuitable for longer chains. The way I think about the BC vs TC performance is that with BCs the noise is filtered on each link and what passes to the end is smaller than the sum of noise on all links, which is what it gets with TCs. This assumes the sync interval is sufficiently short for the instability of the clocks to not dominate the errors. -- Miroslav Lichvar |
|
From: Nemo C. <nem...@gm...> - 2023-02-06 16:17:43
|
Hi Miroslav,
Thanks!
In my understanding of "Time Aware Bridge", it doesn't correct/adjust/tune the PHC. Is that not correct?
Nemo
On Monday, 6 February, 2023 at 11:01:51 am GMT-5, Miroslav Lichvar <mli...@re...> wrote:
On Mon, Feb 06, 2023 at 03:21:25PM +0000, Nemo Crypto wrote:
> Hi Linuxptp-users,
> I am using gPTP 802.1AS profile for my network. My simplified network topology looks like this,
> TimeLeader --> Eth Switch (802.1as Time Aware Bridge)-->Processor (BC?)--->TimeFollower
> In the above topology, The processor runs linuxptp (ptp4l & phc2sys) has 2 interfaces. One interface should act as 802.1AS TimeFollower and other should act as 802.1AS TimeLeader. I know that IEEE1588 BoundaryClock has this feature. But I am not sure if 802.1AS (gPTP) has similar feature.
>
> Can you please share me details? If this is supported by LinuxPTP, can you please help me how would the configuration file look like?
IIRC gPTP has time-aware bridges which are equivalent to PTP boundary
clocks. ptp4l as a boundary clock doesn't require any special
configuration. For a gPTP example see configs/gPTP.cfg in the linuxptp
tarball/repository.
If your interfaces don't share a PTP clock, you will need to enable
the boundary_clock_jbod option and run phc2sys to keep the two PHCs
synchronized. However, that might not meet the gPTP requirements on
accuracy.
--
Miroslav Lichvar
|
|
From: Richard C. <ric...@gm...> - 2023-02-09 19:38:06
|
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 |
|
From: Miroslav L. <mli...@re...> - 2023-02-13 09:41:17
|
On Thu, Feb 09, 2023 at 11:37:52AM -0800, Richard Cochran wrote: > 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. No, I don't remember doing that. I'd expect there to be a thick book written on this subject, likely from someone working in telco, with a conclusion that it's more practical to require all PLLs to have their gain peaking very small (e.g. 0.1 or 0.2 dB), assuming all chains of clocks are long. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2023-02-07 08:29:52
|
On Mon, Feb 06, 2023 at 04:17:30PM +0000, Nemo Crypto wrote: > Hi Miroslav, > Thanks! > In my understanding of "Time Aware Bridge", it doesn't correct/adjust/tune the PHC. Is that not correct? Looking at some freely available drafts of 801.AS, yes, it seems the clocks are supposed to be running free and correct timestamps with the accumulated offsets from the follow up info TLV. However, the example gPTP config doesn't have the free_running option enabled, so I'm not sure if the support is complete or maybe it's only for the end instances and not the bridges/relays. I have no experience with gPTP. -- Miroslav Lichvar |
|
From: Nemo C. <nem...@gm...> - 2023-02-07 13:49:56
|
Thanks Miroslav!
Then the actual question becomes, whether linuxptp has support for IEEE802.1AS Time Aware Bridge (Time Relay)?
Can any other expert comment please?
On Tuesday, 7 February, 2023 at 03:29:48 am GMT-5, Miroslav Lichvar <mli...@re...> wrote:
On Mon, Feb 06, 2023 at 04:17:30PM +0000, Nemo Crypto wrote:
> Hi Miroslav,
> Thanks!
> In my understanding of "Time Aware Bridge", it doesn't correct/adjust/tune the PHC. Is that not correct?
Looking at some freely available drafts of 801.AS, yes, it seems the
clocks are supposed to be running free and correct timestamps with the
accumulated offsets from the follow up info TLV. However, the example
gPTP config doesn't have the free_running option enabled, so I'm not
sure if the support is complete or maybe it's only for the end
instances and not the bridges/relays. I have no experience with gPTP.
--
Miroslav Lichvar
|
|
From: Richard C. <ric...@gm...> - 2023-02-07 15:53:15
|
On Tue, Feb 07, 2023 at 01:49:42PM +0000, 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 |
|
From: Nemo C. <nem...@gm...> - 2023-02-07 15:59:37
|
>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? I mean, the Time Follower that receives Sync/Followup from linuxptp's BC should never see any difference in the frames when compared to the frames it would receive if it is a 802.1AS Time Leader End Point. Please advise.
Thanks,Nemo
On Tuesday, 7 February, 2023 at 10:53:11 am GMT-5, Richard Cochran <ric...@gm...> wrote:
On Tue, Feb 07, 2023 at 01:49:42PM +0000, 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
|
|
From: Richard C. <ric...@gm...> - 2023-02-08 03:40:01
|
On Tue, Feb 07, 2023 at 03:59:23PM +0000, 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 |
|
From: Nemo C. <nem...@gm...> - 2023-02-08 20:26:20
|
Hi Richard,
Thanks for your valuable inputs. 802.1AS is chosen not for better performance in this particular case, but because we should be using Automovitve Profile and compliant to AVnu gPTP standard.But I agree with you, I am waiting for the prototype HW to see how ptp4l BC functions with other gPTP automotive grade devices and see how things work.Thanks,Nemo
On Tuesday, 7 February, 2023 at 10:39:51 pm GMT-5, Richard Cochran <ric...@gm...> wrote:
On Tue, Feb 07, 2023 at 03:59:23PM +0000, 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
|
|
From: Miroslav L. <mli...@re...> - 2023-02-08 08:34:05
|
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. BTW, synchronization with BCs can work better than TCs if the PLLs are well implemented and tuned. TCs are the simpler and safer approach. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2023-02-08 15:18:27
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X