Re: ClockTimeReport OS Clock Sync Not Running?

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

On Jan 4, 2021, at 5:26 PM, Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov> wrote:

Thanks for the info Andrew, yes my VM is running Ubuntu 18.04 which lines up with what you said about the ClockTimeReport.  I see you mentioned using ntpd or chrony for clock syncing (currently I have the windows host syncing with the NTP and then the VM syncs with the host) from within the VM.  

 

Is the way I have it set currently with windows connecting to the NTP not as good as using say ntpd to do it from within the VM? 

We run multiple Linux VMs on a large hypervisor-managed Linux cluster, and we measured how good the time-keeping was in our configurations because we wanted to minimize the jitter for operational reasons. Unless you’re seeing problems or are worried about getting millisecond accuracy your setup ought to be fine and may well be much better than running another daemon inside the VM.

Also if I have environment variable setup EPICS_TS_NTP_INET does this not give the IOC the ability to connect itself to the NTP directly instead of having the IOC grab the OS time (which is synced to the ntp through ntpd or through my windows host)?

No, that variable is only used by the NTP Time Provider, which is only run on embedded OSs and used to synchronize the OS clock to the NTP source. Our workstation OS Clock routines do not provide a way to set the system clock since that is a privileged operation, and the specialist daemons such as ntpd and Chrony are much better at synchronizing with NTP than our code is. The IOC code fetches the current time quite a lot, and reading that time over the network from an NTP source takes many milliseconds, so this would not be efficient or fast enough.

- Andrew

 

From: Johnson, Andrew N. <anj at anl.gov> 
Sent: Monday, January 4, 2021 1:32 PM
To: Manoussakis, Adamandios <manoussakis1 at llnl.gov>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: ClockTimeReport OS Clock Sync Not Running?

 

Hi Adam,

 

On Jan 4, 2021, at 2:42 PM, Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov> wrote:

 

Trying to understand how the timestamp is being placed in a record by looking at the ClockTimeReport and the generalTimeReport.  I also have been exploring using our NTP server with the IOC by setting the env variable EPICS_TS_NTP_INET to the NTP IP.  I may be understanding the reports incorrectly but wanted to make sure that without the NTP server at least the IOCs are syncing with the OS (my iocs are running from within a VM).  I do have the VM setup to sync with the OS.

 

What OS is your VM running? The time synchronization functionality in the IOC is *only* used on embed systems where the OS is VxWorks or RTEMS; if you’re running this IOC on Linux, Windows, MacOS or any other workstation OS the IOC code relies on the OS to keep its clock synchronized with whatever time sources you have available locally.

 

How I understand it if no NTP server is around the IOC will grab its timestamp based off the IOC Boot server (OS Clock?).  But the ClockTimeReport is showing

 

epics> ClockTime_Report             

Program started at 2021-01-04 12:22:24.937270

OS Clock synchronization thread not running.

 

I get the same result if I run that on a Linux-based softIoc. This is exactly what I expect to happen because the IOC will never try to do clock synchronization on Linux, you should be running a specialized daemon such as ntpd or Chrony to do that (we have found that using Chrony gives much lower clock jitter if the OS is actually running as a VM, although newer versions of ntpd might have improved since we actually compared the two).

 

We originally added the clock synchronization functionality to the IOC because VxWorks didn’t have the ability to do that itself at the time. The features in GeneralTime were designed to support several different methods of time synchronization that EPICS labs were using at the time on the various embedded OSs.

But the generalTimeReport seems to match my OS clock

 

epics> generalTimeReport

Backwards time errors prevented 0 times.

 

Current Time Providers:

    "OS Clock", priority = 999

                Current Time is 2021-01-04 12:24:51.784595.

 

Event Time Providers:

                No Providers registered.

 

Again that is the expected result on Linux.

 

- Andrew

 

 

-- 

Complexity comes for free, simplicity you have to work for.

-- 

Complexity comes for free, simplicity you have to work for.