Experimental Physics and Industrial Control System
On 11/27/2017 02:47 AM, Dirk Zimoch wrote:
>
>
> 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?
>>>>
>>>> Dirk
>>>>
>>>
>>> Example:
>>> 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
It seems odd to trip the backwards time detection with only one time provider.
Of course this may due to the local oscillator (decrementer) is running
slightly fast than 100Hz.
> Backwards time errors prevented 2169 times.
>>>> Has anyone else seen this effect?
I saw something like this from an EVR where reading the current time occasionally
resulted in a vme bus error (a firmware issue long fixed). As a result of this the
mrfioc2 time provider does some fairly strict tests to avoid returning a bad time to
generalTime. If this sort of thing happens again, it might be worthwhile to add some
additional sanity checking to the NTP provider.
>>>> Can a corrupted NTP message cause this?
This depends on how much, if any, validation is done by sntpcTimeGet().
- Replies:
- Re: time stamp on vxWorks jumping to the future Maren Purves
- Re: time stamp on vxWorks jumping to the future Hartman, Steven M.
- 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
- Navigate by Date:
- Prev:
Driver for the SM300 john.holt
- Next:
Re: time stamp on vxWorks jumping to the future Maren Purves
- 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
- Navigate by Thread:
- Prev:
Re: time stamp on vxWorks jumping to the future Dirk Zimoch
- Next:
Re: time stamp on vxWorks jumping to the future Maren Purves
- 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