[ntp:questions] Fudge time offset on client/peer?

Todd Glassey tglassey at earthlink.net
Sun Nov 8 21:04:10 UTC 2009


David Mills wrote:
> Danny,
>
> Sure you can in a couple of lines of code. However, where are you going 
> to put the result? The proto_config() call has a fixed number of fields 
> all tied up with data structures used for name resolution and for remote 
> configuration. The original plan, now only part way completed, was to 
> save everything in the parse ttree while the resolver is out to lunch, 
> then pick up where it left off when lunch is over. That would completely 
> resolve (no pun) the issue and allow an indefinate expansion in 
> configuration options.
>
> Dave
>   
Dave - per instance configurability for most all of the NTP control 
parameters is necessary to run NTP in the new OS instances being fluated 
about as Cloud and other massively parallelified (for lack of a better 
term) OS's. This means that interfaces will also allow for resources 
like CPU instances or other resources as whole embedded server instances 
like a B3 cluster to be specified. The issue with NTP is it s really 
only set up to run on a monolithic system instance and that is what is 
changing.

Take the B3 type clusters. These are automated bootable PXE style 
Beowulf clusters now being deployed in industrial automation systems 
with newSCADA on them [These are really cool systems because they 
dynamically grow and collapse based on HW availability. So the aggregate 
scheduler in NTP will need to be able to lock specific resources in the 
form of Run Time Services, Interfaces and Connectivity Rules].

These configurability controls we are working towards are partly 'there' 
today but we need more control with them. For instance in a cloud system 
there could be one server sitting in a specific location in the case to 
force more cooling into it so you would naturally use it as a more 
stable system to run the collective reference NTP instance for that 
server. To facilitate that one would need to be able to fully constrain 
NTP from the config file as to its run time characteristics.

You may also want to permanently lock it in memory as well and leave it 
in fast devices like ramdisks for tracking timing events and telemetry 
file data. So I should be able to say "for a NTP request from this 
interface, on this port, with this AutoKEY or other token, provide a NTP 
response of the type requested.". To do that I would need to be able to

    1)   Specify the Client-Interconnection Interface (CII): That means 
to "Specify Address Interfaces and Port control info"
    2)   And then per CII specify security controls for
          a) Time of Use and any linked
          b) Use Scopes (Authenticated or Anonymous)
                i) Specify the Token constraints and structure and any 
authentication mechanism; mas well as the associated
          c) Reporting requirements (OOB email etc).
    3)   Per CII specify system resources authorized including 
addressing receipt of payload 1 and 2, signed responses, and which CPU's 
or crypto service devices are to be used here.

The intent by the way is to allow for more control at the run-time level 
which is necessary to the rules of evidence and in creating a NTP which 
is better than the people that operate it as far as the forensic value 
of its time-service events goes.
> Danny Mayer wrote:
>
>   
>> Dave,
>>
>> Can we not just introduce an option on the server line for this? That
>> would effectively give you the association. The caviat here is how do
>> you know what to put in the argument?
>>
>> Danny
>> David Mills wrote:
>>
>>     
>>> Rich,
>>>
>>> I have the same situation you have, but a dedicated ISDN line and 
>>> routers that have a mostly symmetric delays. A per-association fudge is 
>>> not possilbe unless the peer mobilization code is overhauled. There is 
>>> in fact a calibration mechanism designed to compensate for small 
>>> inconsistencies using the PPS signal as the ultimate reference. That is 
>>> controlled by the enable/disable calibrate command and applies to all 
>>> associations. A command might be introduced that could affect a 
>>> specified association, but it would have to be given via ntpq after 
>>> mobilization.
>>>
>>> Dave
>>>
>>> Rich Wales wrote:
>>>
>>>
>>>       
>>>>> I suggest you don't want that.  What you need is a fudge on the
>>>>> interface, not the association.
>>>>>   
>>>>>
>>>>>
>>>>>           
>>>> In this situation, I think I really do want a fudge on the association.
>>>>
>>>> Consider the issue from the POV of my work desktop.  My work desktop
>>>> has a single network interface, connected to a conventional 100BASE-TX
>>>> ethernet network.  It has fast (and, for my purposes, sufficiently
>>>> symmetric) connectivity over my school's campus network to stratum-1
>>>> and stratum-2 servers run by the campus IT services.
>>>>
>>>> In order for my work desktop to see the stratum-1 server I'm running at
>>>> my home, however, it has to go over the campus network to the cable-modem
>>>> network servicing the townhouse complex where I live.  As I previously
>>>> mentioned, this cable modem network appears to have an asymmetry, which
>>>> I would like to fudge away for the benefit of my work desktop (but *not*
>>>> for my home LAN).
>>>>
>>>> If I were to fudge the network interface of my work desktop, this would
>>>> presumably affect not only its view of my home stratum-1 server, but also
>>>> my work desktop's view of the campus tickers.
>>>>
>>>> What I think I want/need is a way to fudge my work desktop's view of one
>>>> peer/server, but not another peer/server.  That's why I wanted to be
>>>> able to fudge an association.
>>>>
>>>> Rich Wales  /  richw at richw.org
>>>> _______________________________________________
>>>> questions mailing list
>>>> questions at lists.ntp.org
>>>> https://lists.ntp.org/mailman/listinfo/questions
>>>>
>>>>
>>>>
>>>>         
>>> _______________________________________________
>>> questions mailing list
>>> questions at lists.ntp.org
>>> https://lists.ntp.org/mailman/listinfo/questions
>>>
>>>
>>>
>>>       
>>     
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.425 / Virus Database: 270.14.53/2486 - Release Date: 11/07/09 07:38:00
>
>   




More information about the questions mailing list