Memorandum

My Admiral, your fleet numbers hundreds, maybe thousands of ships. All of them act as a single organism, acting in the same information field. Radio channel or laser communication is used as a communication channel in case of operation in conditions of radio suppression (or radio silence). Most likely, Erlang is used as the base software on the ships, and each ship is the Node of the computing cluster of your space armada. Due to this, combat programs executed on the flagship can manage the resources of any ship of the armada as their own, coordinating the combat interaction. In terms of conducting a space battle in the vicinity of our solar system, this approach has shown high efficiency, both on the test and in real combat. However, the party sets before us a new task: to prevent the penetration of the enemy into the limits of our solar system, the detection of the enemy and the fight against him to lead on distant frontiers.

In terms of sublight speeds and huge distances, a new enemy lurks us. This time technical. This enemy is called “ Time Warp ”. What it is and how to deal with it (using Erlang version 18 and above) is outlined in this memo. The note is based on technical documentation - Time and Time Correction in Erlang .

Single timeline

New conditions put before engineers new technical tasks. The harmonious work of space objects is achieved not only by network interaction, but also by the exact synchronization of clocks with time on Earth. In order for an automatic space object to follow a given program, or to operate in the event of loss of network communication, its internal clock must be synchronized with the Earth time. To this end, within our solar system, the government (using taxpayers' money) built and installed a grouping of time synchronization satellites. Now, any automatic satellite, even in the event of damage to the main batteries, can only receive the signal of the nearest time synchronization satellite and determine the exact time in conditions of operation only directly from solar panels.
')
Why this system does not help in battle?
1) In the new conditions, we must fight outside the solar system. There are no time synchronization satellites in open space.
2) The combat fleet cannot and should not be dependent on civilian systems.
3) The combat fleet cannot depend on stationary systems.
The fleet must be completely independent and self-sufficient.

For this, fleet ships must independently synchronize time with each other. Most likely, all watches need to be synchronized with the flagship clock.

But you will say: “Atomic clocks are installed on our cruisers, even in fighter ships, clocks are used on reference oscillators, and the guided missile doesn’t live so long that its thermally compensated quartz generator is mistaken for a significant value. And you will be right. Yes, you can synchronize once before the fight. In the course of the battle, individual ships may lose contact with the cluster, but continue to perform combat missions on the same time scale .

Actions in different time scales

There are a number of reasons why a different time value can be established in ships:
- the flagship can approach the place of events through a subspace tunnel: in this case, it will instantly change its coordinates without losing synchronization with the time of the Earth;
- the observation satellite located at the scene of events could have been there for a long time without the possibility of synchronization, and because of the inaccuracy of the generator in hours, its time can either “lag behind” the time of the Earth, or “go ahead”
- middle class ships can approach the scene at sublight speeds and relativistic effects can affect their watches
- automatic ships passing along or through a supermassive black hole

In each case, as soon as the ship appears in the radio visibility zone of the flagship, it will synchronize time, and then connect to the cluster. During the synchronization process, the clock of the synchronized ship will be moved forward , or, even worse, back . This effect is called a time warp.

Technical solution

OTP 18 (ERTS version 7.0) has expanded the functionality of working with time. These features are included in the time warp API, which changes the behavior of systems as the system time changes. The default time break mode behaves in the same way as the old API, which is still valid. So you can change nothing if you don’t want it. However, it is strongly recommended to use new API functions instead of old ones that are based on erlang: now / 0 . Currently, erlang: now / 0 is marked as deprecated, as it is a bottleneck in scalability. Using the new API, you automatically improve scalability and performance. You also have the opportunity to use the multi-time warp mode, which increases the accuracy of time measurement.

Erlang platform, uses not only a real time clock, but also an internal processor clock counter. Thanks to the Erlang time correction, applications are guaranteed that the Erlang monotonic clock does not have a time gap and is relatively accurate. For a complete understanding of the work of temporary systems, please direct your engineers to the technical documentation [ 1 ]. It provides concepts from the new temporary API, such as: “monotonous time”, “strictly monotonous time”, UT1, UTC. POSIX Time, Time Precision, Time Resolution, Time Accuracy, Time Warp, OS System Time, OS Monotonic Time, Erlang System Time, Erlang Monotonic Time, etc. .



Erlang team keeps up with the times, welcome to the future!

List of used sources

1. http://erlang.org/doc/apps/erts/time_correction.html - Time and time correction in Erlang