EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: time stamp on vxWorks jumping to the future
From: "Zimoch Dirk (PSI)" <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Tue, 28 Nov 2017 22:41:31 +0000

Am 28.11.2017 um 18:35 schrieb Andrew Johnson <[email protected]>:

On 11/28/2017 11:03 AM, Hartman, Steven M. wrote:

On Nov 27, 2017, at 9:04 PM, Michael Davidsaver <[email protected]> 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.

I have added a sanity check now in my copies of EPICS 3.14.8 and .12 to refuse 1 hour+ jumps and log an error message instead. Let‘s see what I get ...


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?

No idea. My NTP server is the network router for our subnet from PSI IT department. Before I blame them I want to have proof. 😉


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

We had time problems on SL6 VMs because the virtual machine did not understand clock throttling of the physical host. That is solved now, basically using the vmware tools properly. But this is unrelated.


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

References:
time stamp on vxWorks jumping to the future Dirk Zimoch
Re: time stamp on vxWorks jumping to the future Dirk Zimoch
Re: time stamp on vxWorks jumping to the future Michael Davidsaver
Re: time stamp on vxWorks jumping to the future Dirk Zimoch
Re: time stamp on vxWorks jumping to the future Michael Davidsaver
Re: time stamp on vxWorks jumping to the future Hartman, Steven M.
Re: time stamp on vxWorks jumping to the future Andrew Johnson

Navigate by Date:
Prev: RE: EDM Hoff Video Widget and Bits Per Pixel Mark Rivers
Next: Tab Container set focus Amien WORK
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: time stamp on vxWorks jumping to the future Andrew Johnson
Next: Possible bug in areaDetector/ADSupport/supportApp/nexusSrc/Makefile? Jörn Dreyer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024