Re: [RE] Additional question on white paper
David,
If TimerTick is called at the rate of clockFrequency, then each time
TimerTick is called, baseTimer
should be incremented by the clock period, i.e., the time for 1 clock cycle.
However, as I indicated previously,
since baseRate holds a value equal to 2^56/clockFrequency, and since
baseTimer is incremented by the statement
siPtr->baseTimer += ((siPtr->baseRate >> 24) + carry), we see that we are
adding to baseTimer the quantity
2^32/clockFrequency, i.e., the time for 2^32 cycles. Is there some
additional scaling being done? The binary number stored in
baseRate, when right shifted by 24 bits, will be the time for 2^32 clock
cycles, not the time for 1 clock cycle.
My illustration of the relation between baseTimer and reference time t was
an attempt to show concisely how the quantity baseTimer is defined,
assuming my understanding of it is correct. I would have a better idea of
how the algorithm behaves if it is expressed in terms of a set of equations,
and this is the beginning of an attempt to do this.
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>; <dvj@alum.mit.edu>
Cc: <STDS-802-3-RE@listserv.ieee.org>
Sent: Sunday, June 26, 2005 12:47 PM
Subject: Re: Additional question on white paper
>
>
> --- "Geoffrey M. Garner" <gmgarner@comcast.net> wrote:
>
>> 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.
>
> TimerTick is called at a rate of approximately
> clockFrequency. I say approximately because this
> may vary by +-100PPM, based on crystal inaccuracies.
>
>> 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).
>
> The carry vaue is 1, since its sole purpose is to
> implement a wider addition based on narrow additions.
> Its simply the carry from the less-significant
> to the more-significant portion.
>
>> 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?
>
> Its called based on the crystal frequency.
> The baseRate value is a constant, representing
> the time expected between crystal ticks.
>
>> 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.
>
> I'm not sure what you are trying to say. If you are
> noting there is a quantization error, I would agree.
> Its accuracy is indeed limited by the length of the
> clock period.
>
> Is there something more that you meant to illustrate?
> Were you suggesting an alternative phrasing?
> I'm not disagreeing, I just don't understand.
>
> DVJ
>
>
>
>> 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
>>
> === message truncated ===
>
>