[ntp:questions] A proposal to use NIC launch time support to improve NTP

Ulf Samuelsson ulf at invalid.com
Thu Dec 20 23:41:30 UTC 2012


Brian Utterback <brian.utterback at oracle.com> wrote:
> On 12/20/2012 6:25 AM, Ulf Samuelsson wrote:
>> 
>>> Yes there is. The ntpd program has to set a timestamp in the outgoing
>>> packet and then specify the launchtime when it writes the packet. The
>>> goal here is to have the timestamp written in the packet exactly match
>>> the time the packet actually hits the wire. So, the timestamp in the
>>> packet must be a little in the future when it is written so that by the
>>> time the controller gets it the packet can be delayed until the right
>>> time. Since ntpd cannot access the clock in the controller,
>> 
>> The Network controller will timestamp the message in H/W as it arrives
>> and will add a CMESG with the timestamp, and this is supported in
>> ntpd since some time.
>> 
>> You add a small delay to the receive timestamp to make your launchtime.
>> 
>> systime does not get involved at any stage, and can be way off.
>> 
>> (Note that I am only interested in Stratum 1 server functionality)
>> 
> 
> You have to guarantee that the actual processing delay from controller 
> to controller is never more than .5 seconds minus your "small delay", 
> otherwise the timestamp will be off.  It would be a good idea to 
> synchronize the system clock so that you can detect that kind of situation.
> 

We found that an unoptimized system can handle about 50,000 packets per
second.
Have not digged that deep into ntpd, But so far, I have not seen any trace
of multithreading
operation, so I assume that this is a single core doing the job.
Processing a packet should not take more than 1 second / 50,000 = 20 us in
the normal case.

Then again, if you send 100s of thousands of packets per second to the
server, this will cause the system
to basically halt. I measured the server replies to less than 100 per
second in this case. This could cause 
false replies, unless the H/W drops a packet which is queued past its
launchtime.


> Also, if you are only going to be a stratum 1 server, from where are you 
> going to get the actual time? If you are only going to use the 
> controller timestamps then the controller better be disciplined to some 
> source of time. Some how something needs to be setting the time on the 
> controller.

I am not 100 % clear on how it is planned to be done.
If it can be accomplished, then the 1 PPS pulse should be synchronized with
UTC.
Then you only have to set the seconds counter in SYSTIM.
This can easily be done from any source.
Wait until you get the 1 PPS interrupts and then check time.

You have one second until seconds counter is updated again.
You will be in unsynchronized state until that happens, so your
timestamps are not to be trusted.


> 
> Brian.


-- 
Best Regards, Ulf Samuelsson



More information about the questions mailing list