Problem

Users might observe a situation when jobs seem to travel through time - carrying a more recent start time than end time like this in the JS7 - Order History:

Analysis

A possible reason for non-matching timestamps is the fact that the servers involved in job scheduling do not use a the same time..

• Typically in Unix and Windows environments a time service such as NTP is used to synchronize a server's clock from an external time server.
  • Should the time service not work for some time then a server's clock will become more and more inaccurate.
  • Small delays of milliseconds can add up to 2 seconds and more after some time.
• The problem starts from a situation when servers used for the Controller and Agents no longer use a synchronized time:
  • When an order is added then the Controller knows the start time that an order is scheduled for. However, it's the Agent that reports completion of the last job in a workflow as the order's end time.
  • If the Controller's clock is behind the Agent's clock then a job that requires less time than the delay between both servers' clocks
    • will show in the Order History a start time that is behind the end time,
    • will - even more confusingly - show non-matching timestamps in the order log.
  • Even in cases of smaller delays the results displayed in the Order History will not be accurate.

Resolution

• It is essential that the servers used for JOC Cockpit and Controller use synchronized time.
  • In case of a JS7 - Controller Cluster the servers involved have to be synchronized.
  • The same applies to the server operating the Cluster Watch Agent.
• It is recommended to use synchronized time for server that are operating Agents.
  • However, except for the confusion from logs and display of the history there is no detrimental effect.