Subject: [TICTOC] Is there a need to syntonize the 1588v2 TCs with the GM clock

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 13 Mar 2008 20:43:48 +0200

Hi all,
I am curious about the need (or lack thereof) for the 1588v2 TCs to be
syntonized with the GM clock.
("Syntonized" means, of course, having a clock running at he same
frequency as the GM clock).
 
What would be the effect of having each TC on path between the GM to the
lave using its own clock for determining the value of the correction to
be stored in the appropriate field of the PTP packets? My gut feeling
that it could things much worse than not having any TCs inn the network
at all.
 
If syntonization of TCs with the GM is needed, would it mean that a kind
of bootstrapping process is required to make the TCs usable, starting
from he TCs that are adjacent to the GM and then going thru the network
all the way to the TCs that are adjacent to the slaves? 
 
Regards and thanks in advance,
             Sasha
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: [email-masked]
Date: Thu, 13 Mar 2008 12:01:17 -0700

Alexander,

Funny you should mention this. In the 1588 spec the TC syntonizing
requiment is not a shall but a may. If you take a tcxo with a 50ppm
accuracy and look at the say 10uS the 1588 packet is in the "residence"
period this amounts to about 1nS of clock error portential for ONE TC. If
there are 10 TC's and then a potential of 10nS is pretty much a given. If
the TC's need to syntonize to the GM and each one is casdaded off the first
one, then I can see lots of error and time for the syntonization process to
occur. Even worse if a link in the path is lost and the syntonizing process
needs re-calculate.

I am suspicious of the efficacy of the TC concept in large telecom WAN's.

I think the holy grail here is an end to end without "awareness" in the
path.

Pat

             Alexander                                                     
             Vainshtein                                                    
             <Alexander.Vainsh                                          To 
             [email-masked]>         <[email-masked]>                   
             Sent by:                                                   cc 
             tictoc-bounces@ie                                             
             tf.org                                                Subject 
                                       [TICTOC] Is there a need to         
                                       syntonize the 1588v2 TCs with the   
             03/13/2008 11:49          GM     clock                        
             AM                                                            

Hi all,
I am curious about the need (or lack thereof) for the 1588v2 TCs to be
syntonized with the GM clock.
("Syntonized" means, of course, having a clock running at he same frequency
as the GM clock).

What would be the effect of having each TC on path between the GM to the
lave using its own clock for determining the value of the correction to be
stored in the appropriate field of the PTP packets? My gut feeling that it
could things much worse than not having any TCs inn the network at all.

If syntonization of TCs with the GM is needed, would it mean that a kind of
bootstrapping process is required to make the TCs usable, starting from he
TCs that are adjacent to the GM and then going thru the network all the way
to the TCs that are adjacent to the slaves?

Regards and thanks in advance,
             Sasha_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Fri, 14 Mar 2008 04:34:47 +0100

Hi,

In IEEE1588 the TC syntonization is a "should".

The syntonization aims to limit the error in the RT measurement by
stabilizing the local clock.
As IEEE1588 targets equipments with cheap clock, the syntonization aims
to control the error.
The need for TC syntonization depends on the accepted level of error.
As the syntonization with GM is done thru message exchanges, adjustment
at one node can influence downstream nodes adjustment.

The TC syntonization has been strongly discussed during the first ballot
because 802.1AS does not plan to syntonize TC to the GM. Issues were
whiplash and gain-peaking problems associated with cascaded PLLs (aimed
to be in very cheap devices).
802.1AS should use free-running oscillator, compute rate observations
(no PLL control) and use 100Hz update frequency.

IEEE1588v2 left local clock syntonization (as well as the estimation of
rate relative to the GM) optional for TC.

Moreover the syntonization section of IEEE1588v2 also leaves the use of
physical signals as an option.

Use of TC-like function in large WAN may be useful.

Let's consider an operator A using an intermediate third party network
from operator B on the PTP path between opA's master and opA's slaves.
What can the opB do to help maintaining the opA time accuracy?
Using BC function would mean op B has to dedicate BC to the opA (or for
every customer willing to distribute its own precise time).
A TC-like equipment would be more... transparent (or universal) for OpB
and could be used for other customers of opB.

Wrt the TC syntonization, the opB TCs can not be syntonized to opA GM.
However we can assume that both operators are using Str1/G.811 sources
(PRC/PRS).
If we assume all the OpB TC are syntonized by such source (traceable
signal), the RT measurement should become stable (and accurate) enough
and better than free running + rate computations. 

This is just a guess as this has not been discussed at IEEE1588 WG.
TC-like clock performance would have to be characterized, most probably
by ITU-T.

.lm

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: jeudi 13 mars 2008 15:01
> To: Alexander Vainshtein
> Cc: [email-masked]
> Subject: Re: [TICTOC] Is there a need to syntonize the 1588v2 
> TCs with theGM clock
> 
> Alexander,
> 
> Funny you should mention this. In the 1588 spec the TC 
> syntonizing requiment is not a shall but a may. If you take a 
> tcxo with a 50ppm accuracy and look at the say 10uS the 1588 
> packet is in the "residence"
> period this amounts to about 1nS of clock error portential 
> for ONE TC. If there are 10 TC's and then a potential of 10nS 
> is pretty much a given. If the TC's need to syntonize to the 
> GM and each one is casdaded off the first one, then I can see 
> lots of error and time for the syntonization process to 
> occur. Even worse if a link in the path is lost and the 
> syntonizing process needs re-calculate.
> 
> I think the holy grail here is an end to end without 
> "awareness" in the path.
> 
> Pat
> 
> 
>                                                               
>              
>              Alexander                                        
>              
>              Vainshtein                                       
>              
>              <Alexander.Vainsh                                
>           To 
>              Sent by:                                         
>           cc 
>              tf.org                                           
>      Subject 
> I am curious about the need (or lack thereof) for the 1588v2 
> TCs to be syntonized with the GM clock.
> ("Syntonized" means, of course, having a clock running at he 
> same frequency as the GM clock).
> 
> What would be the effect of having each TC on path between 
> the GM to the lave using its own clock for determining the 
> value of the correction to be stored in the appropriate field 
> of the PTP packets? My gut feeling that it could things much 
> worse than not having any TCs inn the network at all.
> 
> If syntonization of TCs with the GM is needed, would it mean 
> that a kind of bootstrapping process is required to make the 
> TCs usable, starting from he TCs that are adjacent to the GM 
> and then going thru the network all the way to the TCs that 
> are adjacent to the slaves?
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 17 Mar 2008 17:15:35 +0000

[email-masked] wrote:
> there are 10 TC's and then a potential of 10nS is pretty much a given.
If your goals is guaranteed 1us - then this is not too bad.

>  If
If you are worried about phase hits the you should be locking to 
multiple references.
> I am suspicious of the efficacy of the TC concept in large telecom WAN's.
I am more worried about how to find the timing packets in this environment.
> I think the holy grail here is an end to end without "awareness" in the
Of course.

Stewart

---

From: jikuiwen 24438 <[email-masked]>
Date: Wed, 19 Mar 2008 10:41:17 -0400

[email-masked] wrote:

> > accuracy and look at the say 10uS the 1588 packet is in the 
> "residence"> period this amounts to about 1nS of clock error 
> portential for ONE TC. If
> > there are 10 TC's and then a potential of 10nS is pretty much a 
> given.If your goals is guaranteed 1us - then this is not too bad.
> 
Yes, 10ns seems not to bad.

> If you are worried about phase hits the you should be locking to 
That's why we need a good timing distribution and protection mechanism.

> I am more worried about how to find the timing packets in this 
> environment.> I think the holy grail here is an end to end without 
> "awareness" in the
> > path.
> >
> >   
> Of course.
E2ETC is a simple solution since E2ETC node just calculate residence-time of itself. It can be used in wide and large network. 
P2PTC is something different. It's better to be used in a well-programming network.