แยกความล่าช้ากับความแปรปรวนของเวลาข้อความ

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

ระบุจุดเริ่มและจุดจบของเวลาให้ชัด

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

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

1. 1
   ความล่าช้า

   เวลาระหว่างเหตุเริ่มและเหตุจบที่กำหนด ต้องรู้เวลาทั้งสองฝั่ง

2. 2
   ช่วงห่างเฟรม

   เวลาระหว่างข้อความต่อเนื่อง ณ จุดรับเดียว ไม่ใช่ latency ต้นทางถึงปลายทาง

3. 3
   เวลาแสดงผล

   คอมพิวเตอร์อาจวาดรายการเป็นชุด จึงต้องอ่าน timestamp แทนการดูจังหวะหน้าจอ

ระบุเหตุเริ่มจบและแหล่ง timestamp ก่อนคำนวณตัวชี้วัด

ตัวอย่างสมมติของค่าเฉลี่ยที่ซ่อนความแกว่ง

สมมติเฟรมที่จุดรับมีเวลา 0, 10, 21 และ 30 มิลลิวินาที ช่วงห่างสามช่วงคือ 10, 11 และ 9 มิลลิวินาที ค่าเฉลี่ยเท่ากับ 10 มิลลิวินาที หากคาดคาบ 10 มิลลิวินาที ความคลาดของแต่ละช่วงคือ 0, บวก 1 และลบ 1 มิลลิวินาที ช่วงสูงสุดลบต่ำสุดเท่ากับ 2 มิลลิวินาที เราอาจเรียกค่านี้ว่าช่วงการแกว่งแบบยอดถึงยอดของช่วงห่าง โดยต้องเขียนนิยามกำกับ

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

นำไปใช้จัดเวลาจากหลายแหล่ง

1. ระบุปริมาณที่จะวัดและเหตุเริ่มจบ เช่นช่วงห่างต้นเฟรมที่จุดรับเดียวกัน
2. ตรวจแหล่ง timestamp ความละเอียด และว่าใช้ต้นหรือท้ายเฟรมเป็นจุดอ้างอิง
3. ถ้าใช้สองอุปกรณ์ ให้ตรวจวิธีซิงโครไนซ์และความคลาดนาฬิกาก่อนลบเวลาข้ามเครื่อง
4. คำนวณช่วงห่างแล้วแสดงทั้งค่ากลางและค่าปลายช่วง พร้อมจำนวนตัวอย่าง
5. ตรวจจุดเริ่มบันทึกใหม่ เวลาไหลย้อน และการวนของตัวนับก่อนตีความช่วงห่างที่ผิดปกติ

นาฬิกาที่เริ่มพร้อมกันโดยกดปุ่มใกล้ ๆ กันยังไม่ถือว่าซิงโครไนซ์ละเอียดพอสำหรับเหตุการณ์ระดับไมโครวินาที แม้ตั้งเวลาวันที่ตรงกันก็อาจมีค่าชดเชยและอัตราเดินต่างกัน หากมีการคลาดคงที่ 3 มิลลิวินาที การลบเวลาข้ามเครื่องจะเพิ่มหรือลด latency ที่คำนวณเท่ากับ 3 มิลลิวินาที ความคลาดนี้อาจใหญ่กว่าเหตุที่กำลังศึกษา จึงต้องหาข้อมูลการซิงโครไนซ์หรือจำกัดการวิเคราะห์ไว้ภายในนาฬิกาเดียว

1. 1
   เวลารับ

   เฟรมสมมติมาถึงที่ 0, 10, 21 และ 30 มิลลิวินาที

2. 2
   หาผลต่าง

   ช่วงห่างคือ 10, 11 และ 9 มิลลิวินาที

3. 3
   ค่าเฉลี่ย

   (10 + 11 + 9) / 3 = 10 มิลลิวินาที

4. 4
   ช่วงการแกว่ง

   11 − 9 = 2 มิลลิวินาทีแบบยอดถึงยอด ยังไม่ทราบ latency เพราะไม่มีเวลาสร้างข้อมูล

ตัวอย่างมีค่าเฉลี่ย 10 มิลลิวินาที แต่ช่วงห่างไม่ได้คงที่ทั้งหมด

ข้อผิดพลาดจากความละเอียดกับความแม่นยำ

หน้าจอแสดงทศนิยมหกหลักไม่ได้พิสูจน์ว่าเวลาถูกต้องระดับไมโครวินาที ความละเอียดคือขั้นที่แสดงหรือบันทึกได้ ส่วนความแม่นยำต้องดูแหล่งนาฬิกาและวิธีประทับเวลา เครื่องมือที่ใช้เวลาคอมพิวเตอร์อาจมีความแกว่งจากการจัดคิวข้อมูล แม้จัดรูปแบบตัวเลขได้ละเอียด การกล่าวว่าเครือข่ายแกว่ง 20 ไมโครวินาทีจึงต้องมีเครื่องมือที่รองรับการแยกขนาดนั้นอย่างมีหลักฐาน

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

ตรวจสอบผลโดยแยกความแกว่งจริงจากการบันทึก

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

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