ภาระบัสเฉลี่ยกับช่วงข้อมูลหนาแน่นต่างกันอย่างไร

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

ภาระบัสเป็นสัดส่วนที่ต้องมีช่วงเวลาอ้างอิง

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

จำนวนเฟรมต่อวินาทีไม่ใช่ภาระบัสโดยตรง เพราะเฟรมอาจต่างขนาด ต่างรูปแบบ และใน CAN FD อาจใช้เวลาช่วงข้อมูลต่างกัน เฟรมหนึ่งร้อยรายการที่สั้นอาจกินเวลาน้อยกว่าเฟรมห้าสิบรายการที่ยาว การประเมินต้องนับเวลา หรือใช้แบบจำลองที่รวมส่วนต่าง ๆ อย่างเหมาะสม ไม่ควรเทียบจำนวนรายการบนหน้าจอแล้วกล่าวว่าชุดใดหนักกว่าทันที

1. 1
   รวมเวลาครอง

   ใช้เวลาของเฟรมตามนิยามเดียวกัน ไม่ใช้จำนวนรายการแทนเวลาโดยตรง

2. 2
   หารหน้าต่าง

   เวลาครองบัสรวมหารเวลาสังเกต คูณ 100 เป็นเปอร์เซ็นต์ตามแบบจำลอง

3. 3
   ตรวจสิ่งที่รวม

   เครื่องมืออาจนับช่วงเว้น บิตแทรก หรือเฟรมผิดพลาดต่างกัน ต้องอ่านคู่มือก่อนเทียบ

จำนวนเฟรมอย่างเดียวไม่พอ เพราะขนาดเฟรมและอัตราบิตมีผลต่อเวลาครองบัส

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

สมมติในหนึ่งวินาทีมีเฟรมครองบัสรวม 200 มิลลิวินาที ภาระตามนิยามนี้คือ 200 หาร 1000 คูณ 100 เท่ากับ 20 เปอร์เซ็นต์ กรณี ก กระจายเวลาใช้งานค่อนข้างสม่ำเสมอตลอดวินาที ส่วนกรณี ข รวม 200 มิลลิวินาทีไว้ในหน้าต่าง 250 มิลลิวินาทีแรก แล้วช่วงที่เหลือแทบว่าง ทั้งสองมีค่าเฉลี่ยหนึ่งวินาทีเท่ากัน แต่หน้าต่างแรกของ ข มีภาระ 80 เปอร์เซ็นต์

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

นำไปใช้เลือกหน้าต่างวิเคราะห์

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

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

1. 1
   ภาพรวม 1 วินาที

   200 / 1000 × 100 = 20 เปอร์เซ็นต์ตามนิยามตัวอย่าง

2. 2
   กระจายหรือรวม

   กรณี ก กระจายตลอดวินาที กรณี ข รวมเวลาใช้งานใน 250 มิลลิวินาทีแรก

3. 3
   หน้าต่างแรกของ ข

   200 / 250 × 100 = 80 เปอร์เซ็นต์ แม้ค่าเฉลี่ยหนึ่งวินาทียังเป็น 20

4. 4
   เทียบเวลารอ

   ข้อความที่พร้อมช่วงหนาแน่นอาจรอมากขึ้น ต้องดูสิทธิ์ส่งและข้อกำหนดเวลาประกอบ

เวลาใช้งานรวมเท่ากันอาจกระจายต่างกัน จึงไม่รับประกันเวลารอของข้อความ

ข้อผิดพลาดจากการตั้งเกณฑ์เปอร์เซ็นต์เดียว

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

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

ตรวจสอบผลโดยเชื่อมภาระกับข้อกำหนดเวลา

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

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