Conference vaxaxp::vmsnotes

   Why is a real-time process altering the system clock?  Particularly
   in a time-critical context?  (There are products that can "dither"
   the clock to the current value, and there are ways to keep system
   clocks closely synchronized.)  What is the task behind this question?

   Depending on what is going on, this call can update the running
   clock, it can update the BBW (Alpha) or TOY (VAX) clock, and (on VAX)
   it can perform and I/O to update the year in the saved system image.

   The underlying code must be executed on the primary processor in an
   SMP environment, as that is the only processor that has access to
   the system clock.

   If you *really* need this to be predictable, force the thread of
   execution over to the primary processor (possibly via a kernel-mode
   fork thread or via the processor affinity routines in recent OpenVMS
   releases), and execute the sys$setime call there...

   What OpenVMS version?

  Jacques,

> I could measure the execution
>    	time of the sys$settime function call could take from 200 ms to 1.5s.
>    	Why this time value is not stable ?

    dumb question, but how are you measuring the elapsed time? Consider that
  if you're using the same clock that you're setting, the time measurement is
  not valid as it will include whatever change you made to the clock.

						John Gillings, Sydney CSC

Hi,

	First, the system is running on OpenVMS V6.2.

	The aim of the process is to get the time value through a RS232 line 	
	from an equipment named	AEC-BOX, receiving the time value on a radio 	
	signal.

	Each hour, the system is waked up, read the AEC-BOX and setup the system
		clock. After that, the cluster time is set  by the SYSMAN
utility.

	NTP assumes the system clock is propagated to the other computers 	
	connected on the network.

	I need the process runs at real-time priority because the time 
	elapsed from the AEC-BOX access to the setime execution must be 
	constant.

	I detect the setime execution time is variable because the system clock 
	could be up to 1 second late in comparaison with the AEC-BOX and the 
	AEC-BOX access time is around 150 ms with a 50 ms variation. So I deduce
		the setime execution time is not constant. 

	Thanks a lot and best regards,

	Jacques

:	The aim of the process is to get the time value through a RS232 line 	
:	from an equipment named	AEC-BOX, receiving the time value on a radio 	
:	signal.

   A time-server, in other words.

:	Each hour, the system is waked up, read the AEC-BOX and setup the
:       system clock. After that, the cluster time is set  by the SYSMAN
:       utility.

   Tools to perform this task are already available, and a mechanism
   by which one can drift the clock to the correct time is available.
   (This mechanism is used by the NTP and DECdtss applications...)

   "Chunking" the current time value in large increments -- as is currently
   being done -- can create some interesting problems -- CMS will start
   reporting errors, as will the file system, as will any applications
   that are expecting increasing timestamp values.

:	NTP assumes the system clock is propagated to the other computers 	
:	connected on the network.

   Correct.  SET TIME does not work on systems that are receiving the
   time from other nodes via DECdtss or NTP.

:	I need the process runs at real-time priority because the time 
:	elapsed from the AEC-BOX access to the setime execution must be 
:	constant.

   It's not, and it very likely won't be -- there's too much going
   on "underneath" the call, including disk I/O.

:	I detect the setime execution time is variable because the system clock 
:	could be up to 1 second late in comparaison with the AEC-BOX and the 
:	AEC-BOX access time is around 150 ms with a 50 ms variation. So I deduce
:		the setime execution time is not constant. 

   What is the customer-required clock accuracy?

   See notes 98.* here.  See NOTED::HACKERS 679.*, 673.*, and various other
   notes.  DIGITAL_UNIX 3946.*, etc.  CLUSTER 4889.*.  UCX 3396.*.

   Here are some NTP- and XNTP-related web sites:

	http://www.eecis.udel.edu/~ntp/
	ftp://louie.udel.edu/pub/ntp
	ftp://louie.udel.edu/pub/ntp/xntp3.patches/patch.149
	ftp://ftp.gwdg.de/pub/vms/xntp3.4v.VMS.README
	ftp://ftp.gwdg.de/pub/vms/

   Also skim the "Configuring a Master Server" portion of the _DIGITAL
   TCP/IP Services for OpenVMS_ (UCX) manual (which tells you how to set
   up the NTP master", but not how to get the time), and see the DECnet-Plus
   DECdtss tool SYS$COMMON:[SYSHLP.EXAMPLES.DTSS]DTSS$PROVIDER_ACTS.C (which
   does show you how to get the time)...

   Try a COMET search for "NIST time WWV modem", or various other keyword
   strings -- you'll find a number of articles, example programs, etc.

  Jacques,

:	I need the process runs at real-time priority because the time 
:	elapsed from the AEC-BOX access to the setime execution must be 
:	constant.

    What you really need is the time between sampling the time source and
  setting the system time cell to be constant, that is *NOT* the same as
  the total execution time of SYS$SETIME being constant.

    There are 2 things which will affect the timing of the call - First 
  setting the time can only occur on the primary CPU, so on a multiprocessor
  system it may be necessary to reschedule the process to that CPU. This will
  take an indeterminate time. Will not affect a uniprocessor system. The second thing
  is writing the time back to the system disk. This will almost certainly be
  the most important factor in elapsed time variation. Note that this occurs
  *after* setting the time. See source code in [SYS.LIS]SYSSETIME.LIS on your
  local results disk.

    Your issue is that you need to estimate the delay between your sampling
  and setting. I'd suggest you find it by checking the difference between 
  your time source and the system time, then set the system time, then check
  the difference again. On a uniprocessor from a high priority process, I'd
  expect there wouldn't be much variation in the difference after you set the
  time. You should be able to derive an adjustement factor, but note that it
  will be processor dependent! You'd probably be better off using an
  off-the-shelf solution, such as NFT or DTSS since they've already dealt
  with these problems.
						John Gillings, Sydney CSC