Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RE] New white paper, with updates from Wednesday's meeting



David,

I do see that with the fix, baseRate comes out to the value given.  But, 
with this definition, the quantity baseRate
actually is a time.  Specifically, given that clockFrequency is in Hz, 
baseRate is the time in seconds for
2^56 cycles to occur.  Since flexRate is defined as 
baseRate+baseRate*normDiffRate, flexRate is also a time.

Is this correct?

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