File System Offsets

The file system that contains the design files may reside on a machine that is not the same as the one where the vovserver is running. The clocks in the two machines may be different, resulting in an offset. These offsets can be easily avoided. Here we show what can be done to work with an unsynchronized network.

Measuring the Offset

The complete list of known offsets is available in the Filesystems page.

To check the offset of a particular file system:
  1. Login onto the machine that is running the vovserver
  2. Connect to a running project
  3. Change to a writable directory in the filesystem you want to test
  4. Use the command vovguru as follows:
    % vovguru -T .
vovguru message [11:16:49]: Filesystem /name/of/filesystem seems OK (deltaT=0)

The program vovguru writes a file in the current directory and computes deltaT as the difference between the file timestamp and the machine clock.

In this example, there is no offset. Otherwise, you would get a warning and deltaT will have a value different from 0. Acceptable offsets may be in the range of +/- 4 seconds. Larger offsets indicate a poorly managed network, and the problem should be corrected by your system administrator, rather than trying to work around it.

Dealing with the Offset

You have the following options:
  • The best option is to synchronize the network.
  • The second option is to allow a tolerance in the comparison of timestamps, which is accomplished by modifying the policy.tcl file.
  • The least attractive option, if the offset is acceptably small, consists of adding add appropriate delays in the job firing and execution procedures. Notice that the delays affect every job, and the entire retracing system becomes slower than it could be if the clocks had been synchronized.
The file system clock is running ahead of the server
If the filesystem clock is ahead of the vovserver, as indicated by a positive deltaT value, sequences of jobs are likely to fail because the timestamps of intermediate input files seem more recent than the start date of the job. The failed jobs, if fired again, will typically succeed, because the files have had time to age. To avoid this kind of failures, it is sufficient to delay the firing of the jobs by setting the environment variable VOV_DELAY_FIRE. This variable, whose default value is 0, is used by vovtasker to delay job firing.
For example, if the time offset is 2 seconds, you can add the following line to the setup.tcl file: 
setenv VOV_DELAY_FIRE 2
and then you must restart the taskers.
The file system clock is running behind the server
If the filesystem clock is running late with respect to the clock in the vovserver, as indicated by a negative deltaT value, it is likely that short jobs will fail because the timestamp of some outputs is younger than the job start time, giving the impression that the job has not had any effect on those outputs. The solution is to introduce a delay between the official start of the job, which is the time the job is added to the design trace, and the actual processing by the job. This is accomplished with the environment variable VOV_DELAY_BEGIN, whose default value is 0.
For example, if the time offset is 1 second, you can add the following line to the setup.tcl file:
setenv VOV_DELAY_BEGIN 1

Then you need to restart the taskers and source the setup.tcl file again in your current shell.