Re: time stamp on vxWorks jumping to the future

[Andrew Johnson <anj@aps.anl.gov>]

On 11/28/2017 11:03 AM, Hartman, Steven M. wrote:
> 
>> On Nov 27, 2017, at 9:04 PM, Michael Davidsaver <mdavidsaver@gmail.com> wrote:
>>
>> On 11/27/2017 02:47 AM, Dirk Zimoch wrote:
>>
>>>>>> Can a corrupted NTP message cause this?
>>
>> This depends on how much, if any, validation is done by sntpcTimeGet().
> 
> 
> Very little validation. Nothing to check if the reported time is sensible as compared to the previously known local time. 
> 
> Dirk, what type of device is your NTP server and where does it get its time? I recall that SNS had a GPS for the timing system which worked fine for the timing system’s time stamp, but it wasn’t considered reliable to use as an NTP server. Can you monitor what your NTP server is reporting? 
> 

This might be completely irrelevant to this issue, but at APS we
discovered that running ntpd on RHEL7 on a VM the times given out to NTP
clients were really noisy (ntpd doesn't understand hypervisors). By
switching to the newer Chrony package we got much nicer results, the
server locks much more quickly and closely than ntpd (Chrony doesn't
support the same obscure high precision clock hardware that ntpd does,
but we don't need them).

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon