對于多CPU的服務器，其實每個CPU的單調時鐘也是不同的，一般操作系統會幫應用程序處理這個不同，這樣一來應用程序就不用擔心這個問題。但是有時這個保證也不一定對，所以知道這件事有可能會對一些意想不到的問題有幫助。

NTP對單調時鐘也是有影響的，它會看本地的單調時鐘的頻率，假如本地時鐘太快或者太慢它會進行調整（一般的容忍度在0.05%），但是和當天時間不同的是，它只會調整頻率，不會讓單調時鐘跳到很前或者很后。一般來說單調時鐘還是一個很好的方法來測量消耗的時長，毫秒級別的精度是沒有問題。

　　時鐘的同步可能和我們想象的不太一樣，例如以下幾種情況：

　　機器上的晶振本身是不準確的，它會漂移。這是一個硬件上的問題，主要會跟環境的溫度等等息息相關。Google一般會假設他們的服務器有200ppm的漂移，相當于每30秒有6ms的差別。所以哪怕別的方面都沒有問題，這個漂移都是存在的。

　　機器的時鐘和NTP有很大差別的時候，可能會拒絕同步或者被強制重置。這樣一來我們就會看到時鐘會有一個向前或者向后的跳躍。

　　假如機器的防火墻設置有問題，那么時鐘可能就沒有機會和NTP來進行同步了，而我們都不知道這件事。

　　即使你能夠和NTP同步，這個準確度也會因為你的網絡延時而有差別?？梢韵胂蠹偃缤降男畔⑹盏搅司W絡傳輸的影響，那么時鐘的同步就是不準確的。

　　跳躍的秒數會讓一分鐘的時間發生變化，再也不是60s了，也就是說一分鐘可能是59s也可能是61秒，這就很有可能導致系統出現問題。

　　虛擬機的時間更加復雜，因為多個虛擬機共享CPU，每一個虛擬機在別的機器運行的時候可能都需要暫停幾個毫秒，這就使得時間的計算更加困難。

　　所以精確的時鐘在現實中是很難得到的，但是我們仍然可以做一些努力來得到相對精確的時鐘，比如依賴于GPS的PTP，然后很好的控制deploy和監控。當然這樣做的代價也很大。

　　時鐘的置信區間

　　我們使用函數讀取時間戳的時候，經?？梢钥吹骄?，比如我們可以讀取到毫秒級的精度，甚至納秒級的精度。那么這是否意味著我們讀到的時間就真的精確到這個級別呢？其實不然，正如我們上面說到的各種時間的漂移，事實的時間是有一個置信區間的，比如說95%的概率現在的時間是在10.3到10.5秒之間，但是不知道具體是哪個。所以假如置信區間是100ms級別的，顯然你讀到的納秒值就沒有什么意義了。

　　這個置信區間可能是由你系統的已經決定的，比如晶振的spec，它會有一個左右的標準值之類的。然而，很不幸的是，這些東西都不會真的暴露給開發者，比如你調用一個系統函數clock_gettime，它就會返回一個時間戳，它不會告訴你時間的置信區間。

　　當然也有API會告訴你這個東西，比如Google的TruetimeAPI會返回一個最早值和最晚值，其實這就是置信區間。