Nhân Linux phát hiện tần số bộ xử lý sai


15

Sau khi khởi động lạnh máy chủ Debian 6.0.8 (HP ProLiant), ntpdđã chơi tàn phá với thời gian hệ thống: bù và jitter đối với các máy chủ thời gian tham chiếu thông thường và đáng tin cậy tăng lên không giới hạn. (Lưu ý rằng một máy chủ giống hệt nhau hoàn toàn không có vấn đề gì.) Sau nhiều nỗ lực không thành công để khắc phục sự cố ở ntpdbên, tôi quyết định thử khởi động lại và mọi thứ đều ổn.

Để điều tra vấn đề, tôi đã tìm thấy sự khác biệt này, điều này có thể giải thích các vấn đề về đồng hồ của tôi:

root@n1:~# zgrep Detected /var/log/dmesg*
/var/log/dmesg:[    0.004000] Detected 2400.110 MHz processor.
/var/log/dmesg.0:[    0.004000] Detected 2383.579 MHz processor.
/var/log/dmesg.1.gz:[    0.004000] Detected 2400.036 MHz processor.
/var/log/dmesg.2.gz:[    0.004000] Detected 2400.298 MHz processor.
/var/log/dmesg.3.gz:[    0.004000] Detected 2400.165 MHz processor.
/var/log/dmesg.4.gz:[    0.004000] Detected 2400.410 MHz processor.

Lưu ý rằng trong lần khởi động cuối cùng thứ hai (vấn đề nan giải), freq CPU được phát hiện là một ngoại lệ rõ ràng. Nếu không có ngoại lệ, sai số và độ lệch chuẩn của tần số được phát hiện liên quan đến tần số danh nghĩa là +0,15 MHz ± 0,25 MHz. Đối với khởi động có vấn đề, tôi có lỗi -16,4 Mhz, lớn hơn khoảng 100 lần so với dự kiến.

Những câu hỏi của tôi:

  1. Một lỗi của loại này có thể làm cho ntpkỷ luật thời gian không ổn định / không thể sử dụng? Đây có phải là lý do cho vấn đề đồng hồ của tôi?

  2. Đây có phải là loại hành vi là một triệu chứng của phần cứng flacky? Máy chủ có nên đi vào bảo trì hw?

Cập nhật

Một số dữ liệu hữu ích:

  • hạt nhân là 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
  • current_clocksourcetsc
  • lỗi cho lpj(tất nhiên) phù hợp với lỗi trên freq CPU

Một số dòng ngữ cảnh cho ở trên grep

[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.004000] Detected 2400.110 MHz processor.
[    0.000008] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.22 BogoMIPS (lpj=9600440)

Câu trả lời:


5

Tôi đã thuyết phục bản thân mình rằng vấn đề là tần số đếm ngược thời gian xác định sai (TSC).

Rõ ràng hạt nhân đang hiệu chỉnh TSC theo bộ định thời khoảng thời gian lập trình (PIT). Thông thường tần số CPU được xác định là 2400.204 ± 0.134 MHz, tương ứng với độ chính xác khoảng 56 ppm. Sau khi khởi động có vấn đề, tần số CPU được ước tính là 2383,579 MHz, tương ứng với lỗi khoảng 6900 ppm, ntpdkhông thể bù được. Trong thực tế trong 10h30m đầu tiên hoạt động, đồng hồ hệ thống đã đạt được khoảng 4m30 giây, tức là khoảng 7000 ppm.

Vì lỗi trong tần số TSC tương ứng với độ lệch trong đồng hồ hệ thống, tôi sẽ kết luận rằng hành vi đồng hồ bất thường là do hiệu chuẩn TSC sai.

Tuy nhiên tôi chưa bao giờ thấy một vấn đề lớn như vậy: Tôi vẫn đang tự hỏi về những nguyên nhân có thể (hw, sw?) Của việc hiệu chuẩn sai này.


3

Loại hành vi này là không điển hình. Một kiểm tra tốt sẽ là theo dõi các giá trị của ntp.drifttệp để xem liệu những thay đổi đáng kể xảy ra khi hành vi được hiển thị. Nếu nó tiếp tục thay đổi đáng kể, NTP đã cố gắng xoay quanh một vấn đề. Nếu đó là trường hợp, đó là một dấu hiệu cho thấy hạt nhân xác định sai tần số đồng hồ thực sự khi khởi động, hoặc chính đồng hồ bị chậm cho các phần khởi động sai. Thật không may, một sự kiện này không phải là một tín hiệu rõ ràng về các vấn đề phần cứng.

Nếu nó xảy ra một lần nữa, hãy xem tập tin ntp.drift đó.


Sau khi khởi động có vấn đề, ntpd không bao giờ đến PLL ổn định, vì vậy ntpdc -c loopinfokhông bao giờ cho tôi giá trị trôi tần số. Bây giờ sau khi khởi động lại, mọi thứ dường như theo thứ tự, với giá trị trôi ổn định ... BTW đề xuất của bạn là chính xác, tôi đang theo dõi log/loopstatshành vi bất thường.
Stefano M
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.