Tôi chỉ nhận thấy một cơ hội thuần túy rằng một trong những thiết bị chuyển mạch Cisco 4500 của tôi có đồng hồ bị lỗi: chậm hơn 2 phút mặc dù có vẻ như không hoạt động. Theo tôi, thậm chí một giây không nên được coi là chấp nhận được đối với các hệ thống liên quan. Ngoài ra, tôi sẽ không nhận thấy sự khác biệt từ chẩn đoán, nếu tôi không so sánh nó với một chiếc đồng hồ treo tường đơn giản.
Một số chi tiết
Đây là thông tin ntp cho một số máy chủ của tôi (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241) một phần tham chiếu lẫn nhau cho dự phòng, nhưng chủ yếu cuối cùng là bằng cách đồng bộ hóa với 10.0.0.1, một lần nữa kéo Thời gian từ bên ngoài. Vì vậy, sự khác biệt về thời gian không thể dẫn đến từ các nguồn thời gian ban đầu khác nhau. Vì các quan sát khiến tôi hơi hoang tưởng, "có thời gian chính xác" theo các cách sau: show clock(hoặc date) tạo ra một đầu ra khớp với đồng hồ treo tường và đồng hồ hệ thống cục bộ của tôi (cũng ổn theo http://time.is ) với một lỗi chắc chắn dưới 1 giây (độ chính xác của tôi nhấn ENTER trong khi xem đồng hồ cục bộ của tôi)
10.0.1.119 (Ubuntu) có thời gian chính xác
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
10.0.99.241 (Cisco 2960) có thời gian chính xác
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.99.1 10.0.0.1 3 28 64 377 1.462 85.288 19.758
+~10.0.99.2 10.0.1.119 4 29 64 377 1.297 83.515 5.369
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.2 (Cico 4500) có thời gian chính xác
#sho ntp associations
address ref clock st when poll reach delay offset disp
+~10.0.99.1 10.0.0.1 3 6 1024 111 1.148 -1.618 42.875
*~10.0.1.119 10.0.0.1 3 31 1024 377 0.043 1.687 1.064
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.1 (Cisco 4500) tụt lại sau khoảng 2 phút 6 giây
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.0.1 130.149.17.8 2 274 1024 377 15.625 3.681 30.403
+~10.0.99.2 10.0.1.119 4 415 1024 376 15.625 0.855 33.276
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
#sho ntp status
Clock is synchronized, stratum 3, reference is 10.0.0.1
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.
Câu hỏi
- Làm thế nào đến 10.0.99.1 là quá xa?
- Làm thế nào mà các hệ thống đồng bộ hóa với 10.0.99.1 là chính xác?
- Tôi nên học như thế nào từ đầu ra của
sho ntp statusngày 10.0.99.1 rằng đồng hồ thực sự không đồng bộ (so với tất cả các máy chủ và đồng hồ tham chiếu được đề cập trongsho ntp asso)? Đối với tôi đầu ra trông hoàn toàn giống như một "Tôi hoàn toàn hạnh phúc".
EDIT: Theo nhu cầu phổ biến, đầu ra củasho clock detail
10.0.99.1
#sho clock detail
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.99.2
#sho clock detail
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.0.1). Nhưng tôi không nghĩ rằng bất kỳ quan sát nào của tôi có thể giải thích trực tiếp nguyên nhân của vấn đề hiện tại của bạn.