มีงานวิจัยเกี่ยวกับความแม่นยำของ NTP หรือไม่?

เท่าที่ฉันทราบความถูกต้องของการทำข้อมูลให้ตรงกันของ NTP นั้นขึ้นอยู่กับเครือข่าย ฉันเห็นตัวเลขบางส่วนจาก 50 microseconds เป็น "ต่ำกว่าหนึ่งวินาที" ผ่านอินเทอร์เน็ต นี่มันแตกต่างกันมาก

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

ได้มีการกล่าวในhttp://www.ntp.org/ntpfaq/NTP-s-algo.htm :

จำเป็นต้องใช้ความแตกต่างของเวลาน้อยกว่า 128ms ระหว่างเซิร์ฟเวอร์และไคลเอนต์เพื่อรักษาการซิงโครไนซ์ NTP ความถูกต้องทั่วไปบนอินเทอร์เน็ตมีตั้งแต่ประมาณ 5ms ถึง 100ms ซึ่งอาจแตกต่างกันไปตามความล่าช้าของเครือข่าย การสำรวจล่าสุด [2] แนะนำว่า 90% ของเซิร์ฟเวอร์ NTP มีความล่าช้าของเครือข่ายต่ำกว่า 100ms และมีการซิงโครไนซ์ประมาณ 99% ภายในหนึ่งวินาทีกับเพียร์ซิงโครไนซ์

ด้วยการซิงโครไนซ์ PPS ความแม่นยำ 50 และความเสถียรต่ำกว่า 0.1 PPM สามารถทำได้บน Pentium PC (เช่น Linux ที่ใช้งาน)

นั่นคือสิ่งที่ แต่อาจมีการวิเคราะห์อย่างละเอียดเพิ่มเติมในหัวข้อ

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

หากปล่อยให้ทำงานต่อเนื่องไคลเอนต์ NTP บน LAN ที่รวดเร็วในสภาพแวดล้อมที่บ้านหรือที่ทำงานสามารถรักษาการประสานให้ตรงกันภายในหนึ่งมิลลิวินาที เมื่ออุณหภูมิแวดล้อมเปลี่ยนแปลงน้อยกว่าหนึ่งองศาเซลเซียสความถี่สัญญาณนาฬิกาจะถูกกำหนดไว้ไม่เกินหนึ่งส่วนต่อล้าน (PPM) แม้เมื่อค่าความถี่สัญญาณนาฬิกา oscillator ดั้งเดิมเท่ากับ 100 PPM หรือมากกว่า

โปรดทราบว่าเวลาแฝงที่มีขนาดใหญ่ แต่มีเสถียรภาพระหว่าง LAN และเซิร์ฟเวอร์สัญญาณอินเทอร์เน็ตของคุณนั้นไม่ได้มีผลกระทบต่อความแม่นยำเท่ากับเวลาแฝงที่เปลี่ยนแปลงสูง

คุณไม่ได้บอกว่าคุณได้รับการประมาณด้านบน ('50 microseconds ถึง ... "ต่ำกว่าหนึ่งวินาที"') ดังนั้นฉันไม่สามารถแสดงความคิดเห็นได้ แต่ในประสบการณ์ของฉัน 50us นั้นไม่น่าเป็นไปได้นอกจากคุณจะมีสิ่งที่แนบมาโดยตรง แหล่งที่มาของนาฬิกาและ 1s นั้นไม่น่าเป็นไปได้นอกจากคุณจะมีสตริงเปียกเชื่อมต่อคุณกับอินเทอร์เน็ตและคุณกำลังใช้เซิร์ฟเวอร์อัปสตรีมในแอนตาร์กติกา

แก้ไข : ข้อความที่คุณอ้างถึงในคำถามของคุณจะให้ตัวชี้ไปยังกระดาษซึ่งในปี 1999 ได้สร้างจริง ๆ แล้วว่า 99% ของเซิร์ฟเวอร์ ntp เชื่อมโยงกับภายในหนึ่งวินาที โชคดีที่มีงานใหม่ ๆ มากกว่านี้; ในบทความนี้ผู้เขียนบางคนจาก Federal University of Parana, Brazil ทำการทดสอบซ้ำในปี 2005 และพบว่า (ถ้าฉันเข้าใจรูปที่ 1 อย่างถูกต้อง) ซึ่งทางเหนือของ 99% - มากกว่า 99.5% - ของเซิร์ฟเวอร์ตอนนี้มีออฟเซ็ตน้อยกว่า 100ms และ 90% นั้นมีออฟเซ็ตน้อยกว่า 10ms สิ่งนี้เข้ากันได้ดีกับประสบการณ์ของฉัน (ดูด้านบน)

แก้ไข 2 : หนึ่งรอยย่นครั้งสุดท้าย: การศึกษาทั้งหมดเหล่านี้ไม่ได้ตรวจสอบว่านาฬิกาท้องถิ่นนั้นถูกต้องแค่ไหน แต่กลับแตกต่างจากนาฬิกาอ้างอิงต้นน้ำมากแค่ไหน สิ่งเหล่านี้ไม่ใช่สิ่งเดียวกัน แต่คนแรกไม่อาจหยั่งรู้ได้ หากต้องการทราบว่านาฬิกาของคุณผิดคุณต้องรู้ว่าเวลาเท่าไรและถ้าคุณรู้ว่าทำไมคุณต้องตั้งนาฬิกาให้ผิดตั้งแต่แรก เพิ่งทราบว่าการศึกษาเหล่านี้วัดอะไรไม่แตกต่างระหว่างนาฬิกาท้องถิ่นกับเวลาสัมบูรณ์ แต่ระหว่างนาฬิกาท้องถิ่นกับนาฬิกาอ้างอิง

คุณพยายามแก้ไขปัญหาอะไร

วิธีการแก้ปัญหาที่ผมเคยพบมาสำหรับสภาพแวดล้อมที่ต้องการความแม่นยำมากกว่า NTP เป็นพรีซิชั่ Time Protocol (PTP) ฉันมีมันในการคำนวณทางวิทยาศาสตร์และการประยุกต์ใช้คอมพิวเตอร์ทางการเงิน แม้ว่าจะมีการแลกเปลี่ยนกัน

ดูเพิ่มเติมที่: การซิงโครไนซ์ ptp time บน centos6 / rhel

สิ่งอื่น ๆ ที่ควรค่าแก่การกล่าวถึง:

• คุณจะโชคดีที่ได้รับสัญญาณนาฬิกาในเครื่องเสมือนจริงน้อยกว่า 100ms ดังนั้นข้อมูลด้านล่างนี้สำหรับโฮสต์จริง
• ความกระวนกระวายใจในระดับต่ำกว่า 100ms นั้นแทบจะไม่สามารถประเมินได้สำหรับเกือบทุกงานและสามารถทำได้อย่างง่ายดายผ่านอินเทอร์เน็ต
• อาจต้องใช้ jitter ย่อย 30ms สำหรับสภาพแวดล้อมการให้บริการทั่วไป (ฉันต้องการสำหรับ log correlation ในงานก่อนหน้า) และสามารถทำได้อย่างง่ายดายโดยใช้เซิร์ฟเวอร์ NTP ในทวีปเดียวกันที่การเชื่อมต่อไม่ได้ผ่านลิงก์ "consumer" (เช่นไม่ใช่ดาวเทียม) , ADSL, DOCSIS, GPON, UMTS / LTE / HSPA / ฯลฯ )
• เพื่อความแม่นยำต่ำกว่านี้คุณควรติดตั้งเซิร์ฟเวอร์ NTP ของฮาร์ดแวร์จากผู้จำหน่ายที่มีคุณภาพ (เช่น Symmetricom)
• Sub 10ms (มักจะย่อย 1ms) ข้อตกลงท้องถิ่นสามารถทำได้ง่าย ๆ เพียงแค่มี trio (คุณสามารถทำได้น้อยกว่า แต่มีเหตุผลที่จะใช้สามหรือห้า) ภายในดาต้าเซ็นเตอร์เดียวกันซึ่งเพียงพอสำหรับการสมัครที่ไม่ใช่วิทยาศาสตร์

ได้รับความสนใจในส่วนของฉัน: ฉันเป็นตัวแทนของ Meinberg :-)

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

บนเครื่องที่มี GPS ท้องถิ่น (ที่มีการเชื่อมต่อระหว่าง PPS) คุณอาจเห็นออฟเซ็ต 0-2 microseconds ระหว่างอินสแตนซ์ ntpd ที่ทำงานในระบบปฏิบัติการและอินพุต PPS refclock ของไดรเวอร์

ส่วนที่เหลืออีก 50 คนของเรา "จบสิ้นผ่าน LAN" เป็นผลมาจากการบัฟเฟอร์หลายขั้นตอน, เวลาแฝง IRQ ที่ผันแปร, การรับส่งข้อมูลอื่น ๆ ที่รบกวน LAN และคอมพิวเตอร์ที่เกี่ยวข้องและอะไรก็ตาม 50 พวกเราหมายถึง LAN ที่มีปริมาณการใช้งานน้อยมาก แม้แต่สวิตช์ก็สามารถเพิ่มกระวนกระวายใจได้หลายไมโครวินาทีและสวิตช์ระดับสูงที่มีคุณสมบัติที่ซับซ้อนจะช่วยเพิ่มความล่าช้าและความกระวนกระวายใจ กล่าวอีกนัยหนึ่งอาจเป็นเรื่องยากที่จะบรรลุ 50 ไมโครวินาทีในสภาพแวดล้อมจริงของคุณบน LAN ที่ใช้งานได้จริง

ในทำนองเดียวกัน cca <2us ของ PPS นั้นเป็นผลมาจากความไม่แน่นอนของความล่าช้าในการตอบสนอง IRQ และความล่าช้าในการตอบสนองของบัสทั่วไปบนฮาร์ดแวร์พีซีที่ทำงานได้ดี

โปรดทราบว่า NTP และการใช้งานของ ntpd และ Chrony จะวัดเวลาการทำธุรกรรม NTP ไปกลับและลบอย่างแน่นอน (เพิ่มจริง ๆ ) ครึ่งหนึ่งของการเดินทางไปกลับนั้นเป็นการวัดเพื่อกรองเวลาแฝงการขนส่งอย่างเป็นระบบ (ทางเดียว) พวกเขายังดำเนินการปฏิเสธนอกรีตฉันทามติที่ครบองค์ประชุมการเลือกตั้งของผู้ปฏิบัติงานและปีศาจ NTP ตัวใดก็ได้กรองการตอบสนองที่ได้รับกับการสืบค้นต้นน้ำ ดังนั้นอย่างที่คนอื่น ๆ พูดมิลลิวินาทีที่คุณเห็นใน Ping และ Traceroute ไม่ได้ชดเชยเวลาท้องถิ่นของคุณโดยตรง สิ่งที่สำคัญคือความแปรปรวนของธุรกรรมไปกลับเช่นปริมาณการใช้งานอื่น ๆ บนเส้นทางไปยังเซิร์ฟเวอร์ NTP ของคุณ Ntpq -p เป็นเพื่อนของคุณ

ตัวรับสัญญาณ GPS ขั้นพื้นฐานสำหรับการใช้งานตามกำหนดเวลาด้วย TCXO อาจมีกระวนกระวายใจที่หลงเหลืออยู่ + 100-200 ns + เดินบนเอาต์พุต PPS ดีพอสำหรับ NTP ตราบใดที่ GPS ยังล็อคอยู่ (ประสิทธิภาพของการพักค้างไม่ค่อยดีนักกับ TCXO) ช่วงเวลา GPS คุณภาพกับ OCXO สามารถทำได้ภายใน 100 ns อาจจะเหมือนกับข้อผิดพลาดตกค้าง 10-30 ns (ชดเชยจาก UTC ทั่วโลก)

โปรดทราบว่าดาวเทียมจริงที่บินอยู่เหนือศีรษะและส่งเสียงบี๊บถึงคุณผ่านบรรยากาศอาจเป็นเกมที่ยากขึ้นสำหรับผู้รับมากกว่าการเปรียบเทียบในห้องปฏิบัติการที่มีเครื่องกำเนิด GPS

PTP เป็นค้อน คุณต้องได้รับการสนับสนุนจาก HW ในปรมาจารย์และในทาสและในสวิตช์ใด ๆ - แต่ถ้าคุณได้รับสิ่งนั้นการชดเชยส่วนที่เหลือจะลดลงเหลือสองหลักของเสี้ยววินาทีที่ต่ำ ฉันได้เห็นสิ่งนี้เป็นการส่วนตัวใน ptp4l ที่ทำงานด้วย i210 NIC ซึ่งรองรับ HW (การประทับเวลาด้วยความละเอียดระดับนาโนวินาที)

ชิป i210 เป็นสิ่งมหัศจรรย์ มันมี 4 หมุดอเนกประสงค์ที่สามารถใช้เพื่อป้อนหรือส่งสัญญาณ PPS การอ้างอิง Intel addon NIC board พร้อม i210 (และเวอร์ชั่น OEM จากผู้จำหน่ายรายใหญ่หลายราย) มาพร้อมกับส่วนหัวพินที่ให้คุณเข้าถึงอย่างน้อย 2 พิน GPIO (SDP ที่เรียกว่าโดย Intel) นอกเหนือจากการนำ PTP grandmaster port มาใช้แล้วยังสามารถใช้ประโยชน์จากอินพุต PPS เพื่อการประทับเวลาที่แม่นยำในการดักจับแพ็กเก็ต คุณต้องมีแหล่งที่มาอย่างแม่นยำของ PPS และซอฟต์แวร์ที่กำหนดเองเพื่อเรียกใช้วนรอบ servo ปรับจูน PHC ของ i210 ให้เป็น ext.PPS บนอุปกรณ์ทดสอบของฉันสิ่งนี้ส่งผลให้มีค่าตัวเลขเดียว ns (ต่อ 1 s ซ้ำ) ของการชดเชยที่เหลือ นี่คือความแม่นยำที่คุณจะได้รับจากเวลาบันทึกภาพ หากคุณรัน tcpdump หรือ wireshark ล่าสุดบนเคอร์เนล Linux ที่ทันสมัย ​​(ซอฟต์แวร์ทั้งหมดต้องการการสนับสนุนสำหรับการแก้ปัญหาระดับนาโนวินาที) ดีกว่า: ฉันไปตลอดทางและสร้าง PLL synth อย่างง่ายเพื่อผลิต 25 MHz สำหรับนาฬิกา NIC ล็อคเพื่อการอ้างอิง 10MHz ต้นน้ำที่แม่นยำ หลังจากนั้นการชดเชยส่วนที่เหลือในลูปเซอร์โวของอุปกรณ์จับภาพแพ็คเก็ตของฉันลดลงถึง 0 ที่สะอาด (หลักฐานที่แสดงว่าการอ้างอิง 10 MHz ของฉันนั้นเฟสซิงโครนัสกับ PPS จากกล่อง GPS เดียวกันนั้น)

โปรดทราบว่า PTP grandmasters อาจถูกระบุเพื่อให้การประทับเวลาด้วยความละเอียดที่แท้จริงต่อ 8 ns (ในชนิดข้อมูลที่มีความละเอียด 1 ns) สิ่งนี้สมเหตุสมผล - กิกะบิตอีเธอร์เน็ตมีแนวโน้มที่จะใช้นาฬิกา 125 MHz ใช้เป็นนาฬิกาไบต์ใน internals ของ MAC นาฬิกานี้อาจใช้ใน GMII และยังเป็นนาฬิกาสัญลักษณ์ในโลหะ 1000Base-TX (สี่คู่ ในแบบคู่ขนาน 2 บิตต่อสัญลักษณ์ต่อคู่) ดังนั้นถ้าคุณใช้ 1000Base-FX (ใยแก้วนำแสง) กับ SERDES และการใช้งานหัวรุนแรงสุดยอดของ HW timestamping unit ใน PHY ที่ทำงานได้กับบิตของ SERDES แต่ละตัว 8 ns นั้นเป็นสิ่งที่คุณสามารถคาดหวังได้ใน gigabit Ethernet แผ่นข้อมูลชิปบางอัน (พร้อมการสนับสนุน PTP) แม้อ้างว่าเส้นทางข้อมูล MII นั้นไม่ได้ฟรีจากการบัฟเฟอร์และกระวนกระวายใจบางอย่างอาจมาจากที่นั่น

แพ็กเก็ต PTP มีการประทับเวลาที่จัดเก็บในรูปแบบข้อมูลที่ช่วยให้การแก้ปัญหา sub-nanosecond ลึก แต่ "เศษส่วนย่อย nanosecond" ในปัจจุบันมักจะไม่ได้ใช้งาน AFAIR เฉพาะโครงการ White Rabbit (ที่เกี่ยวข้องกับ CERN ศูนย์วิจัยสวิส) ได้ใช้ความแม่นยำย่อยแล้ว

PTP ยังมีอยู่ในซอฟต์แวร์บริสุทธิ์โดยไม่ต้องเร่ง HW ในกรณีนี้สำหรับ GM ที่ใช้ SW และไคลเอนต์ SW-based คาดว่าจะได้รับความกระวนกระวายใจที่คล้ายกันเช่นเดียวกับ NTP - คือประมาณ 50 พวกเราใน LAN เฉพาะ แต่ PTP ที่ไม่รู้จัก ฉันจำได้ว่าได้รับความแม่นยำ sub-microsecond จาก HW Grandmaster บนการเชื่อมต่อโดยตรง (ไม่มีสวิตช์สลับระหว่าง) และไคลเอนต์ SW-only (บนพีซี NIC ที่ไม่รู้จัก PTP) เมื่อเทียบกับ NTP เซอร์โวของ PTP จะมาบรรจบกันเร็วกว่ามาก

ในขณะที่ทำการบ้านบางอย่างเมื่อเร็ว ๆ นี้มันเกิดขึ้นกับฉันว่าการขนส่ง PPS หรือสัญญาณเวลา "ไม่ต่อเนื่อง" ที่คล้ายกันผ่านเส้นทางใยแก้วนำแสงในบริเวณกว้างอาจไวต่อการแพร่กระจายของเวลาที่ขึ้นกับอุณหภูมิ และถึงแม้ว่าฉันจะไม่มีวิธีทดสอบการทดลองนี้แหล่งข้อมูลบางแห่งใน interwebs อ้างตัวเลขระหว่าง 40 และ 76 picoseconds ต่อกม. และเคลวิน โปรดทราบว่าในขณะที่ "ความร้อนเดิน" แบบนี้เป็นไปไม่ได้ที่จะลด "ในแถบ" ในการส่ง PPS อย่างง่าย ๆ PTP จะโพสต์ชดเชยสิ่งนี้โดยเนื้อแท้ตามการวัดการหน่วงเวลามาตรฐานเส้นทาง (ซึ่งขึ้นอยู่กับการส่งเพล็กซ์เต็มรูปแบบ)

มากสำหรับภาพรวมของสิ่งที่ "precisions" มีลักษณะที่เทคโนโลยีเวลาที่แตกต่างกัน / อินเตอร์เฟซ ระดับความแม่นยำระดับไหนดีพอสำหรับคุณซึ่งขึ้นอยู่กับใบสมัครของคุณตามความต้องการที่แท้จริงของคุณ