[ntpwg] NTP Follow-up packet details

[David L. Mills]

Suart,

1. It's not done as you may suspect. The design first calculates the 
offset using client/server mode, then computes an artificial "delay" by 
comparing the client/server offset with the apparent broacast offset. 
This was done for the very reason you cite, the broadast spanning trees 
with DVMRP and SPIM with the once popular IP multicast were far 
different than the unicast spanning tree.

2. If you can burn per-client state, then why not use symmetric mode and 
ignore the offset for either direction as necessary.

Dave

STUART VENTERS wrote:

> Dave,
>
> Thanks for the link to the whitepaper, it cleared up a lot.
>
> Seems like a nice interleaving plan given the assumptions it started from,
> but I'm not sure about 2 of the assumptions.
>
> 1)It appears to me that it's risky to transfer time
> with a combination of unicast and broadcast switching modes.
> These two different modes may be forwarded
> with different queueing and scheduling strategies.
> While the differences may be small,
> they could be important if you are interested in sub-microsecond 
> accuracies.
> I wonder if the telcom profiles for PTP reflect this
> in a preference for unicast only transfers?
>
> 2) I was looking for a client-server interleaved mode,
> but this is ruled out by the assertion that the server must be stateless.
> So far, NTP has been well served with a stateless server.
> The per-client memory requirements for interleaving seem modest.
> NTP must remain scalable to large numbers number of clients.
> I wonder what's a large number for applications requiring interleaving?
>
> Regards,
>
> Stuart
>
>
> DAVE MILLS wrote:
>
>> Stuart,
>>
>> See the white paper http://www.eecis.udel.edu/~mills/onwire.html on the
>> NTP project page. The interleaved options have been implmeneted and
>> tested in thedevelopment version. See the xleave option on the server
>> documentation page.
>>
>> In the current code the interleaved modes avoid the message digest
>> latency as well as the output queuing delays. However, for the most
>> precise performance the drivers, in particular the ethernet driver
>> interface code needs to be modified. For the best performance hardware
>> timestamps would be required and the interleaved code can handle that if
>> available.
>
>
>> ***: The department has disabled access to our campus news server, so I
>> can't read the newsgroup. I have no explanation why staff did that and
>> they don't answer my mail. At last for the present, you should copy my
>> campus mailbox mills at udel.edu.
>>
>> Dave
>>
>> STUART VENTERS wrote:
>>
>>> Dave,
>>>
>>> I'd like to understand your plan for NTP follow up timestamping.
>>>
>>> (On the ntp.org it appears that the details are still to be worked out.)
>>>
>>> It appears that for a simple server to client time transfer,
>>> the following rules might cover it:
>>>
>>> 1) If the client receives a server packet with T3 < T2,
>>> then the server is using follow-up timestamping.
>>> (Which means that the T3 value is not for this transaction,
>>> but rather for the previous on in this session.)
>>>
>>> 2) A session is identified at by a unique set of
>>> server IP address and UDP port,
>>> and client IP address and UDP port.
>>>
>>> 3) Since we are only trying to transfer time to the client,
>>> the client doesn't need an accurate value for T1 in it's request packet,
>>> so we don't need follow-up for T1.
>>>
>>>
>>> Are these rules reasonable / inline with what you were thinking?
>>>
>>>
>>> Regards,
>>>
>>> Stuart
>>>
>>>
>>>
>