[ntp:hackers] Bypassing default synchronization - lets put this to bed!

tsg tglassey at earthlink.net
Fri Jul 19 15:15:43 UTC 2013


On 07/19/2013 07:25 AM, cedric gava wrote:
> Waou
> I'll try to answer using the appropriate vocabulary, which is not my 
> domain :
> Our context is embedded system for vehicle application.

OK - is the issue synchronizing the various wire-line or 
control-systems? i.e. is this a complex vehicle control system which has 
multiple controller-instances in various areas (as you would in a ship 
or a train or perhaps a commercial-truck type system?

>
> I think that what we want to implement is what you call a policy below

OK - so this can be done in a couple of ways with NTP or SNTP and 
configuring them. I agree with Harlan that you really dont need to do 
anything fancy with creating new synchronization protocols or using NTP 
outside of its comfort-zone.

What I would do is define the policy you want to implement in detail - 
write it out at a high level and then block out a process casually on 
paper (draw yourself a work flow process diagram).

Its actually pretty simple what they are asking for, a controlled 
NTP-protocol session using policy controls (pertaining to synchronous 
timesettings as opposed to asynchronous ones) which are not generally 
available within NTP itself.

As to the SNMP thing - yeah I totally hear that. I generally use one of 
the Nagios or Cacti extensions for those control instances and its 
pretty simple to set them up.


/*Cedric - If you want when you have that Workflow diagram showing 1) 
the nodes, or the controller types and 2) OS environments (even if its 
embedded Linux or Windows or something smaller like Mach64 or...) and 
the timing constraints for each node - send me a copy and I will write 
the process rule set and you can use it to setup the scripts. */

Todd

> > 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  <mailto: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
>


-- 
// Standard "perasonal email" disclaimers apply



More information about the hackers mailing list