# Tso Allocation Time Window


![left](./student-guide/diagram/04-time-window-01-01.png)
------------------------------------------------------------
The first thing to solve for a single point of time is definitely a single point of failure. As we said, PD clusters can ensure that a new master is selected immediately after the master node goes down and recover scheduled services within a short period of time. Then the question arises, how do you ensure that the new leader must generate a TSO greater than the old leader?

Then the current TSO of the old leader must be stored, and the storage must be highly reliable, so TiDB uses etcd. But do you want to save every timestamp you produce? Obviously not, the speed at which timestamps are generated is directly related to disk I/O capacity, and there will be bottlenecks. How do you solve performance issues? TiDB uses a pre-application time window, and the process is shown in the figure.

The current PD (leader) has an STO of 700 (dummy value for ease of explanation), and PD requests an “allocatable time window” from etcd. To know that the span of the time window can be specified by the parameter, the default configuration of the system is 3 ms. The example uses the default configuration, so the starting point of this window is the PD current STO 700, and the end point of the time window is STO 703. After writing etcd successfully, the PD will get an “assignable time window” from 700 to 703. Within this time window, the PD can use the system's physical time as a high order, splice its logical time accumulated in memory and assign a timestamp to the outside. The above design means that all PDs are assigned the high bit of the timestamp, that is, the physical time, which is always less than the maximum value stored by etcd. Then, if the PD leader goes down, the new master can read the maximum value stored in etcd and request a new “allocatable time window” based on this, so that the new master will definitely have a larger timestamp than the old master. In addition, in order to reduce communication overhead, each client can request multiple timestamps at once, with the number of timestamps as a parameter passed by the client to the PD. Note, however, that once cache on the client, the clock is no longer strictly monotonically incremented between multiple clients.