[RE] Additional question on white paper
David,
In the function TimerTick on p.152, there is a statement
siPtr->baseTimer += ((siPtr->baseRate >> 24) + carry);
In the previous email, I indicated that baseRate holds a value equal to the
time for 2^56 clock cycles to elapse.
Since baseRate is right shifted by 24 bits in the above statement, we see
that when TimerTick is called, baseTimer
is incremented by a time equal to the period of 2^32 clock cycles, with
possibly 1 being added if carry is 1. Note that
this time is in seconds.
You indicate that TimerTick is called at a high clock rate, with time
between calls less than 20 ns. It seems to
me that when TimerTick is called, we want to add to baseTimer the value of
the time between calls. If we
are adding baseRate>>24, and given that baseRate was set to
2^56/clockFrequency, this means that we are calling TimerTick
every 2^32 clock cycles. In the example you gave where clockFrequency was 1
GHz/16, this means we call TimerTick
nominally every (2^32)(16)/1e9 seconds = (approximately) 68.7 seconds. For
a 1 GHz clock, we callTimerTick every 4.29 (approx) seconds. It seems
something here is not correct.
A second question concerns the value of carry; it seems it should be equal
to the granularity of the time increment we are adding each time (rather
than being equal to 1).
A third question is: how do you ensure that the time interval between
successive calls of TimerTick is equal to the value that gets added to
baseTimer on each call?
Is baseTimer intended to represent the current time expressed by the local
oscillator, to some granularity that we have chosen (the granularity would
be at least the period of the oscillator, but could be some multiple of
that)? In that case, we can express baseTimer in a simple manner as
follows. Define the following:
t = current time relative to some referernce, e.g., UTC
y = fractional frequency offset of the local oscillator relative to the same
reference t is expressed relative to (y is a pure fraction; we would
multiply y by 1e6 to get y in ppm).
T = granularity to which we are measuring time with the local oscillator
(expressed in the same units as t)
Then baseTimer, at time t, is given by:
baseTimer(t) = {floor[ (1+y)*t/T] }* T [ under the approximation that y
<< 1 (and here I use << to mean "much less than" and not "left shift");
floor(x) is the greatest integer less than or equal to x]
This can be interpreted as follows. t is the time relative to the reference
that we actually look at the value of baseTimer. If the local oscillator
were perfect and had zero granularity, then y=0, T->0, and baseTimer(t)=t,
i.e., it would read the exact value of time relative to the reference that
we looked at baseTimer. If now we let the local oscillator run with some
offset y, but still have zero granularity, then baseTimer reads t(1+y) if we
look at its value at time t relative to the reference. If we now introduce
granularity of size T, then baseTimer(t) increases in steps of size T; to
express this, we divide (1+y)t by T and truncate (i.e., take the floor), and
then multiply by T.
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>
Sent: Saturday, June 25, 2005 9:54 PM
Subject: Re: [RE] New white paper, with updates from Wednesday's meeting
> Geoff,
>
> A typo. It should be:
> > (1<<(uint64_t)56)/(double)(clockFrequency)
> ^ oops
> Thanks for checking.
>
> DVJ
>
> --- "Geoffrey M. Garner" <gmgarner@comcast.net> wrote:
>
>> David,
>>
>> On p. 149 of your latest document, you indicate that
>> baseRate is defined as:
>>
>> baseRate =
>> (1<<(uint64_t)56)*(double)(clockFrequency)
>>
>> and then give an example that, if clockFrequency =
>> (1GHz)/16, the
>> baseRate = 1,152, 921,504.
>>
>> Can you explain how you get this? If I put
>> 1<<(uint64_t)56 = 2^56, then
>>
>> baseRate = (2^56)(10^9)/16 = (approx) 4.5036e24
>>
>> I realize you don't indicate whether clockFrequency
>> is in GHz or in Hz. The
>> above has it in Hz; if
>> we put it in GHz, we get
>>
>> (2^56)/16 = 2^52 = (approx) 4.4.5036e15
>>
>> I tired working backwards, by factoring
>> 1,152,921,504 into primes; the
>> result is
>>
>> 1,152,921,504 = (2^5)(3)(7)(17)(43)(2347)
>>
>> I don't see how this relates to (2^56) multiplied by
>> a power of 10 and then
>> divided by 16.
>>
>> In addition, I can't resolve this by assuming
>> 1,152,921,504 might have a
>> typo in it, as the results above differ by at least
>> 6 orders of magnitude. Anyway, can you explain this
>> 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: Friday, June 24, 2005 7:45 PM
>> Subject: [RE] New white paper, with updates from
>> Wednesday's meeting
>>
>>
>> > All,
>> >
>> > I have updated the RE white paper, written by
>> > myself with numerous contributors, to include
>> updates
>> > from comments received on last Wednesday's
>> meeting.
>> >
>> > Great appreciation should be shown to Geoff
>> Garner,
>> > whose extensive review of C-code had forced me to
>> > run compiler checks and fix numerous bugs.
>> >
>> > Thanks also to Alexei, who reviewed and suggested
>> > changes to latency-constraints subclause.
>> >
>> > Since its hard to see one's own glaring mistakes,
>> > such reviewes are critical and greatly
>> appreciated!
>> >
>> > Copies can be found at:
>> > http://dvjames.com/esync/dvjReNext2005Jun24.pdf
>> > http://dvjames.com/esync/dvjReBars2005Jun24.pdf
>> >
>> > I assume Michael will (hint, hint) get these
>> posted
>> > on our IEEE site. Thanks, then, to Michael.
>> >
>> > Cheers,
>> > DVJ
>> >
>> >
>> >
>>
>>
>>
>
>