TINE is a distributed control system. There is no central element managing all of the control system data and hence data synchronization is an important issue. The most crucial aspect of control data synchronization is that the data timestamps are synchronized. If the individual clocks of the control system elements are synchronization then that the data timestamps are synchronized follows a priori. For many platforms it is quite straightforward to configure an ntp daemon which keeps the hosts CPU synchronized to a central time server.
Where this is not possible or practical, TINE servers have an embedded 'rdate' service which can obtain the time in-process periodically from a time server and set the local 'clock' accordingly (e.g. MSDOS, VxWorks, NIOS). This service can be optionally turned on or off, depending on whether a time server is available. These synchronization efforts are good to the current second. Note however that the TINE time stamp is good to the current millisecond for most platforms. The TINE time stamp is a 'double' consisting of the UTC, i.e. seconds since Jan 1, 1970, plus the current second fraction. Casting the double value into a long int results in the traditional UTC time.
The time server to use must be identified at build time and is determined by the TIME_SERVER_HOST macro definition in project.def. If undefined it resorts to
#define TIME_SERVER_HOST "time"
which might work for most sites.
In addition, TINE servers can also be configured to synchronize the data timestamps according to the input received from a TINE time server. The TINE timeserver is a server in the vein of the Network Globals server. Namely it operates in producer- consumer mode and produces one quantity, namely the current TINE data timestamp. If a TINE time server is in operation, it will send via multicast the current TINE time stamp at one second intervals. If a TINE server is configured to intercept these multicasts, it can then apply an offset to its own clock when timestamping its data. This will leave the clock alone and consequently, log file entries (other than those written by feclog()) will reflect the time read by the local clock, whereas data timestamps will be synchronized with the TINE time server.
Although any server can receive the system time stamp, some platforms are pre-configured to look for this Network Global by default, namely MSDOS, Win16 and Win32. At initialization time, if
useGlobalSynchronization = TRUE;
has been set, then the server will listen for timestamp updates from the TINE time server. If other platforms desire to have this flag TRUE be default, then introducing:
#define GLOBAL_SYNCHRONIZATION TRUE
inside of project.def will do the trick.
1.5.8