Đồng bộ hóa đồng hồ với NTP khi trực tuyến và với RTC khi ngoại tuyến?


11

Có một cơ chế hiện có đồng bộ hóa hệ thống linux với NTP khi trực tuyến và với RTC có thể dự đoán khi đang ngoại tuyến không?


Chúng tôi vận hành các "bộ thu" từ xa: các hệ thống nhúng Linux thu thập và đánh dấu thời gian dữ liệu cảm biến. Chúng tôi cần các lỗi đồng hồ của họ để ở mức nhỏ hợp lý, nói dưới 5 giây. Thông thường chúng tôi sử dụng NTP để đồng bộ hóa đồng hồ của họ và hoạt động tốt - miễn là hệ thống trực tuyến.

Vấn đề là một số nhà sưu tập có đường dẫn rất xấu có thể xuống hàng giờ, hàng ngày hoặc thậm chí vài tuần. Điều đó không dừng việc thu thập dữ liệu cục bộ, nhưng không có NTP, đồng hồ hệ thống Linux bị trôi dạt và khá khó lường.

OTOH, RTC của phần cứng cũng bị trôi rất nhiều, nhưng với tốc độ không đổi. Tốc độ trôi RTC thay đổi từ bảng này sang bảng khác, nhưng không đổi trên mỗi bảng và có thể đo được.

Tôi đoán những gì chúng ta cần là một cơ chế thực hiện như sau:

  • Đo tốc độ trôi RTC của một bảng trước khi triển khai
  • Điều chỉnh thời gian hệ thống liên tục / thường xuyên qua NTP khi có thể
  • Điều chỉnh thời gian hệ thống thường xuyên từ RTC khi NTP không thể truy cập được. Hãy biết tỷ lệ trôi RTC được biết đến.
  • Tùy chọn: Đo và ghi lại tốc độ trôi RTC đang diễn ra trong khi trực tuyến (1)

Với 'cơ chế', tôi có nghĩa là một số phần mềm và / hoặc cấu hình được bảo trì tốt, có thể xử lý hai trạng thái "trực tuyến" so với "ngoại tuyến", đảm bảo rằng đồng hồ hệ thống được đồng bộ hóa với nguồn thời gian chính xác (ntp vs. rtc), phát hiện sự thay đổi trạng thái và sửa lỗi cho sự trôi dạt RTC. Nó không quan trọng lắm cho dù nó được triển khai như một cấu hình / plugin đặc biệt ntpd, như một trình nền riêng biệt, như một công việc định kỳ, hoặc cách khác.

Tôi đã xem Chrony , nhưng theo tài liệu của nó, nó cố gắng dự đoán sự trôi dạt của đồng hồ hệ thống , trong trường hợp của chúng tôi trôi dạt khó lường hơn nhiều so với RTC. Chrony dường như chỉ sử dụng RTC để giữ thời gian cho các lần khởi động lại.


(1) Lưu ý ntpd kích hoạt chế độ '11 -minute 'của kernel (cập nhật rtc từ đồng hồ hệ thống cứ sau 11 phút). Dường như không có cách nào với các nhân và ntpd hiện tại để ngăn chặn chế độ 11 phút. Do đó, bất kỳ thông tin trôi dạt rtc nào bị mất trong khi ntpd đang chạy (thx @billthor).


Cập nhật / chỉnh sửa:

  • Chúng tôi đang xem xét để thêm đồng hồ radio bên ngoài cho tín hiệu MSF hoặc DCF77 (chúng tôi có trụ sở tại Châu Âu) thông qua USB hoặc Nối tiếp. Nhưng chúng tôi thay vì giữ cho phần cứng nạc.
  • Bộ sưu tập của chúng tôi được đặt trong nhà, thường ở tầng hầm. Vì vậy, thêm đồng hồ GPS sẽ không giúp đỡ.
  • Chúng tôi sử dụng Debian 7. Điều đó có nghĩa là hwclock từ produc-linux-2.20.1, ntpdate-4.2.6p5, ntpd từ ntp-4.2.6.p5, chrony-1.24 (có khả năng 1.30).
  • Lưu ý rằng vấn đề của chúng tôi không phải là chúng ta không biết làm thế nào để sử dụng ntpdate(8), hwclock(8), date(1), vv Xin vui lòng xem phần bổ sung trong nghiêng về những gì tôi có nghĩa với 'cơ chế'.
  • Đã thêm chú thích về chế độ '11 -minute '
  • Đây là một cuộc thảo luận rất thú vị về đồng bộ hóa ngoại tuyến và trôi dạt RTC

Theo tôi hiểu, sự kết hợp giữa ntpd và hwclock đã cho phép bạn thực hiện tất cả những điều này.
Roy

@Roy Chắc chắn rồi. Câu hỏi là: Làm thế nào để kết hợp ntp (d) và RTC (hwclock) mạch lạc để đạt được độ chính xác tối đa?
Nils Toedtmann

Tôi hiểu rằng đồng hồ sys trôi nhiều hơn RTC. Tôi tò mò về những gì bạn thấy không thể chấp nhận được về cách thức / hiệu quả của việc quản lý thời gian trôi của hệ thống? Làm thế nào đã chrony thất bại cho bạn?
dfc

@dfc chrony đã không thất bại với chúng tôi. Chúng tôi chưa thử vì dường như không sử dụng RTC để giữ thời gian trong thời gian ngoại tuyến, điều mà tôi nghĩ sẽ tăng độ chính xác trong trường hợp sử dụng của chúng tôi. Chúng tôi sẽ kiểm tra thời gian nếu không có phương pháp nào có triển vọng hơn được đề xuất.
Nils Toedtmann

Tôi nghĩ bạn nên nhìn vào chrony. Trân trọng, có vẻ như bạn đang bỏ qua một lựa chọn tốt dựa trên linh cảm. Theo ý kiến ​​của tôi, điều ngược lại là điều tra về thời gian không tìm thấy RTC-ntpd. Có vẻ như điều dễ nhất là xem liệu chrony có đáp ứng nhu cầu của bạn hay không và nếu không thì hãy xuống hố thỏ này
dfc

Câu trả lời:


4

Tình huống của bạn là không bình thường, và tôi sẽ ngạc nhiên nếu có ai nghĩ ra ntpdcấu hình dựa trên tiêu chuẩn để làm những gì bạn muốn. Điều đó nói rằng, tôi thích được ngạc nhiên, và nó xảy ra khá thường xuyên xung quanh những phần này.

Nhưng cho đến khi ai đó nghĩ ra một ý tưởng tốt hơn, bạn đã xem xét một crontabmục như thế này chưa?

*/5 * * * *   ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )

IE, cứ năm phút cố gắng đồng bộ hóa đồng hồ qua ntpdatevà nếu (và chỉ khi) không thành công, hãy điều chỉnh đồng hồ phần cứng cho trôi theo /etc/adjtimetệp (định dạng được nêu chi tiết man hwclockvà dòng đầu tiên bạn đã điền phù hợp sử dụng kiến ​​thức của bạn của tỷ lệ RTC cụ thể đó), sau đó đặt đồng hồ hệ thống từ RTC.

Lưu ý rằng nếu bạn đi đến một giải pháp như thế này và bạn đang triển khai bất kỳ số lượng đáng kể nào của các hệ thống này, thì nó được coi là lịch sự khi làm việc với nhóm và đóng góp máy chủ theo tỷ lệ sử dụng của bạn. Bạn có thể tìm thêm thông tin tại http://www.pool.ntp.org/en/vendors.html .


Bạn đóng đinh ý tưởng cơ bản :-) Nhưng nó không được tính là câu trả lời (vì) nó không tính đến sự trôi dạt RTC (không đổi, nhưng quan trọng). Chúng ta có thể cải thiện nó, ví dụ như sử dụng /etc/adjtimehwclock --adjust?
Nils Toedtmann

Đúng; xem ở trên.
MadHatter

Đây là loại giải pháp tôi có trong đầu khi tôi viết bình luận trước đây. Ngoài ra, nếu đồng hồ hệ thống hiện đang được đồng bộ hóa qua ntpd, bạn có thể sử dụng hwclock để đo và đặt tốc độ trôi khá chính xác cho RTC.
Roy

Thật không may, không thấy bình luận về chế độ ntpd & '11
-minute

-1

NTP đã có các cơ chế để biết nó trực tuyến hay ngoại tuyến và nó sẽ chuyển sang các nguồn ưu tiên thấp hơn theo yêu cầu. Rất dễ dàng để kiểm tra giá trị phạm vi để kích hoạt nguồn thay thế, nhưng tôi sẽ gắn bó với NTP. Như đã thảo luận dưới đây, việc theo dõi và sửa lỗi cho RTC trôi dạt có thể sẽ khó khăn.

Trong những ngày trước Internet, tôi đã sử dụng một chương trình sẽ gọi ra nguồn dữ liệu và đồng bộ hóa đồng hồ. Vẫn có thể có các dịch vụ có sẵn cung cấp nguồn thời gian qua modem. Điều này sẽ yêu cầu truy cập vào một đường dây điện thoại.

Có những vấn đề đã biết với đồng hồ địa phương, không áp dụng cho RTC. Một số vấn đề được ghi lại trong danh sách các vấn đề hệ điều hành đã biết của NTP . Đây có thể chiếm tài khoản cho đồng hồ trôi của bạn. Giải quyết chúng có thể giải quyết vấn đề của bạn. Trong trường hợp không có dấu tích bị bỏ lỡ, tôi đã tìm thấy nguồn thời gian (hệ thống) cục bộ có thể rất ổn định.

Bạn có thể sử dụng trình điều khiển đồng hồ Dumb (33) với chương trình ghi thời gian RTC thích hợp vào thiết bị / dev / dumbclockX.

Có một số trình điều khiển khác dựa trên đồng hồ Radio. Một số trong số này sử dụng các dịch vụ sóng ngắn như WWV và CHU, có thể hoạt động trong môi trường không có tín hiệu GPS. Đối với châu Âu, danh sách này sẽ bao gồm BBC, TDF, RBU và RMW.

Pavel Krejci cũng đã viết một trình điều khiển RTC, nhưng nó dường như không được tích hợp vào các trình điều khiển chính thức. Điều này có thể hoạt động với đồng bộ hóa loại PPS.

Có thể đo độ trôi RTC trước khi triển khai. Tuy nhiên, bạn sẽ cần đảm bảo rằng RTC không được cập nhật tự động. Khi đồng hồ hệ thống được cập nhật với chức năng adjtimex, RTC có thể được cập nhật cứ sau 11 phút.

NTP sẽ cập nhật đồng hồ khi được kết nối. Thông thường NTP sẽ từ chối thực hiện các điều chỉnh lớn cho đồng hồ hệ thống. Có các tùy chọn để điều chỉnh khoảng cách đồng hồ có thể được điều chỉnh.

Tôi đã đề xuất các tùy chọn để sử dụng RTC ở trên. Đồng hồ radio có thể phù hợp hơn đồng hồ GPS.

Đo độ trôi trong trường hợp không có nguồn thời gian đáng tin cậy để so sánh với nó có thể là một nỗ lực vô ích. Nếu giờ địa phương không ổn định, bạn không thể sử dụng nó để theo dõi RTC và ngược lại. Đo độ trôi trong khi NTP được kết nối sẽ không hoạt động nếu kernel đang cập nhật RTC cứ sau 11 phút. Các RTC tôi đã sử dụng có độ phân giải một giây, vì vậy chúng sẽ phải trôi đáng kể để có thể đo lường được một cách đáng tin cậy.


Tôi không hiểu làm thế nào điều này liên quan đến câu hỏi của tôi. Tôi không nghĩ vấn đề của tôi là thiếu trình điều khiển ... hay là vậy?
Nils Toedtmann

@NilsToedtmann Theo tôi có thể thấy không có trình điều khiển chính thức cho RTC. Tôi tin rằng localtrình điều khiển chỉ sử dụng đồng hồ máy chủ, mà bạn báo cáo trôi. Tôi sẽ cập nhật phản hồi của tôi.
BillThor

Khi bạn nói 'trình điều khiển', bạn có nghĩa là trình điều khiển hạt nhân Linux (trong đó có nhiều tính năng) hoặc tính năng ntpd? Thx cho lời khuyên của bạn, một số trong số chúng là thú vị - mặc dù tôi nghĩ rằng chúng nên được đăng chứ không phải là bình luận. Thx đặc biệt khi đề cập đến '11 phút nữa ', tôi đã quên mất điều đó. Tôi cập nhật câu hỏi của tôi.
Nils Toedtmann

@NilsToedtmann Không, ý tôi là trình điều khiển đồng hồ NTP. Đó là kinh nghiệm của tôi rằng RTC thường trôi, nhưng không ở mức cao nếu người đánh bóng tốt. Bọ ve bị thiếu có thể là một vấn đề với đồng hồ hệ thống.
BillThor
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.