Re: [RE] Posting for discussion tomorrow
Geoff,
Points well taken.
I'll try to make things clearer on the next pass.
DVJ
>> -----Original Message-----
>> From: owner-stds-802-3-re@ieee.org
>> [mailto:owner-stds-802-3-re@ieee.org]On Behalf Of Geoffrey M. Garner
>> Sent: Wednesday, June 22, 2005 12:44 PM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: 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
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >
>> >