Làm thế nào tôi có thể đo và ngăn ngừa trôi đồng hồ?

15

Trên một số nền tảng sản xuất, chúng tôi đã quan sát thấy các triệu chứng xuất hiện cho thấy thời gian trong ngày là định kỳ nhảy về phía trước hoặc lùi lại. Các bước nhảy thường khoảng 1 giây, thường là hủy bỏ (nhảy về phía trước rồi lùi lại rất nhanh sau đó) và xảy ra khoảng 50 lần mỗi ngày. Sự trôi dạt này là đáng chú ý nhất trong thời gian sử dụng ứng dụng cao điểm và trong các giai đoạn hoạt động I / O đĩa cao như sao lưu hàng ngày. Những bản thảo này đang ảnh hưởng đến ứng dụng nhạy cảm thời gian thực mềm của chúng tôi.

Các hệ thống là các máy chủ Oracle Netra X4250 và Netra X4270 chạy SLES 11SP2 với kernel mặc định 3.0.58-0.6.6.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Chúng tôi đã vô hiệu hóa NTP , nhưng điều đó không có bất kỳ ảnh hưởng nào đến việc trôi dạt. Có công cụ nào đo thời gian trôi trong ngày không? Làm thế nào chúng ta có thể tránh điều này?

Đây là những nền tảng sản xuất và chúng tôi không thể tạo lại vấn đề trong phòng thí nghiệm của mình, vì vậy khả năng thử nghiệm của tôi bị hạn chế. Nếu để các thiết bị của riêng tôi, tôi sẽ viết một công cụ để đo độ trôi và có thể thử nghiệm với nguồn đồng hồ HPET .

linux sles clock

— brett
nguồn

5

Vô hiệu hóa NTP làm cho đồng hồ không ổn định hơn nhiều ... lý do duy nhất tôi có thể thấy đối với NTP là không giữ đồng hồ thẳng hàng là đồng hồ đã hết tiền và NTP từ chối cập nhật (xem ntpdate(8)hoặc ntpd(8)).

— vonbrand

1

NTPD không theo dõi và sửa lỗi cho đồng hồ trôi, nhưng những gì bạn không trôi. Sự trôi dạt luôn theo cùng một hướng với khoảng cùng một lượng theo thời gian. Nếu nó ngẫu nhiên nhảy về phía trước và lùi lại, không có cách nào để dự đoán nó, và phù hợp với nó.

— Patrick

1

Những gì @Patrick nói là đúng, vấn đề bạn mô tả là một bước nhảy không ngừng trong thời gian tiến và lùi, nhiều lần mỗi ngày. NTP hoạt động tốt trên drift nhưng nó sẽ không giúp bạn nhiều với điều này. Một cái gì đó có khả năng đặt lại ngày hệ thống của bạn thành một số nguồn thời gian bên ngoài có thể chỉ có độ phân giải 1 giây. Nếu máy chủ của bạn là x86 * thì RTC phần cứng có thể là nguồn và một số công việc định kỳ là thủ phạm. Theo như cách đo bù đồng hồ của Bratchley, câu trả lời ntpdate của Bratchley là một cách tiếp cận hợp lý, cung cấp một tham chiếu đồng hồ tốt 1 tầng được sử dụng: chạy một lần một phút và gnuplot kết quả cho một bức ảnh.

— duanev

1

Chạy qua đánh giá này về NTP bắt đầu trên một máy chủ mới ( drdobbs.com/embedded-systems/ mẹo ). Phải mất hàng giờ NTP để tìm hiểu một tinh thể mới. Đối với các tinh thể thực sự xấu, NTP sẽ phải 'bước' đồng hồ nhiều lần trong khi luyện tập (xem Hình 4 và 5 trong bài viết đó). Giá trị cuối cùng trong ntp.drift là 118ppm là 10 giây mỗi ngày hoặc 208ms cứ sau 30 phút. Mặc dù đây không phải là những gì OP đã thấy, NTP ban đầu có thể gây ra những bước nhảy đáng chú ý trong thời gian.

— duanev 29/07/2015

8

Có công cụ nào đo thời gian trôi trong ngày không?

Các công cụ duy nhất tôi biết là các công cụ NTP đủ. Bạn không cần phải thực sự định cấu hình ntpd để đồng bộ hóa với nguồn đồng hồ đã cho, bạn chỉ có thể sử dụng -dtùy chọn ntpdateđể tìm nạp phần bù đã tính.

Thí dụ:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d là tùy chọn gỡ lỗi mà NTP hoạt động mà không thực sự chạm vào đồng hồ hệ thống.

Bất kỳ lời khuyên về làm thế nào chúng ta có thể tránh điều này?

Tôi không quá ngạc nhiên khi bạn không thể tái tạo điều này trong môi trường dev / test vì có lẽ chỉ là do đồng hồ phần cứng. Nếu bạn có hỗ trợ phần cứng với ai đó, tôi sẽ cố gắng bảo trì máy của bạn. Một khả năng là kinh doanh một trong những máy dev cho máy sản xuất này, sửa chữa các hệ thống SẢN XUẤT trước đây và giới thiệu lại nó như một máy dev để thay thế máy hiện có trong sản xuất.

Nói tóm lại, chuyển đổi nguồn đồng hồ phần cứng là tất cả những gì bạn có thể làm. Nếu bạn không hoặc không thể thực hiện việc hoán đổi, tôi khuyên bạn nên đi theo con đường hpet. Bạn có thể kiểm tra xem nguồn thay đổi đồng hồ có gây rối với các dịch vụ hệ thống hay không và sau đó triển khai nó vào sản xuất như một mary mưa đá.

— Bratchley
nguồn

Bằng cách "đo độ trôi của đồng hồ", tôi không có nghĩa là trôi từ nguồn thời gian tham chiếu, chẳng hạn như NTP mang lại cho bạn. Tôi có nghĩa là một công cụ có thể phát hiện "nhảy" trong thời gian của đồng hồ trong một khoảng thời gian liên tục. Ví dụ: mất thời gian lấy mẫu trong ngày cứ sau 50ms và báo cáo nếu chênh lệch so với lần lấy mẫu cuối cùng quá xa so với 50ms. Một công cụ như vậy sẽ hiển thị nếu thời gian trong ngày đồng hồ trôi từ đồng hồ phần cứng cơ bản vì bất kỳ lý do.

— brett

1

Không phải sự hiện diện của sự can thiệp như vậy có thể gây ra sự suy giảm hiệu suất nhiều hơn bạn mong muốn giải quyết? Tuy nhiên, rất có thể, đó là sự cố phần cứng, vì vậy bạn sẽ cần bảo trì phần cứng hoặc sử dụng nguồn đồng hồ mà không gặp sự cố này. tscđược dựa trên CPU nên có ý nghĩa rằng hoạt động CPU cao hơn sẽ gây ra vấn đề với dù sao đồng hồ phần cứng. Nếu hpet đủ nhanh cho bạn, thì bạn có thể phải thử điều đó, được phục vụ hoặc thực hiện việc hoán đổi. Đó là những lựa chọn duy nhất tôi có thể thấy cho bạn.

— Bratchley

3

Một giải pháp là sử dụng HPET

Xem thêm Hẹn giờ sự kiện chính xác cao

Để đặt nó làm tham số khởi động, hãy sử dụng

clocksource=hpet

Trên phần cứng cũ, TSCnó thường không ổn định và bị vô hiệu hóa bởi kernel.

Với sự ra đời của CPU đa lõi / siêu phân luồng, hệ thống có nhiều CPU và hệ điều hành ngủ đông, TSC không thể dựa vào để cung cấp kết quả chính xác ...

Wikipedia: Bộ đếm thời gian

Trên một hệ thống sản xuất biểu hiện các triệu chứng jitter đồng hồ, tôi đã chuyển đồng hồ sang hpet. Điều này không có tác dụng đối với các triệu chứng jitter đồng hồ quan sát được.

— Brett

HPET là bộ đếm thời gian phần cứng bên ngoài và không thể jitter. Vì vậy, giải pháp này dường như là một con đường sai. Có rất nhiều vấn đề về thời gian với phần cứng cũ, đặc biệt là khi sử dụng ảo hóa. Bạn đã kiểm tra điều này với phần mềm khác nhau không?

1

Tôi đã viết một công cụ chi tiết hơn để tương quan các phép đo đồng hồ với các triệu chứng độ trễ được thể hiện bởi ứng dụng của chúng tôi. Công cụ này dường như loại trừ những gì trước đây tôi nghi ngờ là jitter trong thời gian ban ngày của Linux.

Câu chuyện dài quá ngắn, giả thuyết ban đầu của tôi không hợp lệ. Nhưng tôi đã học được rất nhiều về đồng hồ Linux từ các câu trả lời và liên kết, vì vậy cảm ơn tất cả những người đã trả lời!

— brett
nguồn

3

(...) Giả thuyết ban đầu của tôi không hợp lệ. Bạn có thể cho chúng tôi biết đâu là nguyên nhân thực sự?

— Piotr Dobrogost

0

Không phải đồng hồ được cho là đơn điệu trừ khi có ai đó thay đổi nó? Nhảy lùi không nên có thể. Phải có một cái gì đó thiết lập đồng hồ - một công việc định kỳ hoặc một số trình nền khác (ví dụ như một cuộc gọi đến hwclock --adjust). Tôi nhớ lại rằng ntp tự cập nhật số liệu thống kê cho sự trôi dạt và bù đắp cho nó thường xuyên và nếu bạn không chạy ntp trong một thời gian dài và nhận được một khoản bù đắp lớn, nó sẽ làm rối tung thời gian trong nhiều ngày sau khi bạn không thiết lập lại /etc/adjtime. Bạn có thể có một cái gì đó giống như được thiết lập - thứ gì đó điều chỉnh thời gian trôi theo định kỳ (và gây ra các bước nhảy).

ntp thực sự là để chống lại vấn đề này

— hành
nguồn

Đó là những gì tôi nghĩ là tốt. Việc đọc các nguồn đồng hồ phần cứng của tôi cho thấy rằng bộ đếm nên tăng đơn điệu. Nếu đó là sự thật, tệ nhất là chúng ta nên quan sát tỷ lệ đánh dấu thất thường, nhưng không bao giờ nhảy trở lại. Trên hệ thống đa bộ xử lý, tôi hiểu rằng tsc cần được đồng bộ hóa giữa các bộ xử lý - có lẽ đây là nguyên nhân gây ra các bước nhảy ngược?

— brett