การกระจาย NTP คืออะไรและฉันจะควบคุมมันได้อย่างไร

เราเปิดตัวเซิร์ฟเวอร์ Ubuntu 14.04 บนเครือข่ายแยกที่ใช้ ntpd 4.2.6p5 ซึ่งกำหนดค่าให้ใช้เซิร์ฟเวอร์ NTP หลายตัวตามที่ลูกค้าให้บริการ (ไม่สามารถเข้าถึง pool.ntp.org) อุปกรณ์ไคลเอ็นต์เทอร์มินัลโง่ของเราใช้ BusyBox เวอร์ชันเก่า (1.00-rc2) และntpclient 2010จาก Larry Doolittle รุ่นเก่า

การตั้งค่านี้ใช้งานได้ดีมาหลายปี แต่เมื่อเร็ว ๆ นี้เราได้พบสิ่งกีดขวางบนถนนกับลูกค้าใหม่ พวกเขาให้เรามีที่อยู่เซิร์ฟเวอร์ NTP 5 แห่งซึ่งดูเหมือนว่าจะทำงานได้ดีด้วยตัวเองเท่าที่ntpdate-debianเกี่ยวข้องกับเซิร์ฟเวอร์ Linux อย่างไรก็ตามในด้าน BusyBox ntpclientบ่นกับ "การกระจายสูงเกินไป" จากเอาต์พุตดีบักntpclientรับ "1217163.1" จากเซิร์ฟเวอร์ NTP แต่ค่าสูงสุดที่รองรับคือค่าสัมบูรณ์ (65536)

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

อุปกรณ์เหล่านี้ทั้งหมดใน LAN เดียวกันดังนั้นฉันจึงรู้สึกงุนงง ตกตะลึง

นี่คือntpq -pnผลลัพธ์จากเซิร์ฟเวอร์ Ubuntu 14.04:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

คำถามของฉันคือ:

1. การกระจายตัวคืออะไรและอะไรที่สามารถเปลี่ยนแปลงมูลค่าของมันได้?
2. ฉันสามารถเรียกใช้คำสั่งใดเพื่อรับรายละเอียดเพิ่มเติมจากเซิร์ฟเวอร์ NTP
3. ความผิดอาจอยู่ที่ฝั่งเซิร์ฟเวอร์อูบุนตูntp.confหรือไม่เหมาะสม? ไม่มีอะไรพิเศษจริงๆที่นั่น
4. การสลับไปใช้ลำดับเหตุการณ์จะเปลี่ยนแปลงอะไรในกรณีนี้หรือไม่

ฉันเห็นความสับสนเกิดขึ้นในคำตอบที่นี่ สำหรับ starters ntpclientอย่างน้อยก็ใน-sโหมดไม่ได้ทำหน้าที่เป็นไคลเอนต์ NTP เต็มมันเป็นเพียงการส่งและรับหนึ่งแพ็คเก็ตดังนั้นจึงไม่มี "8 แพ็คเก็ตล่าสุดที่ได้รับ" มันไม่ได้ประเมินการกระจายตัวของมันเลย

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

จุดหนึ่งของความสับสนที่นี่คือในขณะที่ ntpq และแสดง chrony การกระจายตัวและการกระจายของรากในไม่กี่วินาทีซึ่งเป็นสิ่งที่ผู้คนจะใช้ในการมองหาที่จะแสดง NtpClient ในmicroseconds ไม่ว่าค่า 1217163 ยังคงค่อนข้างสูง เซิร์ฟเวอร์ NTP ที่ดีรู้เวลาภายในไม่กี่มิลลิวินาที สิ่งที่ไม่ดีภายในไม่กี่สิบหรือหลายร้อยมิลลิวินาที คุณกำลังบอกคุณว่าเวลาของมันสามารถเชื่อถือได้ภายใน +/- 1.2 วินาทีเท่านั้น

คุณสามารถรับ ntpclient เพื่อซิงโครไนซ์กับเซิร์ฟเวอร์นี้โดยการผ่าน-x 0หรือ-tตัวเลือก (ขึ้นอยู่กับรุ่นของ ntpclient) ซึ่งปิดใช้งานการตรวจสอบสติ NTP หากคุณต้องการเวลาที่แม่นยำเท่านั้น (ภายในไม่กี่วินาที) นั่นอาจจะดีพอ อย่างไรก็ตาม ntpclient ค่อนข้างสมเหตุสมผลในการปฏิเสธที่จะซิงโครไนซ์กับเซิร์ฟเวอร์ที่ไม่ดี คุณntpqเอาท์พุทบนเครื่องอูบุนตูมีการแสดงกระวนกระวายใจของหลายร้อยมิลลิวินาทีสำหรับทุกเซิร์ฟเวอร์ของตนถึงแม้ว่าพวกเขาจะมีความล่าช้าต่ำซึ่งระบุถึงเครือข่ายที่ไม่น่าเชื่อถือมาก, สมรู้ร่วมคิดของทั้งหมดของเซิร์ฟเวอร์เพื่อให้เวลาที่ผิดปกติหรือพื้นฐาน ปัญหาการจับเวลาในเซิร์ฟเวอร์

นอกจากนี้ยังเกี่ยวกับฉันว่าเซิร์ฟเวอร์ 10.31.10.22 กำลังโฆษณา refid ของLOCL(นาฬิกาที่ไม่มีระเบียบในท้องถิ่น) แต่มี stratum เป็น 1 โดยปกตินาฬิกาท้องถิ่นจะ fudged เป็น stratum 10 เพื่อที่จะใช้เป็นแหล่งการซิงโครไนซ์สุดท้ายเท่านั้น เพื่อป้องกันไม่ให้ฝูงแฉกกัน ทั้ง 10.31.10.22 ได้รับการกำหนดค่าผิดพลาดและให้เวลากับเครือข่ายที่เหลือหรือมีระเบียบวินัยในช่วงเวลาที่ดีโดยโปรแกรมบางโปรแกรมที่อยู่นอกเหนือการควบคุมของ NTP ซึ่งในกรณีที่การกำหนดค่าผิดพลาดนั้นเป็นเพียงการโฆษณาLOCLrefid มันควรจะถูกแทนที่ด้วยเช่นGPSหรือสิ่งที่ให้เวลา

เพียงคำตอบบางส่วนสำหรับ "การกระจายตัวคืออะไร":

การเดินทางไปกลับโดยทั่วไปของ NTP:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

สิ่งนี้ให้ค่าสองค่าชดเชย (ความแตกต่างของเวลาระหว่างไคลเอนต์และเซิร์ฟเวอร์) และความล่าช้า (จำเป็นสำหรับเวลาเดินทางของเครือข่าย) ด้วยสูตรต่อไปนี้:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

ลูกค้าเลือกออฟเซ็ตปัจจุบันจาก 8 แพ็กเก็ตล่าสุดที่ได้รับเลือกอันที่มีความล่าช้าน้อยที่สุด

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

การกระจายตัวและความเบ้ของคุณนั้นมีขนาดใหญ่มากมีการชดเชยที่ใหญ่มากจากนาฬิกาท้องถิ่นไปยังเพียร์นั้น คุณควรเปรียบเทียบออฟเซ็ตกับโลคัลdateแล้วตั้งนาฬิกาด้วยตนเอง

รับ ntpd ทำงานและแสดงntpq -pจากโฮสต์โดยใช้เพียร์ทั้งหมด มันจะเลือกอันที่ดีกว่า

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

มันควรจะเพียงพอเพื่อให้แน่ใจว่านาฬิกาท้องถิ่นไม่ไกลเกินไปในการเริ่มต้น (แม้สองสามชั่วโมงจะยังคงเป็นที่ยอมรับ) ทั้งโดยการปรับนาฬิกา (และวันที่!) ใน BIOS หรือโดยการออกntpdateหนึ่งครั้งก่อนเริ่มntpdบนลูกค้า