Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RE] Posting for discussion tomorrow



David,

I have some additional questions:

1) You said before that clockstrobe contains the incoming synch information 
from the upstream
node.  Then, I assume clockstrobe.diffrate is the rate difference of the 
upstream clock.  For now I'll
assume we can express this number as a pure fraction and not worry about its 
representation using
integer variables.  At the Grandmaster, I assume there is no received 
clockstrobe info; therefore, the
incoming diffrate is zero.  The variable temprate, which accumulates 
clockstrobe.diffrate, is therefore zero.
The locally computed diffrate = LIMIT(temprate, PPM250, -PPM250).  This 
value is therefore zero.

This means that the clockstrobe.diffrate value sent out by the GM is zero 
(see the line between 42 and 43 on p.10).
The first downstream clock from the GM therefore receives a 
clockstrobe.diffrate of zero.

It appears to me that this just propagates; I don't see how diffrate ever 
becomes nonzero at any downstream node.
I do see that there is a value diffrate1 that is computed, but this does not 
seem to influence the calculation of diffrate.

Can you explain how diffrate becomes nonzero?

2) What are the quantities csTime, csTimeA, csTimeB, myTime, myTimeA, and 
myTimeB?

3) You said that timer1 is not adjusted.  However, around lines 19-21 you 
adjust the variable tick by an amount
(tick*diffrate)<<NORM), which I assume is supposed to be tick multipled by 
freq offset expressed as a pure fraction.
This adjusted tick is then used to update timer1.  It seems that this 
represents an adjustment of timer1.

I think it would be desirable to re-express the algorithm using conventional 
equations, with all variables defined.

Thanks.

Best regards,

Geoff
---------------------------------------------
Geoffrey M. Garner
Samsung (Consultant)



----- Original Message ----- 
From: "David V James" <dvj@alum.mit.edu>
To: "Geoffrey M. Garner" <gmgarner@comcast.net>; 
<STDS-802-3-RE@listserv.ieee.org>
Sent: Wednesday, June 22, 2005 4:13 PM
Subject: RE: [RE] Posting for discussion tomorrow


> Geoff,
>
> Thanks for your detailed reading and most useful questions,
> particularly given the short review time. Most appreciated.
>
> I'll try to answer these herein, as you suggest, to assist
> in the resolution process.
>
> Comments interleaved.
>
> DVJ
>
>
>
>>> -----Original Message-----
>>> From: Geoffrey M. Garner [mailto:gmgarner@comcast.net]
>>> Sent: Wednesday, June 22, 2005 10:33 AM
>>> To: David V James; STDS-802-3-RE@listserv.ieee.org
>>> Subject: Re: [RE] Posting for discussion tomorrow
>>>
>>>
>>> David,
>>>
>>> I have begun reading your synch document and have some initial 
>>> questions.
>>> These are mainly
>>> to help me understand the document; I'll have more comments when I have
>>> finished.
>>>
>>> 1) You indicate in Section 2.1.5 that the local clocks are
>>> free-running and
>>> that PLLs are not used.  However,
>>> in Section 2.2 (e.g., figure 2.6 and the code in 2.2.3) you indicate 
>>> that
>>> the rate of the slave clock is adjusted based
>>> on the difference between its rate and the master rate.  It
>>> seems that this
>>> type of algorithm is essentially a PLL.  I realize
>>> you may not be using the timing produced by this PLL to time the
>>> PHY, but it
>>> seems it is still functionally a PLL, at least if the frequency
>>> adjustment
>>> of the slave
>>> is based on the phase difference between the phase of the slave and the
>>> phase indicated
>>> by the incoming timestamp from the master.
>
> Yes, it is a PLL, but its a bit different from a cascaded PLL.
> The key is that the incremental offset is based on errors from
> a non-PLL'd timer from the previous stage.
>
>
>>> 2) what is the difference between timer and timer1?  Are both being
>>> adjusted, or only one (and, in the
>>> latter case, which)?  Why are both needed?
>
> Only "timer" is adjusted. The timer1 value is not adjusted, but
> used to determine the incremental differences from the previous stage.
>
>
>>> 3) In the code in section 2.2.3, what is the structure clockstrobe, and
>>> where do its member values come from?  I.e., if the code is running in a
>>> slave, do
>>> the members of clockstrobe come from the upstream master?  What is the
>>> precise
>>> definition of the member clockstrobe.diffrate, and what are its
>>> units (e.g.,
>>> Hz?).
>
> The clockStrobe structure represents the contents of a received
> synchronization frame. The diffRate is a binary integer:
>  (error/interval)*4096*(1<<32)
> The idea is that its a percent-error, only a fraction that
> is scaled to the largest integer.
>
>
>>> I ask this because you have an expression rate = rate1+ (
>>> (rate1*diffrate)
>>>  >> NORM);
>>> it appears you are mutiplying 2 rates.
>
> The rate1*diffRate is the rate time the percent error, in a sense.
> Thus, if diffRate corresponded to 50PPM, then this value would
> represent rate1*50/1000000.
>
>
>>> In addition, what is the purpose of the right shift
>>> by NORM; NORM is defined to be 43, so I assume the quantity
>>> being shifted is not a 32 bit
>>> integer (K&R 2nd edition indicates that a shift is undefined
>>> when the amount of the shift is greater
>>> than the width of the data field).
>
> If one wishes to multiply a * b, and b is a binary signed fraction,
> then (in integers) this is (a * b) >> 31. And, yes, 64-bit values
> are used (long long with a GNU C compiler).
>
>
>>> My main reason for trying to read the code in detail, and therefore for
>>> asking the above questions, is that I want to understand the
>>> algorithm that
>>> governs how the rate and offset are adjusted.  If it is easier
>>> to provide an
>>> alternative explanation (e.g., using conventional mathematical equations
>>> with all variables defined), then it is not necessary to explain
>>> the code in
>>> detail (i.e., my main interest is in the algorithm).
>
> I'm starting to realize that, after reading you questions.
>
> Maybe it would have been better to use floating point values
> internally, and scale the numbers before they
> are included within a frame. That might work better.
>
>
>>> Two additional, minor comments are:
>>> 4) In your #define LIMIT (pp. 10 and 12) it appears the final b
>>> should be an a
>>> (i.e., I gather you want to set a equal to the upper or lower
>>> limit if a is outside the range, but
>>> leave a the same if it is within the range).
>
> Yes, you are correct. You can tell I haven't actually run the
> code yet, although we probably want to before we're done.
>
>>> 5) In the statememtn if ((i+=1) < TICKS) {
>>> should the < (less than) really be >= (greater than or equal to) ?
>
> Yes, again. You are reading carefully, which is much appreciated!
>
>
>>> As I indicated above, my main question is on how the algorithm
>>> for adjusting
>>> the phase and frequency of the slave clock works.
>
> Its basically:
>  1) Determine your offset-difference from the upstream timer
>     (not the timeOfDay).
>  2) Determine your rate-difference from the upstream timer1.
>  3) Add these differences to the values received form upstream
>     stations.
>  4) Use these values to generate your timer value.
>  5) Pass these values downstream.
>
> I'm always amazed by the first reviews, afterwards which I
> realize how unclear the text has been. That's the problem
> with being the author; almost anything appears to be obvious
> after days of work!
>
> Thanks again,
> DVJ
>
>
>
>>> Thanks.
>>>
>>> Best regards,
>>>
>>> Geoff
>>> -------------------------------------------------
>>> Geoffrey M. Garner
>>> Samsung (Consultant)
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "David V James" <dvj@ALUM.MIT.EDU>
>>> To: <STDS-802-3-RE@listserv.ieee.org>
>>> Sent: Tuesday, June 21, 2005 5:46 PM
>>> Subject: [RE] Posting for discussion tomorrow
>>>
>>>
>>> > All,
>>> >
>>> > I have posted a document for disucssion tomorrow.
>>> > This is available at:
>>> >  http://dvjames.com/esync/timer2005Jun21.pdf
>>> >
>>> > As announced in last week's minutes, details for
>>> > tomorrow's meeting should appear on the reflector
>>> > soon (Michael, hint, hint!).
>>> >
>>> > From past tradition, we expect:
>>> >  Teleconference of
>>> >  Synchronization Adhoc of
>>> >  IEEE 802.3 Residential Ethernet Study Group
>>> >  2005June22 14:00-16:00 PST
>>> >
>>> >  Meeting ID:          8023**
>>> >  Toll Free (US Only): + 1 877-827-6232
>>> >  International:       + 1 949-926-5900
>>> >
>>> >  Note:
>>> >   ** Represents digits whose value is TBD.
>>> >
>>> > DVJ
>>> >
>>> > David V. James
>>> > 3180 South Ct
>>> > Palo Alto, CA 94306
>>> > Home: +1.650.494.0926
>>> >      +1.650.856.9801
>>> > Cell: +1.650.954.6906
>>> > Fax:  +1.360.242.5508
>>> > Base: dvj@alum.mit.edu
>>> >
>>> >
>>> >
>>>
>>>
>
>