Facebook เปิดตัวบริการเวลาใหม่
(engineering.fb.com)Facebook เปิดตัวบริการเวลา NTP ใหม่ที่ time.facebook.com โดยระบุว่ามีความแม่นยำสูงกว่าบริการเวลาแบบสาธารณะอื่น ๆ และไม่ใช้ที่อยู่ IP เพื่อระบุตัวผู้ใช้ นอกจากนี้ Facebook ยังเผยแพร่บทความเกี่ยวกับบริการนี้บนบล็อกวิศวกรรมของบริษัทด้วย (ภาษาอังกฤษ)
สาเหตุที่บริษัทไอทีขนาดใหญ่อย่าง Facebook ให้ความสำคัญกับบริการเวลา ก็เพราะการปฏิบัติการของระบบแบบกระจาย การประมวลผลทรานแซ็กชันของฐานข้อมูลแบบกระจายหรือการรับประกันการบันทึกล็อกที่ถูกต้อง จำเป็นต้องให้เซิร์ฟเวอร์หลายเครื่องซิงก์นาฬิกาเข้าหากันด้วยความแม่นยำสูง
Facebook ได้ซื้ออุปกรณ์ทดสอบเฉพาะทางระดับ Stratum 1 (อุปกรณ์ที่รับข้อมูลเวลาโดยตรงจากนาฬิกาอะตอมของดาวเทียม) เพื่อทำเบนช์มาร์กเปรียบเทียบระหว่าง ntpd ซึ่งเดิมนิยมใช้เป็นเซิร์ฟเวอร์เวลา กับ chrony ซึ่งเป็น NTP daemon ที่ใหม่กว่าพอสมควร ( https://chrony.tuxfamily.org/ ) โดย ntpd หลังเริ่มทำงานครั้งแรกมีความคลาดเคลื่อนชั่วคราวที่ -10 ms ก่อนจะค่อย ๆ ลู่เข้าสู่ความคลาดเคลื่อน ±1 ms แต่ chrony มีความคลาดเคลื่อนส่วนใหญ่อยู่ภายใน ±0.2 ms อย่างต่อเนื่อง จึงแม่นยำกว่า ntpd อย่างชัดเจน
chrony ยังมีข้อดีอื่นด้วย นั่นคือรองรับ hardware timestamp โปรโตคอลซิงก์เวลาอย่าง NTP จะพยายามคำนวณเวลาปัจจุบันให้แม่นยำที่สุด โดยประทับเวลาเมื่อแพ็กเก็ตเดินทางไปมาระหว่างเซิร์ฟเวอร์และไคลเอนต์ แล้วนำมาคำนวณความต่างของเวลาที่ใช้ไป แต่หากไม่ใช่ระบบปฏิบัติการแบบเรียลไทม์ ก็ไม่สามารถรับประกันได้ว่าความหน่วงของกระบวนการต่าง ๆ จะต่ำกว่าระดับหนึ่งเสมอไป ซึ่งใน NTP ก็เช่นกัน และเป็นหนึ่งในสาเหตุที่ทำให้เกิดความคลาดเคลื่อนมากขึ้นเมื่อต้องซิงก์เวลาผ่านเครือข่าย
อย่างไรก็ตาม NIC บางรุ่น (การ์ดแลน) รองรับความสามารถ hardware timestamp ฟีเจอร์นี้ทำให้ NIC มีฮาร์ดแวร์แยกต่างหากสำหรับรักษานาฬิกาภายในและจัดการ timestamp โดยมีความหน่วงของการประมวลผลเพียงไม่กี่นาโนวินาทีเท่านั้น หากเป็นสภาพแวดล้อมเครือข่ายภายในองค์กร และทั้งเซิร์ฟเวอร์ NTP กับไคลเอนต์ต่างก็รองรับ hardware timestamp ซึ่งเป็นสถานการณ์ที่เหมาะสมที่สุด ก็อาจซิงก์เวลาได้ด้วยความคลาดเคลื่อนต่ำกว่า 1 ไมโครวินาที แม้บริการเวลาจริงจะไม่ใช่สภาพแวดล้อมเครือข่ายภายใน และฝั่งไคลเอนต์อาจไม่ได้มี NIC ที่รองรับ hardware timestamp จึงคาดหวังได้ไม่ถึงระดับนั้นก็ตาม แต่ผลเบนช์มาร์กจากการใช้ chrony ร่วมกับ hardware timestamp ก็พบว่าความคลาดเคลื่อนของการซิงก์เวลาส่วนใหญ่อยู่ภายใน ±0.1 ms
ดังนั้น Facebook จึงให้บริการเวลาแบบสาธารณะโดยใช้ chrony ที่เปิดใช้งาน hardware timestamp ขณะที่เซิร์ฟเวอร์เวลาสาธารณะอื่นอย่าง Google หรือ Apple บางครั้งมีความคลาดเคลื่อนของเวลาที่ให้บริการเกิน ±2 ms แต่บริการของ Facebook ส่วนใหญ่อยู่ภายใน ±1 ms อนึ่ง บริการนี้เปิดให้ใช้งานผ่านเอ็นด์พอยต์ใน 5 ภูมิภาคที่แตกต่างกัน รายละเอียดเพิ่มเติมโปรดดูบทความต้นฉบับ
7 ความคิดเห็น
ว้าว เป็นบทความที่น่าสนใจมาก ความพยายามเพื่อความแม่นยำถูกถ่ายทอดออกมาแบบกระชับ(?) แต่ก็ละเอียดดี หลังจากอ่านบทความนี้แล้ว ผมได้เปลี่ยน NTP server บน Mac เป็น
time3.facebook.comแล้วผมใช้
time1.facebook.comอยู่ครับ ลองส่ง ping ดูแล้วพบว่าเอนด์พอยต์อื่นตั้งแต่หมายเลข 2 ถึง 5 นั้น ping ไม่ได้หรือไม่ก็ค่อนข้างช้ามาก พอตั้งค่าtime1.facebook.comเป็นเซิร์ฟเวอร์เวลาในchronyก็แสดงค่าความคลาดเคลื่อนที่คาดไว้ว่าเกิน ±1 ms ไปเล็กน้อย แต่ถ้าตั้งเป็นtime.facebook.comเฉยๆ กลับรับเวลาไม่ได้ครับอ้างอิงไว้ก่อนว่าเซิร์ฟเวอร์เวลาตัวอื่น ๆ เช่น
time.google.comหรือtime.windows.comต่างก็มีค่าคลาดเคลื่อนเกิน 30 ms โดยไม่มีข้อยกเว้น เช่นเดียวกับ NTP pool อย่างkr.pool.ntp.orgด้วย ส่วนเซิร์ฟเวอร์เวลาที่มีความคลาดเคลื่อนน้อยที่สุดเท่าที่เคยเห็นมาจนถึงตอนนี้คือntp.postech.ac.krซึ่งเป็นเซิร์ฟเวอร์ Stratum 1 โดยchronyประเมินว่าอยู่ที่ประมาณ ±5 msเมื่อไม่นานมานี้ผมเพิ่งรู้ว่า ถ้าตั้ง
time.apple.comเป็นพูลใน chrony ก็จะได้เซิร์ฟเวอร์ NTP ความแม่นยำสูงที่อยู่ในเกาหลีและญี่ปุ่น แถมยังแสดงว่าเป็น Stratum 1 ด้วย ดูเหมือนว่า Apple จะติดตั้งตัวรับสัญญาณ GPS ไว้กับเซิร์ฟเวอร์ CDN ของตัวเองแล้วนำมาใช้เป็นไทม์เซิร์ฟเวอร์ว้าว น่าสนุกดีนะ คำว่า at Facebook scale ตอนนี้เริ่มคุ้นหูกันแล้วนะ
พูดนอกเรื่องนิดหนึ่งนะครับ เห็นว่าใน Twitter ของ GeekNews ไม่มีโพสต์นี้ขึ้นอยู่ อยากทราบว่าข่าวที่บอต Twitter โพสต์มีเงื่อนไขแยกต่างหากหรือเปล่าครับ?
อ๋อ พอตรวจดูแล้ว ตรงส่วนที่เช็กจำนวนตัวอักษรแล้วตัดก่อนโพสต์ เกิดแปลง URL ที่อยู่ต้นข้อความเป็นลิงก์อัตโนมัติ ทำให้จำนวนตัวอักษรเกิน แล้ว Twitter API ก็เลยส่ง error กลับมาครับ ฮือ
บน Twitter นั้น URL จะถูกแปลงเป็นขนาดประมาณ 22 ไบต์แบบตายตัวเสมอ
ตรงนี้คงต้องแก้ไขกันหน่อยสินะ ฮือ