NTP geçiştirme ağ kaynağı katmanı

ntpdBir ağ kaynağının katman düzeyini geçecek şekilde yapılandırmak mümkün müdür ?

İlk bakışta, fudgedirektifin bunu başarabileceğini düşündüm , ancak ntp.conf(5)man sayfalarına göz attıktan sonra , bu direktifin sadece Referans Saatler için geçerli olduğunu buldum.

Birkaç ayrıntı:

ntpdLAN istemcileri için birincil zaman kaynağı olarak çalışan bir yerel sunucu var . Bu sunucu ntp.org havuzuna işaret eder ve genellikle katman düzeyi 3'ü korur.

Ana sunucuma ek olarak, birincil işi duvar saatlerini kablosuz olarak senkronize eden bir üçüncü taraf ağ cihazım var. RF iletimi. Cihazın teknik özellikleri bunun "RFC2030 uyumlu bir Zaman Sunucusu" olduğunu söylüyor, ancak aksi halde hemen hemen bir kara kutu. Cihazı ana sunucumu kullanması için tek zaman kaynağı olarak yapılandırdım:

kara kutu yapılandırması http://www.freeimagehosting.net/uploads/21bafb12bd.png

ntpdKişisel bilgisayarımda hem ana NTP sunucumu hem de kablosuz vericiyi zaman kaynağı olarak kullanacak şekilde yapılandırdığımda sorunum ortaya çıktı . Yerel ntpd sorgularken, "kara kutu" (10.xxZ) tercih edilen zaman kaynağı olduğunu fark ettim:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x10.x.x.X        69.164.222.108   3 u   48   64  177    0.501  370.029   1.530
*10.x.x.Z        10.x.x.Z         2 u   50   64  377    1.354  -23.681  14.179

Sunucu bu yana 10.x.x.Z'ın sadece zaman kaynak olan sunucu 10.x.x.X(stratum 3 olan), bu olmalıdır ben Üretici, Stratum seviyesini sabit kodlanmış inanıyoruz Stratum 4. ol.

Daha yüksek tabaka seviyesine rağmen makinemi "iyi" (10.xxX) sunucuyu tercih etmenin herhangi bir yolu var mı? preferYönergeyi yerel dosyamda da denedim ntp.conf, ancak boşuna, küçük kara kutu her zaman kazanır: /

Değeri ne olursa olsun, yerel makinem Mac OS X 10.6 kullanıyor.

$ ntpq -c rv | grep version
version="ntpd 4.2.4p4@1.1520-o Mon May 18 19:38:25 UTC 2009 (1)",

Biraz daha araştırma yapıldıktan sonra, bir ağ kaynağının katman seviyesi " mümkün değil " gibi görünüyor . Bu yüzden devam ettim ve dtoubeli'nin cevabını denedim . Şaşırtıcı bir şekilde, sadece yerel zaman sunucumu katman seviye 2 (3. taraf cihaza eşit) yapmak her zaman tercih edilen zaman kaynağı olmasına neden olmadı. Yerel ntpd'm hala ikisini de "yanlış keneler" olarak yönetirdi. Hangi nedenle, emin değilim, ama tahmin ediyorum çünkü onlar sadece iki zaman kaynağıydı ve zamanları çok uzaktı.

Buradaki en büyük sorun, 3. taraf cihazımın çok tutarlı bir zamana sahip görünmemesi, aslında çok dalgalanıyor. Sorunumun çözümü, diğer birkaç doğru zaman kaynağını (pool.ntp.org) ekledi /etc/ntp.conf. Şimdi yerel sunucum her zaman tercih edilen zaman kaynağı olarak seçiliyor, çoğu zaman havuzdaki bazı sunuculardan daha yüksek bir katman seviyesine sahip olmasına rağmen.

Yerel ntpd'nizi stratum 2'de çalıştırmayı deneyebilirsiniz. Bunun yerine pool.ntp.org adresine yönlendirmek yerine 5-7 stratum 1 sunucusunun bir listesini oluşturun ve bunları doğrudan yapılandırmaya ekleyin. Tabaka 1'deki referans sunucusu ile sizinki katman 2'de preferçalışacaktır. O zaman seçeneğiniz işe yarayabilir.

Ancak, deneyimimden dolayı, tabaka kaynağı seviyesi birincil kaynak seçiminde her zaman kazanan faktör değildir. Gecikmenin ve titremenin de önemli bir etkisi olduğunu düşünüyorum. Birkaç kez düşük stratum sunucusunun birincil kaynak olarak seçildiğini fark ettim, ancak yalnızca en düşük gecikme süresine sahip olduğu için birkaç yüksek stratum sunucusu mevcuttu. Bu yüzden önerilen yaklaşımın işe yarayacağını garanti edemem.

Yerel ağımızda ntpq'de bir falsetick durumu (x) veren bir "yüksek tabaka (10)" donanım GPS zaman kaynağım var server [x.x.x.x] true, ntp.conf içinde (x = IP adresi) kullanmanın falsetick denetimini atlayacağını, olası bir aday olmasını sağlar. Tabaka sayısı her zaman daha yüksek öncelik anlamına gelmez.

Bu sunucu 10.xxZ'yi referans olarak beğenmediyseniz, bu hile yapmalıdır:

server 10.x.x.Z noselect 

Bu, sunucunun yalnızca izleme nedenleriyle kullanılması gerektiğinde kullanışlıdır. alternatif olarak şunları da yapılandırabilirsiniz:

server 10.x.x.X prefer

Bu nedenle, 10.xxX mevcutsa 10.xxZ kullanılmayacaktır.

Tercih edilmesinin bir nedeni, diğer zaman sunucunuza yakın zamanda ulaşılamamış olmasıdır. Erişim sütununa bakın?