Saat kaymasını nasıl ölçebilir ve önleyebilirim?

15

Birkaç üretim platformunda, gün saatinin periyodik olarak ileri veya geri atladığını gösteren semptomlar gözlemledik. Sıçramalar tipik olarak 1 saniye civarındadır, tipik olarak iptal edilir (daha sonra kısa bir süre sonra ileriye ve sonra geriye doğru atlar) ve günde yaklaşık 50 kez gerçekleşir. Bu sapma, en yoğun uygulama kullanım zamanlarında ve günlük yedeklemeler gibi yüksek disk G / Ç işlemleri dönemlerinde en belirgindir. Bu sürüklemeler yumuşak gerçek zamanlı hassas uygulamamızı etkiliyor.

Sistemler, 3.0.58-0.6.6 varsayılan çekirdeğe sahip SLES 11SP2 çalıştıran Oracle Netra X4250 ve Netra X4270 sunuculardır.

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

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

NTP'yi devre dışı bıraktık , ancak bunun sürüklenme üzerinde herhangi bir etkisi olmadı. Gündüz saat kaymasını ölçen araçlar var mı? Bundan nasıl kaçınabiliriz?

Bunlar üretim platformlarıdır ve sorunu laboratuvarlarımızda yeniden oluşturamayız, bu nedenle deneme yeteneğim sınırlıdır. Kendi aygıtlarıma bırakılırsa, sapmayı ölçmek için bir araç yazacağım ve belki de HPET saat kaynağını deneyeceğim.

linux sles clock

— brett
kaynak

5

NTP'yi devre dışı bırakmak saatleri çok daha dengesiz hale getirir ... NTP'nin saati sabit tutmaması için görebilmemin tek nedeni, saatin boşa gitmemesi ve NTP'nin güncellemeyi reddetmesidir (bkz. ntpdate(8)Veya ntpd(8)).

— vonbrand

1

NTPD saat kaymasını izler ve düzeltir, ancak sahip olduğunuz şey sürüklenmez. Kayma, zaman içinde kabaca aynı miktarda sürekli olarak aynı yöndedir. Rastgele ileri ve geri atlarsa, bunu tahmin etmenin ve uyum sağlamanın bir yolu yoktur.

— Patrick

1

@Patrick'in söylediği doğru, tarif ettiğiniz sorun, günde birkaç kez ileri ve geri zaman içinde süreksiz bir sıçramadır. NTP driftte iyi çalışır ancak bu konuda size çok yardımcı olmaz. Sistem tarihinizi muhtemelen yalnızca 1 saniye çözünürlüğe sahip olan harici bir zaman kaynağına sıfırlayan bir şey olabilir. Sunucularınız x86 * ise, donanım RTC kaynağı olabilir ve bazı cron suçlu iş olabilir. Saat ofsetini ölçerken, iyi bir stratum 1 saat referansı kullanılması şartıyla Bratchley'nin ntpdate cevabı makul bir yaklaşımdır: dakikada bir kez çalıştırın ve bir resim için sonucu gnuplotlayın.

— duanev

1

Yeni bir sunucuda ( drdobbs.com/embedded-systems/… ) başlayarak bu NTP değerlendirmesiyle karşılaştık . Yeni bir kristal öğrenmek NTP saatlerini alır. Gerçekten kötü kristaller için NTP, eğitim sırasında saati önemli miktarlarda birkaç kez 'adımlamak' zorunda kalacaktır (bu makaledeki Şekil 4 ve 5'e bakın). 118ppm'lik ntp.drift cinsinden son değer günde 10 saniye veya 30 dakikada bir 208 ms'dir. OP'nin gördüğü şey bu olmasa da, NTP başlangıçta zaman içinde belirgin sıçramalara neden olabilir.

— duanev

8

Gündüz saat kaymasını ölçen araçlar var mı?

Fark ettiğim tek araç, yeterli olması gereken NTP araçları. Aslında ntpd'yi belirli bir saat kaynağına göre senkronize edilecek şekilde yapılandırmanız gerekmez, sadece hesaplanan ofseti getirme -dseçeneğini kullanabilirsiniz ntpdate.

Misal:

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

-d NTP'nin sistem saatine gerçekten dokunmadan çalışan hata ayıklama seçeneğidir.

Bundan nasıl kaçınabiliriz?

Muhtemelen donanım saatinden kaynaklandığından, bunu dev / test ortamlarında çoğaltamayacağınıza çok şaşırmadım. Birisiyle donanım desteğiniz varsa, makinelerinizin bakımını yapmaya çalışırım. Bir olasılık, bu üretim makinesi için dev makinelerinden birinin ticaretini yapmak, eski PROD sistemlerini sabitlemek ve şimdi PROD'da bulunanın yerini almak için bir dev makinesi olarak yeniden tanıtmaktır.

Kısacası, donanım saat kaynağını değiştirmek yapabileceğiniz her şeyle ilgilidir. Eğer takas şeyi yapmazsanız veya yapamazsanız , hpet yoluna gitmenizi öneririm . Saat kaynağı değişikliğinin sistem hizmetleriyle karıştırılıp karıştırılmadığını test edebilir ve daha sonra bunu bir dolu mary olarak üretime dağıtabilirsiniz.

— Bratchley
kaynak

"Saat sapmasını ölçmek" ile, NTP'nin verdiği gibi bir referans zaman kaynağından sapma demek istemedim. Sürekli bir zaman aralığında, günün saati içinde "sıçramaları" algılayabilen bir araç demek istedim. Örneğin, her 50 ms'de bir örnekleme zamanı alın ve son örneklemedeki farkın 50 ms'den çok uzak olup olmadığını bildirin. Böyle bir araç, gündüz saatinin herhangi bir nedenle altta yatan donanım saatinden sürüklenip sürüklenmediğini gösterecektir.

— brett

1

Böyle bir müdahalenin varlığı muhtemelen çözmeyi umduğunuzdan daha fazla performans düşüşüne neden olmaz mı? Her durumda, bu bir donanım problemidir, bu nedenle donanımı servise götürmeniz veya bu sorun olmadan bir saat kaynağı kullanmanız gerekecektir. tscCPU'ya dayanmaktadır, bu nedenle daha yüksek CPU etkinliğinin donanım saatiyle ilgili bir sorunu zaten tetiklemesi mantıklıdır. Hpet sizin için yeterince hızlıysa, bunu denemeniz, servis almanız veya takas işini yapmanız gerekebilir. Sizin için görebildiğim tek seçenek bunlar.

— Bratchley

3

Bir çözüm kullanmak HPET

Ayrıca bkz. Yüksek Hassasiyetli Etkinlik Zamanlayıcısı

Önyükleme parametresi olarak ayarlamak için şunu kullanın:

clocksource=hpet

Eski donanımlarda TSCgenellikle kararsızdı ve çekirdek tarafından devre dışı bırakıldı.

Çok çekirdekli / hiper iş parçacıklı CPU'ların, birden fazla CPU'lu sistemlerin ve hazırda bekleme işletim sistemlerinin ortaya çıkmasıyla TSC'ye, doğru sonuçlar sağlamak için güvenilemez ...

Vikipedi: Zaman Damgası Sayacı

Saat titremesi belirtileri sergileyen bir üretim sisteminde saat kaynağını hpet'e çevirdim. Bunun gözlemlenen saat titreşimi semptomları üzerinde hiçbir etkisi yoktu.

— brett

HPET harici bir donanım zamanlayıcıdır ve titremez. Yani bu çözüm yanlış bir yol gibi görünüyor. Özellikle sanallaştırma kullanılırken eski donanımlarda birçok zamanlama sorunu vardı. Bunu farklı bir yazılımla da kontrol ettiniz mi?

1

Saat ölçümlerini uygulamamızın sergilediği gecikme belirtileriyle ilişkilendirmek için daha ayrıntılı bir araç yazdım. Bu araç, daha önce Linux saatinin saatinde titremekten şüphelendiğim şeyi göz ardı ediyor gibi görünüyor.

Uzun lafın kısası, ilk hipotezim geçersizdi. Ama cevaplardan ve bağlantılardan Linux saatleri hakkında çok şey öğrendim, bu yüzden cevap veren herkese teşekkürler!

— brett
kaynak

3

(...) ilk hipotezim geçersizdi Bize asıl nedenin ne olduğunu söyleyebilir misiniz?

— Piotr Dobrogost

0

Birisi değiştirmedikçe saatin monoton olması gerekmez mi? Geriye doğru atlamalar mümkün olmamalıdır. Saati ayarlayan bir şey olmalı - bir cron işi veya başka bir arka plan programı (örneğin, bir çağrı hwclock --adjust). NTP'nin kendisinin sürüklenme istatistiklerini güncellediğini ve rutin olarak telafi ettiğini hatırlıyorum ve uzun bir süre ntp'yi çalıştırıp büyük bir ofset elde ederseniz, sıfırlamazsanız günler sonra zamanını karıştırır /etc/adjtime. Bunun gibi bir şeye sahip olabilirsiniz - periyodik olarak zaman kaymasını yeniden ayarlayan (ve sıçramalara neden olan).

ntp aslında bu sorunla mücadele etmek içindir.

— Oryon
kaynak

Ben de öyle düşünmüştüm. Donanım saati kaynaklarını okumam sayacın monoton olarak artması gerektiğini gösteriyor. Eğer bu doğruysa, en kötüsü düzensiz kene oranlarını gözlemlemeliyiz, ama asla geri atlamayız. Çok işlemcili bir sistemde, tsc'nin işlemciler arasında senkronize edilmesi gerektiğini anlıyorum - belki de geriye doğru sıçramalara neden olan şey budur?

— brett