[RE] More general question
David,
I have a more general question than the ones I've asked in my previous
emails.
he general exchange of timestamps that you describe, namely the aTx, aRx,
bTx, and
bRx, uses the same general principles as 1588. You could consider the
message b (slave)sends to a (master)
with aTx as being equivalent to Delay_Req, and the message a sends back to b
as being equivalent to Delay_Resp.
However, the details of your description and 1588 are different (e.g., 1588
also has the one-way messaging using synch and followup; you seem to avoid
the need for followup by always having the one frame delay present). The
question is: are you mainly interested in describing (or proposing) general
principles, in which case 1588 would be largely consistent with your
proposal, or are you proposing the precise details (detailed messages, frame
formats, etc.)?
Related to this, I am not yet certain if your offset and rate adjustment
algorithms are equivalent to or at least similar to what is typically done
in 1588 using servos. I need to understand your phase and rate adjustment
algorithms in more detail.
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: 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
>>> >
>>> >
>>> >
>>>
>>>
>