But when database commits locally, it doesn't involve network card. I might want all packets sent by my application to carry the timestamps when they leave the network card. This is a useful feature for applications. Hence tighter bound on clock uncertainty. Once you bypass software, time synchronization, especially various latency estimations are much easier. And PTP clock synchronization is done usually, if not exclusively, in hardware. That's why Precision Time Protocol (or PTP) requires hardware support, i.e. Notice that we are talking about milliseconds, if not microseconds or nanoseconds. It's impossible to have a bound on the execution time of the daemon. Even if the daemon runs in kernel space, there can be times that memory pressure is high, and the code can be waiting for IO, etc. As long as the clock synchronization happens in software, you can't have an accurate bound of the uncertainty.
#Win32 api gettimestamp as file time software
You can't reply on software if you want to have an accurate clock. But first, let's take a look at how can you get a timestamp with bounded uncertainty. In this post, I want to discuss different options of assigning timestamps and their usefulness to applications. There I talked about how Spanner uses TrueTime API to achieve external consistency at global scale and hide sharding and replication from users.
This is a follow-up post of my previous one about Spanner.
0 kommentar(er)
