Yeah, the new change is good.
Thanks,
Jamie
Praveen.Thimmashetty nokia.com wrote:
> Hi Jamie,
>
> We can use complete 64 bit NTP time Stamp to calculate
the NTP Time or
> we can also use middle 32 bits to calculate brief NTP
Time. If we can
> handle calculation of NTP time by using 64 bit NTP Time
Stamp without
> any overflow, we should stick to this.
>
> Original CR was to use middle 32 bits of NTP Time Stamp
to calculate NTP
> Time.
> The change suggested by Eric, fixes the overflow
problem in
> NTPTime::ToMsec function that we were facing with 64
bit NTP Timestamp.
> This allows us to use complete 64 bit NTP Time stamp to
calculate NTP
> Time and avoids any changes to protocol.
>
> Following are the changes.
>
> UINT32
> NTPTime::toMSec()
> {
> // no checking for overflow
> double ms = (m_ulSecond * 1000.0);
> ms += ((double) m_ulFraction / (double)
MAX_UINT32) * 1000.0;
>
> + while (ms > MAX_UINT32_AS_DOUBLE)
> + {
> + ms -= MAX_UINT32_AS_DOUBLE;
> + }
>
> return (UINT32) ms;
> }
>
> Let me know if there are any concerns.
>
> Thanks
> Praveen
>
> -----Original Message-----
> From: ext Jamie Gordon [mailto:jgordon real.com]
> Sent: Wednesday, October 24, 2007 2:09 PM
> To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas)
> Cc: ehyche real.com; client-dev helixcommunity.org;
> protocol-dev helixcommunity.org
> Subject: Re: [Protocol-dev] RE: [Client-dev] CR: NTP
Time Overflow
> during livestream
>
> Praveen.Thimmashetty nokia.com wrote:
>> Does a specification (RFC) somewhere tell us to use
the middle 16
>> bits, or was this just a practical conclusion you
reached?
>>
>> Praveen: None of the RFC mentions about it. I did
found the usage in
>> other application.
>>
>
> I'm not sure exactly what usage this CR is trying to
fix, but the middle
> 32 bits is LSR (Last SR) calculation. LSR in RR/SR is
defined as the
> middle 32-bits of the NTP time of the last SR received.
(See the SR
> section of RFC 3550). So you'll want to make sure you
are correctly
> handling the full NTP time stamp for the client usage
and then also
> correctly calculating the corresponding LSR to send in
your receiver
> reports.
>
> Thanks,
> Jamie
_______________________________________________
Protocol-dev mailing list
Protocol-dev helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
|