[ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

Tue Nov 13 04:30:34 GMT 2007

Karen,

As engineering principle, the only really accurate timetag is the SOF 
octet, which 1588 uses. Using any other octet is not a good idea, as it 
could be affected by coding in some technowledgy as well as jitter and 
clock skew. My best example why this is really the only choice is space 
links, which get heavy duty coding. The issue then is where is that 
precious octet you want to find in the midst of interleaved, 
convolutional coding? I recommend we specify the timetag point as a 
media and protocol issue, perhaps in an annex.

Dave

Odonoghue, Karen F CIV NSWCDD, W13 wrote:

> That's true for today; however, the discussion at the meeting was more 
> along the lines of if someone in the future built hardware that could 
> do this, they would need to know what point was the "transmission 
> event". Currently, this is an estimate based on the issues you 
> mentioned, but it could be more precise in the future. The suggestion 
> was made that we go ahead and specify this. It doesn't impact current 
> implementations, but it does provide some needed specification should 
> someone pursue this approach. Do you think a clarification is needed 
> on the text Rich provided to address this?
>
> Karen
>
> ________________________________
>
> From: ntpwg-bounces+karen.odonoghue=navy.mil at lists.ntp.org on behalf 
> of David L. Mills
> Sent: Mon 11/12/2007 10:05 PM
> To: ntpwg at lists.ntp.org
> Subject: Re: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes
>
>
>
> Karen,
>
> With all due respect, we don't get to do this with current operating
> systems and NICs. All we can do is retrieve the kernel time after
> receiving a packet and before sending a packet. The operating system
> doesn't know when the first octet (SOF) of the frame arrives or departs
> unless the NIC tells it so, which is what 1588 hardware does. Even with
> 1588 we can't infer when any particular octet within the packet was sent
> or received unless we know icky details about the bit rate, etc.
>
> Dave
>
> Odonoghue, Karen F CIV NSWCDD, W13 wrote:
>
>> Just out of curiosity, if there isn't a strong rationale to differ
>> from 1588 why would we do so. Part of the point of this would be to
>> potentially leverage hardware in the future. If 1588 and 802.1AS
>> define the same timestamp point, why would we differ?
>>
>> Karen
>>
>> ________________________________
>>
>> From: ntpwg-bounces+karen.odonoghue=navy.mil at lists.ntp.org on behalf
>> of rich.osman at nsn.com
>> Sent: Mon 11/12/2007 8:20 PM
>> To: ntpwg at lists.ntp.org
>> Subject: Re: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: ntpwg-bounces+rich.osman=nsn.com at lists.ntp.org
>>> [mailto:ntpwg-bounces+rich.osman=nsn.com at lists.ntp.org] On
>>> Behalf Of ext Jim Martin
>>> Sent: Thursday, November 08, 2007 3:47 PM
>>> To: ntpwg at lists.ntp.org
>>> Subject: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes
>>>
>>> Gentlepeople,
>>> Based upon the notes (and my recollection) from the meeting in
>>> Chicago, there were four main points to be addressed in the
>>> next (and
>>> hopefully final) rev of the protocol spec. They were:
>>>
>> <stuff deleted>
>>
>>>> -Comment from Stewart Bryant: need to specify precisely the start
>>>
>> bit
>>
>>>> * Yakov and Stewart Bryant agreed to contribute text to resolve this
>>>
>>>> issue
>>>
>>> This is where I'm looking for input from the community. Yakov,
>>> Stewart, Rich Osman, or anyone who has a good grasp on the issue and
>>> can generate a few lines to precisely characterize the
>>> details. This
>>> is currently the blocker on getting this out.
>>
>>
>> NTP has a lot in common with IEEE-1588 and there can be value in
>> consistency if it isn't foolish.
>>
>> IEEE P1588 D2.2 paragraph 7.3.4.1 "Event message timestamp point" says:
>> "Unless otherwise specified in a transport specific Annex to this
>> standard, the message timestamp point for an event message shall be the
>> beginning of the first symbol following the start of frame delimiter."
>>
>> I'd propose that the leading edge of the first bit of the LI Leap
>> Indicator (first transport independent point) of the NTP packet header
>> as shown in Figure 8 be the reference point. This isn't completely
>> consistent with 1588, but I believe it's consistent with the intent and
>> with the rest of NTP. Regardless of where it ends up, it should be in
>> the first 12 words of the message so that there is no need to compensate
>> for varying message lengths. A brief look at some sample code seems to
>> indicate that this is about the location that assumed but I've done no
>> exhaustive or scientific search.
>>
>> Given the structure of the document I believe that the end of section 4
>> "Definitions" is probably the best place to include the text: "The
>> timestamp reference point is the leading edge of the first bit of the LI
>> Leap Indicator bit pair of the NTP packet header shown in Figure 8."
>>
>> --
>>
>> Rich Osman
>> Nokia Siemens Networks
>> mailto:rich.osman at nsn.com
>> 6000 Connection Drive; Irving, TX 75039
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg
>
>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
>
>
>