List Info

Thread: Re: CR: NTP Time Overflow during livestream




Re: CR: NTP Time Overflow during livestream
country flaguser name
United States
2007-10-24 19:53:40
Yeah, the new change is good.

Thanks,
Jamie

Praveen.Thimmashettynokia.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:jgordonreal.com]

> Sent: Wednesday, October 24, 2007 2:09 PM
> To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas)
> Cc: ehychereal.com; client-devhelixcommunity.org;
> protocol-devhelixcommunity.org
> Subject: Re: [Protocol-dev] RE: [Client-dev] CR: NTP
Time Overflow
> during livestream
> 
> Praveen.Thimmashettynokia.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-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )