ฉันจะวัดและป้องกันการเลื่อนของนาฬิกาได้อย่างไร

15

ในหลาย ๆ แพลตฟอร์มการผลิตเราได้สังเกตอาการที่ดูเหมือนจะบ่งบอกว่าเวลาของนาฬิกาวันนั้นกำลังกระโดดไปข้างหน้าหรือข้างหลังเป็นระยะ ปกติการกระโดดจะใช้เวลาประมาณ 1 วินาทีโดยทั่วไปจะถูกยกเลิก (กระโดดไปข้างหน้าหลังจากนั้นไม่นานหลังจากนั้น) และเกิดขึ้นประมาณ 50 ครั้งต่อวัน ดริฟท์นี้สามารถสังเกตได้มากที่สุดในช่วงเวลาที่มีการใช้งานแอพพลิเคชั่นสูงสุดและในช่วงที่มีการทำงานของดิสก์ I / O สูงเช่นการสำรองข้อมูลรายวัน สิ่งเหล่านี้ส่งผลกระทบต่อแอปพลิเคชันที่อ่อนไหวตามเวลาจริงของเรา

ระบบคือเซิร์ฟเวอร์ Oracle Netra X4250 และเซิร์ฟเวอร์ Netra X4270 ที่ใช้ SLES 11SP2 พร้อมเคอร์เนลเริ่มต้น 3.0.58-0.6.6

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

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

เราได้ปิดใช้งานNTPแต่นั่นไม่ได้มีผลกระทบใด ๆ ต่อการดริฟท์ มีเครื่องมือที่ใช้วัดเวลาของการเลื่อนนาฬิกาวันหรือไม่? เราจะหลีกเลี่ยงสิ่งนี้ได้อย่างไร

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

linux sles clock

— เบร็ท
แหล่งที่มา

5

การปิดใช้งาน NTP ทำให้นาฬิกาไม่เสถียรมากขึ้น ... เหตุผลเดียวที่ฉันเห็น NTP ไม่ให้นาฬิกาอยู่ในแนวเดียวคือนาฬิกาหมดสติและ NTP ปฏิเสธที่จะอัปเดต (ดูntpdate(8)หรือntpd(8))

— vonbrand

1

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

— แพทริค

1

สิ่งที่ @Patrick พูดถูกต้องปัญหาที่คุณอธิบายคือการกระโดดข้ามเวลาไปข้างหน้าและย้อนหลังอย่างไม่ต่อเนื่องหลายครั้งต่อวัน NTP ทำงานได้ดีในการดริฟท์ แต่มันจะไม่ช่วยอะไรคุณได้มากนัก มีบางอย่างกำลังรีเซ็ตวันที่ระบบของคุณไปเป็นแหล่งเวลาภายนอกที่อาจมีความละเอียดเพียง 1 วินาทีเท่านั้น หากเซิร์ฟเวอร์ของคุณเป็น x86 * ฮาร์ดแวร์ RTC อาจเป็นแหล่งที่มา เท่าที่การวัดค่านาฬิกาตรงข้ามคำตอบ ntpdate ของ Bratchley เป็นวิธีการที่เหมาะสมหากมีการใช้ stratum 1 การอ้างอิงนาฬิกาที่ดี: เรียกใช้หนึ่งครั้งต่อนาทีและ gnuplot ผลลัพธ์สำหรับรูปภาพ

— duanev

1

วิ่งข้ามการประเมินผลของ NTP เริ่มต้นขึ้นบนเซิร์ฟเวอร์ใหม่ ( drdobbs.com/embedded-systems/ … ) ใช้เวลา NTP ในการเรียนรู้คริสตัลใหม่ สำหรับผลึกที่ไม่ดีจริงๆ NTP จะต้อง 'ทำตามขั้นตอน' นาฬิกาด้วยจำนวนที่มากหลายครั้งในขณะที่ฝึกฝน (ดูรูปที่ 4 และ 5 ในบทความนั้น) ค่าสุดท้ายใน ntp.drift 118ppm คือ 10 วินาทีต่อวันหรือ 208ms ทุก 30 นาที แม้ว่านี่จะไม่ใช่สิ่งที่ OP เห็น แต่เริ่มแรก NTP สามารถทำให้เกิดการกระโดดได้ทันเวลา

— duanev

8

มีเครื่องมือที่ใช้วัดเวลาของการเลื่อนนาฬิกาวันหรือไม่?

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

ตัวอย่าง:

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

-d เป็นตัวเลือก debug ที่ NTP ทำงานโดยไม่ได้สัมผัสกับนาฬิกาของระบบ

คำแนะนำเกี่ยวกับวิธีที่เราสามารถหลีกเลี่ยงปัญหานี้ได้อย่างไร

ฉันไม่แปลกใจเกินไปที่คุณไม่สามารถทำซ้ำได้ในสภาพแวดล้อมการพัฒนา / ทดสอบเนื่องจากอาจเป็นเพราะนาฬิกาฮาร์ดแวร์ หากคุณมีการสนับสนุนด้านฮาร์ดแวร์กับใครสักคนฉันจะลองรับบริการจากเครื่องของคุณ มีความเป็นไปได้ทางหนึ่งคือทำการซื้อขายหนึ่งในเครื่องจักร dev สำหรับเครื่องผลิตนี้แก้ไขระบบเก่าของ PROD และแนะนำเป็นเครื่องจักร dev เพื่อแทนที่เครื่องที่อยู่ใน PROD ทันที

การสลับแหล่งนาฬิกาฮาร์ดแวร์นั้นเป็นเรื่องที่คุณทำได้ หากคุณทำไม่ได้หรือไม่สามารถแลกเปลี่ยนสิ่งที่ฉันอยากจะแนะนำให้คุณไปเส้นทาง hpet คุณสามารถทดสอบว่าการเปลี่ยนแปลงแหล่งสัญญาณนาฬิกาเกิดความยุ่งเหยิงด้วยบริการของระบบหรือไม่และปรับใช้กับการผลิตในลักษณะเหมือนลูกเห็บหรือไม่

— Bratchley
แหล่งที่มา

โดย "การวัดนาฬิกาดริฟท์" ฉันไม่ได้หมายถึงการดริฟท์จากแหล่งเวลาอ้างอิงเช่น NTP ให้คุณ ฉันหมายถึงเครื่องมือที่สามารถตรวจจับ "การข้าม" ในช่วงเวลาของวันในช่วงเวลาต่อเนื่อง ตัวอย่างเช่นใช้เวลาในการสุ่มตัวอย่างวันละ 50 มิลลิวินาทีและรายงานว่าความแตกต่างจากการสุ่มตัวอย่างครั้งสุดท้ายนั้นไกลเกินกว่า 50ms เครื่องมือดังกล่าวจะแสดงว่าเวลาของนาฬิกาในแต่ละวันลอยจากนาฬิกาฮาร์ดแวร์พื้นฐานไม่ว่าด้วยเหตุผลใดก็ตาม

— brett

1

การมีอยู่ของการแทรกแซงดังกล่าวจะไม่ทำให้ประสิทธิภาพลดลงมากกว่าที่คุณคาดหวังที่จะแก้ไขหรือไม่? ในทุกโอกาสแม้ว่ามันจะเป็นปัญหาฮาร์ดแวร์ดังนั้นคุณจะต้องได้รับบริการฮาร์ดแวร์หรือใช้แหล่งสัญญาณนาฬิกาโดยไม่มีปัญหานี้ tscมีพื้นฐานมาจากซีพียูดังนั้นจึงมีเหตุผลว่ากิจกรรมของ CPU ที่สูงขึ้นจะทำให้เกิดปัญหากับนาฬิกาฮาร์ดแวร์ต่อไป หาก hpet เร็วพอสำหรับคุณคุณอาจต้องลองรับบริการหรือทำสิ่งแลกเปลี่ยน นี่เป็นตัวเลือกเดียวที่ฉันสามารถเห็นคุณ

— Bratchley

3

ทางออกหนึ่งคือการใช้ HPET

ดูเพิ่มเติมตัวจับเวลาเหตุการณ์ที่มีความแม่นยำสูง

เพื่อตั้งเป็นพารามิเตอร์การบูตใช้

clocksource=hpet

บนฮาร์ดแวร์รุ่นเก่าTSCมักจะไม่เสถียรและถูกปิดใช้งานโดยเคอร์เนล

ด้วยการถือกำเนิดของซีพียูแบบมัลติคอร์ / ไฮเปอร์เธรดระบบที่มีหลายซีพียูและระบบปฏิบัติการไฮเบอร์เนต TSC ไม่สามารถเชื่อถือได้เพื่อให้ได้ผลลัพธ์ที่ถูกต้อง ...

Wikipedia: ตัวนับเวลา

ในระบบการผลิตที่แสดงอาการกระวนกระวายใจของนาฬิกาฉันเปลี่ยนแหล่งที่มาของนาฬิกาเป็น hpet สิ่งนี้ไม่มีผลต่ออาการกระวนกระวายใจของนาฬิกา

— brett

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

1

ฉันเขียนเครื่องมือที่มีรายละเอียดเพิ่มเติมเพื่อเชื่อมโยงการวัดนาฬิกากับอาการเวลาแฝงที่แสดงโดยแอปพลิเคชันของเรา เครื่องมือนี้ดูเหมือนจะแยกแยะสิ่งที่ฉันเคยสงสัยว่าเป็นกระวนกระวายใจในนาฬิกาเวลาของ Linux

เรื่องสั้นยาวมากสมมติฐานแรกของฉันไม่ถูกต้อง แต่ฉันได้เรียนรู้มากมายเกี่ยวกับนาฬิกา Linux จากคำตอบและลิงก์ดังนั้นขอบคุณทุกคนที่ตอบกลับ!

— เบร็ท
แหล่งที่มา

3

(... ) สมมติฐานเริ่มต้นของฉันไม่ถูกต้องคุณสามารถบอกเราได้ว่าอะไรคือสาเหตุที่แท้จริงแล้ว

— Piotr Dobrogost

0

นาฬิกาไม่ควรจะซ้ำซากถ้าไม่มีใครเปลี่ยนแปลงได้? การกระโดดถอยหลังไม่ควรทำ จะต้องมีบางสิ่งบางอย่างในการตั้งค่านาฬิกา - งาน cron หรือ daemon อื่น ๆ (เช่นการเรียกไปยังhwclock --adjust) ฉันจะจำได้ว่าตัวเอง NTP ปรับปรุงสถิติดริฟท์และชดเชยให้มันเป็นประจำและหากคุณล้มเหลวในการเรียกใช้ NTP เป็นเวลานานและได้รับการชดเชยมากก็ messes up /etc/adjtimeเวลาสำหรับวันหลังจากที่ถ้าคุณไม่ได้ตั้งค่า คุณอาจมีบางอย่างเช่นการตั้งค่า - สิ่งที่ปรับเวลาดริฟท์เป็นระยะ (และทำให้เกิดการกระโดด)

ntp มีความหมายจริงเพื่อตอบโต้ปัญหานี้

— กลุ่มดาวนายพราน
แหล่งที่มา

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

— brett