我們可以寫一個簡單程序（取名為icmptime），給某個主機發送ICMP時間戳請求，并打印出返回的應答。它在我們的小互聯網上運行結果如下：  程序打印出ICMP報文中的三個時間戳：發起時間戳（orig）、接收時間戳（recv）以及發送時間戳（xmit）。正如我們在這個例子以及下面的例子中所看到的那樣，所有的主機把接收時間戳和發送時間戳都設成相同的值。 我們還能計算出往返時間（rtt），它的值是收到應答時的時間值減去發送請求時的時間值。difference的值是接收時間戳值減去發起時間戳值。這些值之間的關系如圖6-7所示。  如果我們相信RTT的值，并且相信RTT的一半用于請求報文的傳輸，另一半用于應答報文的傳輸，那么為了使本機時鐘與查詢主機的時鐘一致，本機時鐘需要進行調整，調整值是difference減去RTT的一半。在前面的例子中， bsdi的時鐘比sun的時鐘要慢7 ms和8 ms。 由于時間戳的值是自午夜開始計算的毫秒數，即UTC，因此它們的值始終小于86400000 (24×60×60×1000)。這些例子都是在下午4:00以前運行的，并且在一個比UTC慢7個小時的時區，因此它們的值比82800000（2300小時）要大是有道理的。 如果對主機bsdi重復運行該程序數次，我們發現接收時間戳和發送時間戳的最后一位數總是0。這是因為該版本的軟件（0.9.4版）只能提供10ms的時間分辨率（說明參見附錄B）。 如果對主機svr4運行該程序兩次，我們發現SVR4時間戳的最后三位數始終為0：  由于某種原因， SVR4在ICMP時間戳中不提供毫秒級的分辨率。這樣，對秒以下的時間差調整將不起任何作用。 如果我們對子網140.252.1上的其他主機運行該程序，結果表明其中一臺主機的時鐘與sun相差3.7秒，而另一個主機時鐘相差近75秒：  另一個令人感興趣的例子是路由器gateway（一個Cisco路由器）。它表明，當系統返回一個非標準時間戳值時（不是自午夜開始計算的毫秒數， UTC），它就用32 bit時間戳中的高位來表示。我們的程序證明了一點，在尖括號中打印出了接收和發送的時間戳值（在關閉高位之后）。另外，不能計算發起時間戳和接收時間戳之間的時間差，因為它們的單位不一致。  如果我們在這臺主機上運行該程序數次，會發現時間戳值顯然具有毫秒級的分辨率，而且是從某個起始點開始計算的毫秒數，但是起始點并不是午夜UTC（例如，可能是從路由器引導時開始計數的毫秒數）。 作為最后一個例子，我們來比較sun主機和另一個已知是準確的系統時鐘—一個NT Pstratum1服務器（下面我們會更多地討論NTP，網絡時間協議）。  如果我們把difference的值減去RTT的一半，結果表明sun主機上的時鐘要快38.5～51.5 ms。