Çevrimiçi durumdayken saati NTP ile ve çevrimdışıyken RTC ile senkronize edilsin mi?

Bir linux sistemini çevrim içi iken NTP ile ve çevrimdışıyken tahmin edilebilir şekilde sürüklenen bir RTC ile senkronize eden mevcut bir mekanizma var mı?

Uzak "toplayıcılar" işletiyoruz: sensör verilerini toplayan ve zaman damgası ekleyen yerleşik Linux sistemleri. 5 saniyenin altında, makul derecede küçük kalmak için saat hatalarına ihtiyacımız var. Genellikle saatlerini senkronize etmek için NTP kullanırız ve sistem çevrimiçi olduğu sürece iyi çalışır.

Sorun şu ki, bazı koleksiyoncular saatler, günler hatta haftalar boyunca inebilecek çok kötü bağlantılara sahip. Bu, yerel veri toplamayı durdurmaz, ancak NTP olmadan, Linux sistem saati kötü ve oldukça öngörülemez şekilde sürüklenir.

OTOH, donanımın RTC'si de ağır bir şekilde sürüklenir, ancak sabit bir oranda. RTC sürüklenme hızı karttan karta değişir, ancak kart başına sabittir ve ölçülebilir.

Sanırım ihtiyacımız olan şey aşağıdakileri yapan bir mekanizma:

• Bir kartın konuşlandırılmadan önce RTC kayma hızını ölçün
• Mümkün olduğunda sistem süresini devam eden / düzenli olarak NTP üzerinden ayarlayın
• NTP kullanılamadığında sistem saatini düzenli olarak RTC'den ayarlayın. Bilinen RTC sürüklenme oranını dikkate alın.
• İsteğe bağlı: Çevrimiçi durumdayken devam eden RTC sürüklenme oranını ölçün ve kaydedin (1)

'Mekanizma' ile, "çevrimiçi" ve "çevrimdışı" iki durumu işleyebilen, bakımlı, belgelenmiş bir yazılım ve / veya yapılandırma parçası anlamına gelir, sistem saatinin doğru zaman kaynağıyla (ntp vs. rtc), durum değişikliğini tespit edin ve RTC sapması için düzeltin. Özel bir ntpd yapılandırması / eklentisi, ayrı bir arka plan programı, bir cron işi veya başka bir uygulama olarak uygulanması önemli değildir.

Chrony'ye bir göz attım , ancak belgelerine göre , bizim durumumuzda RTC'den çok daha öngörülemez şekilde sürüklenen sistem saatinin sürüklenmesini tahmin etmeye çalışıyor . Chrony, RTC'yi yalnızca yeniden başlatmalarda zaman tutmak için kullanıyor gibi görünüyor.

(1) Not ntpd, çekirdeğin '11 dakikalık modunu 'etkinleştirir (rtc'yi her 11 dakikada bir sistem saatinden güncelleyin). Mevcut çekirdekler ve ntpd ile 11 dakikalık modu engellemenin bir yolu yok gibi görünüyor. Bu nedenle, ntpd çalışırken herhangi bir rtc sürüklenme bilgisi kaybolur (thx @billthor).

Güncellemeler / düzenlemeler:

• USB veya Seri yoluyla MSF veya DCF77 sinyali için harici bir radyo saati eklemeyi düşünüyoruz. Ancak donanımı yalın tutmayı tercih ediyoruz.
• Koleksiyonerlerimiz kapalı mekanda, genellikle bodrum kattadır. Bu yüzden GPS saatleri eklemek yardımcı olmaz.
• Debian 7 kullanıyoruz. Bunun anlamı util-linux-2.20.1, ntpdate-4.2.6p5, ntpd ntp-4.2.6.p5, chrony-1.24 (potansiyel olarak 1.30).
• Not bizim sorunumuz biz nasıl kullanılacağını bilmiyorum olmadığını ntpdate(8), hwclock(8), date(1)vb eklenen bölümüne bakın italik i 'mekanizma' ile ne anlama geldiği hakkında.
• '11 dakikalık mod 'hakkında dipnot eklendi
• İşte çevrimdışı senkronize olmayan ve RTC sürüklenme ile ilgili çok ilginç tartışma

Durumunuz olağandışıdır ve istediğinizi yapmak için standart ntpdtabanlı bir yapılandırma bulursanız şaşırırım. Bununla birlikte, şaşırmayı seviyorum ve bu bölümlerin çevresinde oldukça sık oluyor.

Ama birisi daha iyi bir fikir bulana kadar, böyle bir crontabgirişi düşündünüz mü?

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

IE, her beş dakikada bir saati senkronize etmeye çalışır ntpdateve başarısız olursa (ve sadece başarısız olursa) donanım saatini /etc/adjtimedosyaya göre (formatı ayrıntılı olarak man hwclockve ilk satırı bilginizi kullanarak doldurduğunuz) dosyaya göre ayarlayın söz konusu RTC'nin hızına göre), daha sonra sistem saatini RTC'den ayarlayın.

Bunun gibi bir çözüm ararsanız ve bu sistemlerden önemli sayıda dağıtıyorsanız, havuzla çalışmanın ve sunucuları kullanımınızla orantılı olarak katkıda bulunmanın kibar kabul edildiğini unutmayın. Daha fazla bilgiyi http://www.pool.ntp.org/en/vendors.html adresinde bulabilirsiniz .

NTP zaten çevrimiçi mi yoksa çevrimdışı mı olduğunu bilmek için mekanizmalara sahiptir ve gerektiğinde düşük öncelikli kaynaklara geçecektir. Alternatif bir kaynağı tetiklemek için erişim değerini kontrol etmek çok kolaydır, ancak NTP'ye bağlı kalırım. Aşağıda tartışıldığı gibi, RTC sapmasının izlenmesi ve düzeltilmesi zor olabilir.

İnternet öncesi günlerde bir veri kaynağına seslenecek ve saati senkronize edecek bir program kullandım. Modem üzerinden zaman kaynağı sağlayan hizmetler hala mevcut olabilir. Bunun için bir telefon hattına erişim gerekir.

Yerel saatle ilgili, RTC için geçerli olmayan bilinen sorunlar vardır. Bazı sorunlar NTP Bilinen İşletim Sistemi Sorunları listesinde belgelenmiştir . Bunlar saat kaymalarınızı hesaba katabilir. Bunları çözmek sorununuzu çözebilir. Kaçırılan kenelerin yokluğunda, yerel (sistem) zaman kaynağının çok kararlı olabileceğini buldum.

Dumb clock sürücüsünü (33) / dev / dumbclockX cihazına uygun RTC zamanını yazan bir programla kullanabilirsiniz.

Radyo saatlerine dayalı bir dizi sürücü daha var. Bunlardan bazıları, GPS sinyallerinin bulunmadığı ortamlarda çalışabilen WWV ve CHU gibi kısa dalga servislerini kullanır. Avrupa için bu liste BBC, TDF, RBU ve RMW'yi içerecektir.

Pavel Krejci de bir RTC sürücüsü yazdı, ancak resmi sürücülere dahil edilmemiş gibi görünüyor. Bu, PPS tipi senkronizasyon ile çalışabilir.

Devreye almadan önce RTC sapmasını ölçmek mümkün olmalıdır. Ancak, RTC'nin otomatik olarak güncellenmediğinden emin olmanız gerekir. Sistem saati adjtimex işleviyle güncellendiğinde, RTC her 11 dakikada bir güncellenebilir.

NTP, bağlandığında saati güncelleyecektir. Normalde NTP, sistem saatinde büyük ayarlamalar yapmayı reddeder. Saatin ne kadar ayarlanabileceğini ayarlamak için seçenekler vardır.

Yukarıda RTC kullanmak için seçenekler önerdim. Radyo saati, GPS saatinden daha uygun olabilir.

Karşılaştırma ile karşılaştırmak için güvenilir bir zaman kaynağının yokluğunda kaymanın ölçülmesi büyük olasılıkla boşuna bir çabadır. Yerel saat kararsızsa, RTC'yi izlemek için kullanamazsınız; Çekirdek RTC'yi 11 dakikada bir güncelliyorsa, NTP bağlıyken sapmanın ölçülmesi çalışmaz. Kullandığım RTC'lerin bir saniyelik çözünürlüğü var, bu yüzden güvenilir bir şekilde ölçülebilmeleri için önemli ölçüde sapmaları gerekecekti.