# Tso Assignment: Time Window
__*TSO time window*__

![left](./student-guide/diagram/TSOTimeWindow_aa_001_20220509.png)

------------------------------------------------------------
The first thing that needs to be solved at 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 through raft, and resumes the timing service in a short period of time. So the question arises, how can we 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 also be highly reliable, so TiDB uses etcd. But is it necessary to save a timestamp for every time it is generated? Obviously not, the speed at which timestamps are generated is directly related to disk I/O capacity, and there are bottlenecks. How do you solve performance issues? TiDB uses the method of pre-application time window, and this process is shown in the figure.

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