[ntp:hackers] Bypassing default synchronization

cedric gava gava.c at free.fr
Fri Jul 19 14:25:16 UTC 2013


Waou
I'll try to answer using the appropriate vocabulary, which is not my
domain : 
Our context is embedded system for vehicle application.

I think that what we want to implement is what you call a policy below 
> or are you trying to say that you are implementing a 
> policy that the initialization-event (as opposed to
> in-operating-period steering or offset-tracking events?)

On Thu, 2013-07-18 at 20:52 -0700, tsg wrote:

> On 07/18/2013 07:01 PM, Hal Murray wrote:
> > gava.c at free.fr said:
> >> If I try to be clearer : the first initialization of system clock is a
> >> particular process that shall take the max time of some other NTP servers.
> Lets ask whether this is about policies or process - are you trying to 
> say you will implement a feed process which will take a pre-detrmined 
> number of ticks?  or are you trying to say that you are implementing a 
> policy that the initialization-event (as opposed to in-operating-period 
> steering or offset-tracking events?)
> 
> >> Each server communicate is time using broadcast for a certain amount of
> >> time, and at the end of this period, they all take the date of the server
> >> which has the greater date.
> So this then has a polling loop which votes among the servers...
> >>    Our idea is either : to start ntpd, and playing
> >> with commands and traps, making it following this initialization process.
> There are all kinds of process control services which will do this, and 
> it can easily be implemented in Perl or Python as a standalone server so 
> its not that hard. Especially if you use openssl and the ssh services.
> 
> >> Or
> >> to change ntpd if we can't do with traps and commands...
> Yeah the traps (SNMP) have all the issues they have.

We had some troubles with SNMP ont he last project, and prefer not to
use it if possible.


> >>   We thought of a
> >> last idea : make a small program that uses libntp to initialize system clock
> >> following the process I mentioned before, and then start ntpd
> > I can't figure out what you are trying to do and/or why.
> he is trying to come up with a structured initialization process -the 
> real issue is why. There are a number of policy-specific reasons you 
> would want to do something like this inside of certain financial and 
> other control processes so that control nodes which fail to synchronize 
> can be taken out of the process loop... but that means that the 
> trust-envelope for the content being timestamped is limited to the 
> virtualized context of this single source environment.

Don't ask me why the customer want this... He does want it !


> 
> >
> >> shall take the max time of some other NTP servers
> > That sounds like a bad idea.  What are you going to do if some server that
> > you have chosen is broken and is serving the time 10 years in the future.

For the application, having the right time does matter less than having
a strictly growing time without jump, once synchronized... So, we can
have a date 10 years in the future. The only thing is that we can't have
a date in the past compared to the system time of any of the servers


> You are going to have an internal offset tied to that machine.
> 
> >
> > There is a long history of broken NTP servers.
> You mean the public ones?
> >   A major fraction of the
> > complexities of the reference NTP package is heuristics to avoid problems
> > like that.
> 
> Yes and this is one of the reasons that NTP is such a strong tool when 
> properly used.
> >   
> >
> >> We thought of a last idea : make a small program that uses libntp to
> >> initialize system clock following the process I mentioned before, and then
> >> start ntpd
> 
> You means something like NTPDATE 2.0??? I agree with Harlan's commentary 
> below. Its a waste of effort. There are java SNTP and Perl clients which 
> work great for a non-servo controlled timing-loop based time setting 
> (i.e. doing a jam set across a local network).

Our target language must be C++

> 
> > That seems unlikely to work any better than starting ntpd with the
> > appropriate command line switches.

Tha major issue for non NTP experts is to set the correct switches,
because we don't want some heuristic to take place of ours (particularly
the 10 years in advance...)

Cedric



More information about the hackers mailing list