对于多CPU的服务器，其实每个CPU的单调时钟也是不同的，一般操作系统会帮应用程序处理这个不同，这样一来应用程序就不用担心这个问题。但是有时这个保证也不一定对，所以知道这件事有可能会对一些意想不到的问题有帮助。

NTP对单调时钟也是有影响的，它会看本地的单调时钟的频率，假如本地时钟太快或者太慢它会进行调整（一般的容忍度在0.05%），但是和当天时间不同的是，它只会调整频率，不会让单调时钟跳到很前或者很后。一般来说单调时钟还是一个很好的方法来测量消耗的时长，毫秒级别的精度是没有问题。

　　时钟的同步可能和我们想象的不太一样，例如以下几种情况：

　　机器上的晶振本身是不准确的，它会漂移。这是一个硬件上的问题，主要会跟环境的温度等等息息相关。Google一般会假设他们的服务器有200ppm的漂移，相当于每30秒有6ms的差别。所以哪怕别的方面都没有问题，这个漂移都是存在的。

　　机器的时钟和NTP有很大差别的时候，可能会拒绝同步或者被强制重置。这样一来我们就会看到时钟会有一个向前或者向后的跳跃。

　　假如机器的防火墙设置有问题，那么时钟可能就没有机会和NTP来进行同步了，而我们都不知道这件事。

　　即使你能够和NTP同步，这个准确度也会因为你的网络延时而有差别。可以想象假如同步的信息收到了网络传输的影响，那么时钟的同步就是不准确的。

　　跳跃的秒数会让一分钟的时间发生变化，再也不是60s了，也就是说一分钟可能是59s也可能是61秒，这就很有可能导致系统出现问题。

　　虚拟机的时间更加复杂，因为多个虚拟机共享CPU，每一个虚拟机在别的机器运行的时候可能都需要暂停几个毫秒，这就使得时间的计算更加困难。

　　所以精确的时钟在现实中是很难得到的，但是我们仍然可以做一些努力来得到相对精确的时钟，比如依赖于GPS的PTP，然后很好的控制deploy和监控。当然这样做的代价也很大。

　　时钟的置信区间

　　我们使用函数读取时间戳的时候，经常可以看到精度，比如我们可以读取到毫秒级的精度，甚至纳秒级的精度。那么这是否意味着我们读到的时间就真的精确到这个级别呢？其实不然，正如我们上面说到的各种时间的漂移，事实的时间是有一个置信区间的，比如说95%的概率现在的时间是在10.3到10.5秒之间，但是不知道具体是哪个。所以假如置信区间是100ms级别的，显然你读到的纳秒值就没有什么意义了。

　　这个置信区间可能是由你系统的已经决定的，比如晶振的spec，它会有一个左右的标准值之类的。然而，很不幸的是，这些东西都不会真的暴露给开发者，比如你调用一个系统函数clock_gettime，它就会返回一个时间戳，它不会告诉你时间的置信区间。

　　当然也有API会告诉你这个东西，比如Google的TruetimeAPI会返回一个最早值和最晚值，其实这就是置信区间。