เหตุใด NTP จึงซิงค์กับ LOCAL มากกว่าเซิร์ฟเวอร์ระยะไกล

ดังนั้นฉันพยายามดีบักการตั้งค่า NTP ปัจจุบันของฉันและพบว่าเขาชดเชยจากเซิร์ฟเวอร์ที่กำหนดค่าเดียวของฉันนานกว่า 3 วินาทีและไม่ปรับ เครื่องหมายดอกจันบน LOCAL (0) ในเอาต์พุต ntpq ดูเหมือนว่าระบบกำลังซิงค์อย่างมีความสุขกับตัวเองมากกว่าเซิร์ฟเวอร์ 10.130.33.201 (ซึ่งเป็นอีกกล่อง linux ในระบบของเราที่เราต้องการให้ทุกอย่างเพื่อซิงค์)

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

และนี่คือไฟล์ ntp.conf ของฉัน เขียนโดยคนอื่นดังนั้นฉันไม่แน่ใจ 100% ว่าทุกอย่างถูกต้อง

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

ฉันได้อ่านเกี่ยวกับการระเบิดและ iburst และ minpoll / maxpoll ดังนั้นฉันจึงตระหนักว่าสิ่งเหล่านั้นอาจไม่จำเป็น แต่ฉันไม่คิดว่าเกี่ยวข้องกับปัญหาปัจจุบันของฉัน

นอกจากนี้เนื่องจากวิธีการนำไปใช้งานไฟล์กำหนดค่านั้นจะต้องใช้เวลามากในการเปลี่ยนแปลงดังนั้นฉันหวังว่าจะไม่มีการเปลี่ยนแปลงใด ๆ ฉันหวังว่านี่เป็นกรณีของฉันที่ไม่เข้าใจว่า NTP ทำงานอย่างไร

แก้ไข -

ดังนั้นดูเหมือนว่านี่จะเป็นคำถามที่ซ้ำกันแต่ฉันไม่รู้สึกว่าโปสเตอร์ได้คำตอบที่เพียงพอดังนั้นฉันยังอยากรู้ว่าทำไมเวลาท้องถิ่นถึงได้รับความนิยมบนเซิร์ฟเวอร์ นอกจากนี้ตามคำตอบด้านล่างนี้ฉันพยายามใช้preferคำหลักในบรรทัดเซิร์ฟเวอร์ของการกำหนดค่าและเริ่มต้นใหม่ แต่ดูเหมือนจะไม่มีผลใด ๆ

หากฉันลบบรรทัด "local" ทั้งหมดใน config ตามคำตอบของคำถามอื่น ๆ ที่แนะนำจะเกิดอะไรขึ้นหากเซิร์ฟเวอร์ไม่สามารถเข้าถึงได้ NTP ตายหรือพยายามต่อไปหรือไม่

การแก้ไขที่สำคัญ -

ตกลงปกติแล้วคือ 10.130.33.201 ("เซิร์ฟเวอร์") ไม่มีการเข้าถึงอินเทอร์เน็ตและไม่มีแหล่งเวลา GPS ที่จะใช้ ส่วนที่สำคัญคืออุปกรณ์ทั้งหมดในระบบมีเวลาเดียวกันกับเซิร์ฟเวอร์โดยไม่คำนึงว่าเวลานั้นถูกต้องจริงเพียงใด

ดังนั้นเพื่อดูว่าจะเกิดอะไรขึ้นฉันเพิ่มหนึ่งในเซิร์ฟเวอร์ NTP พูลลงในไฟล์ปรับแต่งของเซิร์ฟเวอร์ดังนั้นมันจะได้รับเวลาจากที่นั่นแทนที่จะรับเวลาจากท้องถิ่น ตอนนี้ได้รับเวลาอย่างถูกต้องจากเซิร์ฟเวอร์เวลา NTP

หลังจากที่ฉันทำอย่างนั้นตอนนี้ลูกค้าซิงค์กับเซิร์ฟเวอร์มากกว่าที่จะชอบ LOCAL (0)

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

คำถามใหม่ - เมื่อเซิร์ฟเวอร์ของฉันใช้โลคัล (ตัวอย่างดั้งเดิมที่ให้มา) ดูเหมือนว่าลูกค้ากำลังพูดว่า "โอ้ 10.130.33.201 ใช้ LOCAL (0) อืมฉันมีเซิร์ฟเวอร์ LOCAL (0) - - ฉันจะใช้สิ่งนั้นโดยตรงแทนที่จะได้รับข้อมูลเดียวกันผ่านทาง 10.130.33.201 "

เป็นอย่างนั้นเหรอ? พวกเขาพยายามที่จะ "โดยตรงไปยังแหล่งที่มา" ซึ่งไม่ถูกต้องในท้องถิ่น (0)? ฉันต้องการเซิร์ฟเวอร์ของฉันเพื่อรับเวลาจาก LOCAL (0) และฉันต้องการให้ลูกค้ารับเวลาจากเซิร์ฟเวอร์ ตอนนี้การลบเซิร์ฟเวอร์ "ท้องถิ่น" ออกจากไฟล์ปรับแต่งไคลเอนต์เป็นเพียงตัวเลือกเดียว แต่ฉันอยากจะเข้าใจว่าทำไมถึงเกิดเหตุการณ์นี้ขึ้นและถ้าเป็นไปได้ให้หลีกเลี่ยงการเปลี่ยนการตั้งค่าของพวกเขา สภาพแวดล้อมของเรา...).

นอกจากนี้ดูเหมือนว่าจะซ้ำกันโดยไม่มีคำตอบที่ดี

ด้วยการกำหนดค่าเซิร์ฟเวอร์ NTP เพียงตัวเดียวอัลกอริทึมจึงไม่แน่ใจว่าใครจะเชื่อถือได้ แม้ว่าสตราตัมจะต่ำกว่าด้วยรีโมตโฮสต์ฉันเดิมพันว่าอัลกอริทึมคิดว่าเวลาท้องถิ่นน่าเชื่อถือมากขึ้น

ลองใช้preferคำหลักกับserverคำสั่งของคุณเพื่อตั้งเป็นแหล่งเวลาพิเศษ

แก้ไข -

ดังนั้นดูเหมือนว่านี่จะเป็นคำถามที่ซ้ำกัน แต่ฉันไม่รู้สึกว่าโปสเตอร์ได้คำตอบที่เพียงพอดังนั้นฉันยังอยากรู้ว่าทำไมเวลาท้องถิ่นถึงได้รับความนิยมบนเซิร์ฟเวอร์

สำหรับคำตอบที่เพียงพออย่างแท้จริงคุณจะต้องขุดเข้าไปในลำไส้ของอัลกอริทึมที่ซับซ้อนมาก เอกสารไม่ได้เจาะจงมากเกินไปแต่ฉันมั่นใจว่ามีกระดาษขาวหรือสเปคอยู่ข้างนอก

หากฉันลบบรรทัด "local" ทั้งหมดใน config ตามคำตอบของคำถามอื่น ๆ ที่แนะนำจะเกิดอะไรขึ้นหากเซิร์ฟเวอร์ไม่สามารถเข้าถึงได้ NTP ตายหรือพยายามต่อไปหรือไม่

NTP daemon ไม่ตายหรือหยุดทำงาน แต่จะออกจากการซิงโครไนซ์เวลาหลังจากที่ไม่สามารถเข้าถึงเซิร์ฟเวอร์ระยะไกลได้ นี่คือเหตุผลที่แนวทางปฏิบัติที่ดีที่สุดจะแนะนำเซิร์ฟเวอร์ระยะไกลอย่างน้อยสามแห่งและไม่ควรใช้ LCL เว้นแต่คุณจะถูกตัดการเชื่อมต่อจากเครือข่าย มีการแนะนำเซิร์ฟเวอร์สามแห่งเพราะเมื่อมีเพียงสองเซิร์ฟเวอร์และพวกเขาไม่เห็นด้วยซึ่งจะเลือกได้อย่างไร เซิร์ฟเวอร์ที่สามควรช่วยอัลกอริทึมกำจัดเซิร์ฟเวอร์ปลอม

driftfileสุดท้ายนี้ผมเพิ่งสังเกตเห็นว่าคุณไม่ได้กำหนด สิ่งนี้อาจช่วยได้อย่างไร

ดูเหมือนว่าฉันชอบช่วงเวลาของการชดเชย (ความแตกต่างระหว่างเวลาระบบของคุณและช่วงเวลาของโฮสต์ NTP) นั้นแตกต่างกันมากเกินไปสำหรับ NTP ที่จะตั้งค่าอย่างถูกต้อง

คำแนะนำของฉัน,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

คุณควรไม่มีปัญหาหลังจากนั้น

Stratum ของ 10.130.33.201 ในฐานะเซิร์ฟเวอร์ LOCAL คือ 9 ซึ่งทำให้ stratum ท้องถิ่นคำนวณจากสิ่งนี้ (9 + 1 = 10) แข่งขันกับเซิร์ฟเวอร์ LOCAL ท้องถิ่นที่ stratum 10 เนื่องจาก Stratum ท้องถิ่น LOCAL ไม่มีเครือข่ายล่าช้าหรือกระวนกระวายใจ อาจดูดีกว่าเล็กน้อยสำหรับ ntpd จากรีโมท

หากคุณต้องการให้การกำหนดค่านี้ทำงานให้ตั้งค่าเซิร์ฟเวอร์ 'ต้นแบบ' LOCAL เป็น stratum ที่ต่ำกว่า 9 ไม่ต่ำเกินไปถ้าคุณต้องการให้เวลาที่สามารถติดตามได้ไปยังเซิร์ฟเวอร์ stratum 1 เป็นที่ต้องการ

ฉันรู้ว่านี่เก่า แต่ฉันคิดว่าคุณพูดถูก ไม่มีใครแสดงวิธีการแก้ปัญหา ntpd ใด ๆ ปรากฎว่ามันเป็นไปได้

ฉันคิดว่าคุณกำลังติดตามถูกเมื่อคุณสงสัยว่าการใช้ LOCAL (0) ในพื้นที่และบนเซิร์ฟเวอร์ต้นน้ำอาจเป็นปัญหา

แน่นอนมันอยู่บนเกาะแห่งเซิร์ฟเวอร์ 4 แห่งที่ฉันมีปัญหาคล้ายกัน สิ่งเหล่านี้ถูกตั้งค่าให้เป็นเพื่อนของกันและกันดังนั้นอาจเป็นปัญหาที่แตกต่างสำหรับคุณ

ก่อนอื่นมีวิธีที่ดีกว่าในการจัดการเวลาบนเกาะที่เรียกว่าโหมดเด็กกำพร้าที่รองรับกับรุ่น ntpd ในช่วงไม่กี่ปีที่ผ่านมา:

โหมดเด็กกำพร้าใน doc.ntp.org

เริ่มแรกเซิร์ฟเวอร์ทั้ง 4 เครื่องมีสแตรทเท่ากัน 10 อันและต้องการนาฬิกาในเครื่องของพวกเขา ฉันได้แก้ไขเรื่องนี้แล้วและพวกเขายังชอบนาฬิกาท้องถิ่นของพวกเขา (สตราตัมดูเหมือนจะสำคัญ)

ฉันใช้คำสั่ง ntpq pe (เพียร์) เป็น rv เพื่อรับการจัดการกับสิ่งที่เกิดขึ้น คุณต้องใช้ rv (readvar) บนหมายเลขการเชื่อมโยงสำหรับเซิร์ฟเวอร์เพื่อถ่ายโอนข้อมูล pe และดูเหมือนว่าจะเรียงลำดับตามดัชนีเดียวกันเพื่อให้คุณได้จำนวนตามที่ต้องการ เช่นเดียวกับเขตข้อมูลที่เรียกว่าเงื่อนไขที่อาจแสดงค่าปฏิเสธถ้ามันไม่ชอบเซิร์ฟเวอร์

ในเอาต์พุต rv เป็นฟิลด์ที่เรียกว่าแฟลช ถ้าทุกอย่างดีนี่จะเป็นศูนย์ ถ้าไม่ใช่มันเป็น bitmask (แสดงเป็น hex) ของปัญหา พวกเขาสามารถดูได้ที่นี่:

ถอดรหัสภายใน ntpd

ปัญหาที่ฉันมีคือ 0800 peer_loop ปรากฎว่า refid ของนาฬิกาเป็นสิ่งสำคัญ การเห็น LOCAL (0) ทั้งบนนาฬิกาในตัวเครื่องและจากเซิร์ฟเวอร์ระยะไกลทำให้ ntpd คิดว่ามีลูป David Mills ยืนยันว่าในโพสต์บน comp.protocols.time'How เพื่อหลีกเลี่ยงการวนซ้ำใน NTP '(ฉันมีลิงก์ถึงขีด จำกัด ของฉันแล้ว 2 รายการขออภัย!)

การใช้อาร์กิวเมนต์ refid เพื่อเหลวไหลเพื่อตั้งค่า refid ที่ไม่ซ้ำกัน - มันยังคงแสดงเป็น LOCAL (0) ที่ผู้รับ

สิ่งที่ดูเหมือนจะใช้งานได้คือการใช้หมายเลขอินสแตนซ์เฉพาะสำหรับไดรเวอร์ท้องถิ่น 127.127.1. [0-3] ใช้ ID เดียวกันบนทั้งเซิร์ฟเวอร์และสายเหลวไหล เมื่อฉันทำสิ่งนี้เซิร์ฟเวอร์โดยทั่วไปจะซิงค์กับเซิร์ฟเวอร์ stratum ที่ต่ำที่สุดซึ่งมักจะใช้นาฬิกาท้องถิ่น อย่างไรก็ตามบางครั้งก็พยายามใช้หนึ่งในเซิร์ฟเวอร์อื่นที่ใช้เป็นแหล่งข้อมูล อย่างไรก็ตามเวลาที่ได้รับการซิงค์และดูเหมือนจะอยู่ในลักษณะนั้น

อาจจะสายเกินไปที่จะช่วยเหลือ แต่ฉันขอเสนอให้แสดง NTP สามารถแก้ไขได้ด้วยตรรกะและการแก้ไขปัญหา ฉันใช้เวลาหลายชั่วโมงกว่าจะได้คำตอบโดยการลองผิดลองถูกจากนั้นก็พบเอกสารในภายหลัง

ใช้ iburst เพื่อบังคับให้เซิร์ฟเวอร์ส่งคำร้องขอ NTP ไปยัง NTS ที่ต้องการแม้ว่าคำร้องขอเดียวจะล้มเหลว