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
>> >
>> >
>> >
>>
>>