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: | Change/Sync General Time Providers |
From: | Kyle Hesse via Tech-talk <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Wed, 20 Mar 2019 14:52:12 +0000 |
Hello Tech-Talk,
We have two IOCs, both mv2700s running EPICS r314123j0 that have OS Clock times in the future. Our NTP time is correct and it is set to a higher priority but is not syncing with the OS time. Is there a way to force synchronization of the two time providers at run-time? Or is there a way to forcibly set the current general time provider at run-time? Rebooting is an option, but I'm checking to see if there is a run-time solution. I've left some additional information below.
IOC command line:
#####generalTimeReport#####
vxwrks@ioc -> generalTimeReport 5
Backwards time errors prevented 315503 times.
Current Time Providers:
"NTP", priority = 100
Current Time is 2019-03-20 10:11:35.092046.
"OS Clock", priority = 999
Current Time is 2064-12-01 07:21:34.754838.
Event Time Providers:
No Providers registered.
value = 0 = 0x0
#####NTPTime_Report#####
vxwrks@ioc -> NTPTime_Report 2
NTP driver is synchronized with server
Syncronization interval = 60.0 seconds
Last synchronized at 2019-03-20 10:02:34.116603
OS tick rate = 60 Hz (nominal)
Measured tick rate = 59.997 Hz
NTP Server = XXX.XX.XXX.XX
value = 0 = 0x0#####ClockTime_Report#####
vxwrks@ioc -> ClockTime_Report 2
OS Clock synchronization thread not running.
value = 0 = 0x0
PV Status:
$(ioc):GTIM_CUR_SRC = OS Clock (***Is NTP on our functional IOCs***)
$(ioc):GTIM_HI_SRC = NTP
This is a strange one that seems to have come up before: https://epics.anl.gov/tech-talk/2017/msg01846.php Any advice or suggestions would be much appreciated. Thanks for your help, Kyle |