1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 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 <2017> 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: time stamp on vxWorks jumping to the future |
From: | Dirk Zimoch <[email protected]> |
To: | Michael Davidsaver <[email protected]> |
Cc: | [email protected] |
Date: | Mon, 27 Nov 2017 09:47:37 +0100 |
On 24.11.2017 17:04, Michael Davidsaver wrote:
On 11/24/2017 01:50 AM, Dirk Zimoch wrote:On 20.11.2017 11:10, Dirk Zimoch wrote:Hello everyone, From time to time we see a strange problem with the timestamp on our vxWorks 5.5 IOCs. The timestamp jumps to the future (e.g. 2071). I have seen it happen on EPICS 3.14.12 as well as 3.14.8. Not all but more than one IOC seem to be affected from such an incident. Not all jump to the same future time. Has anyone else seen this effect? Can a corrupted NTP message cause this? DirkExample: ZPSAF15-VME > NTPTime_Report 1 NTP driver is synchronized with server Syncronization interval = 60.0 seconds Last synchronized at 2017-11-24 08:45:29.149741 OS tick rate = 100 Hz (nominal) Measured tick rate = 100.024 Hz NTP Server = 129.129.190.1 value = 0 = 0x0 ZPSAF15-VME > date 2073/05/20 11:20:31.396217 value = 27 = 0x1b Time jumped this night, only on this IOC.Are there other time providers in this IOC? What does "generalTimeReport 5" show?
The system has been restarted meanwhile, but here is the report: ZPSAF15-VME > generalTimeReport 5 Backwards time errors prevented 2169 times. Current Time Providers: "NTP", priority = 100 Current Time is 2017-11-27 09:46:31.885855. "OS Clock", priority = 999 Current Time is 2017-11-27 09:46:31.885192. Event Time Providers: No Providers registered. value = 0 = 0x0