บทความเทคนิคต้นฉบับ FCTEL · ทีมเทคนิค FCTEL
เผยแพร่ครั้งแรก: 2026-10-05 · แก้ไขล่าสุด: 2026-10-05
กราฟการใช้งานพอร์ตดูสงบ แต่ภาพจากระบบแมชชีนวิชันกลับสูญเสียเฟรมเป็นครั้งคราว และการตอบสนองของ PLC ช้าลงอย่างกะทันหัน สาเหตุหนึ่งที่เป็นไปได้คือไมโครเบิร์สต์ ซึ่งเกิดเมื่ออุปกรณ์หลายตัวส่งข้อมูลไปยังขาออกเดียวกันในช่วงเวลาสั้น ๆ สวิตช์ไม่สามารถส่งข้อมูลทั้งหมดได้ทันที จึงต้องเก็บเฟรมไว้ชั่วคราว หากพื้นที่บัฟเฟอร์ไม่เพียงพออาจทำให้เกิดการทิ้งเฟรม บทความนี้อธิบายตั้งแต่การรับ การเข้าคิว การจัดตาราง ไปจนถึงการส่ง โดยแยกกลไกทั่วไป การคำนวณเพื่อประกอบคำอธิบาย และความสามารถที่ระบุไว้อย่างชัดเจนในเอกสารของผลิตภัณฑ์ FCTEL ออกจากกัน
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนในแนวนอนเพื่ออ่านข้อความกำกับแผนภาพในขนาดเต็ม
1 เหตุใดขาเข้าระดับกิกะบิตหลายช่องจึงแย่งใช้ขาออกหนึ่งช่องได้
หลังรับเฟรมอีเทอร์เน็ต สวิตช์จะกำหนดขาออกโดยใช้ตารางส่งต่อและนโยบายที่เกี่ยวข้อง ขาเข้าหลายช่องสามารถรับข้อมูลพร้อมกันได้ แต่ขาออกทางกายภาพทั่วไปหนึ่งช่องยังคงต้องส่งเฟรมเรียงต่อกันด้วยอัตราสายสัญญาณของช่องนั้นในทิศทางการส่งหนึ่ง ๆ เมื่อกล้องสองตัวส่งภาพไปยังเซิร์ฟเวอร์วิเคราะห์เดียวกัน การเชื่อมต่อทั้งสองอาจเจรจาใช้งานที่ความเร็วกิกะบิตได้ แต่ยังต้องแย่งใช้พอร์ตสวิตช์กิกะบิตเพียงพอร์ตเดียวของเซิร์ฟเวอร์ การเพิ่มขาเข้าไม่ได้เพิ่มความจุของขาออกนั้น
บัฟเฟอร์คือพื้นที่จัดเก็บข้อมูลเฟรม ส่วนคิวคือข้อมูลที่รออยู่และความสัมพันธ์ด้านการจัดการที่ใช้ให้บริการข้อมูลนั้น ทั้งสองแนวคิดเกี่ยวข้องกันแต่ใช้แทนกันไม่ได้ ชิปสวิตช์อาจใช้พื้นที่จัดเก็บร่วม การจัดสรรพื้นที่ให้พอร์ต และคิวทราฟฟิกหลายคิว กฎการจัดสรรเป็นตัวกำหนดว่าขาออกหนึ่งช่องจะใช้พื้นที่ได้เท่าใดในขณะนั้น ค่าความจุบัฟเฟอร์รวมในข้อกำหนดผลิตภัณฑ์ไม่ได้หมายความว่าแต่ละพอร์ตมีพื้นที่จำนวนดังกล่าวเป็นของตนเองโดยเฉพาะ และไม่ได้ระบุโดยตรงว่าแอปพลิเคชันใดแอปพลิเคชันหนึ่งอาจต้องรอนานเท่าใด
สถานการณ์ที่พิจารณาในที่นี้คือโหลดขาออกเกินความสามารถในการให้บริการชั่วคราว ซึ่งแตกต่างจากลูปที่สร้างสำเนาเฟรมอย่างต่อเนื่อง และแตกต่างจากสัญญาณรบกวนที่ทำให้เฟรมบนลิงก์สายทองแดงเสียหาย ควรระบุตำแหน่งที่เกิดความแออัดและทิศทางทราฟฟิกก่อนสรุปว่าเหตุการณ์สูญเสียทุกครั้งเกิดจากสายเคเบิลหรือสวิตช์ขัดข้อง
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนในแนวนอนเพื่ออ่านข้อความกำกับแผนภาพในขนาดเต็ม
2 ไมโครเบิร์สต์หลุดรอดจากกราฟอัตราการใช้งานเฉลี่ยได้อย่างไร
อัตราเฉลี่ยคือจำนวนบิตที่ส่งหารด้วยช่วงเวลาการวัด ในช่วงเวลาหนึ่งวินาที เบิร์สต์ที่กินเวลาหนึ่งมิลลิวินาทีจะถูกเฉลี่ยรวมกับเวลาว่างที่เหลือจนผลของมันลดลง ช่วงเวลาที่นานขึ้นยิ่งซ่อนค่าสูงสุดได้ง่ายขึ้น การทริกเกอร์กล้องแบบซิงโครไนซ์ การอัปโหลดเป็นบล็อก และการรายงานจากอุปกรณ์พร้อมกันอาจทำให้ทราฟฟิกกระจุกตัวในเวลาใกล้กัน ไม่มีเกณฑ์ระยะเวลาไมโครเบิร์สต์ค่าเดียวที่ใช้ได้กับอุปกรณ์ทุกชนิด เงื่อนไขที่เกี่ยวข้องคืออัตราข้อมูลที่มาถึง ณ ขณะหนึ่งเกินอัตราการให้บริการของขาออก
พิจารณาการคำนวณในอุดมคติ ขาเข้าสองช่องส่งข้อมูลรวม 2 Gbit/s เป็นเวลา 1 ms ไปยังคิวที่เริ่มต้นว่างอยู่ ขณะที่ขาออกส่งด้วยอัตรา 1 Gbit/s ผลต่างคือ 1 Gbit/s เมื่อนำผลต่างนี้คูณด้วยเวลาแล้วหารด้วยแปด จะได้ข้อมูลค้างรอ 125,000 ไบต์ หรือประมาณ 125 kB เมื่อขาเข้าหยุดส่ง การระบายข้อมูลดังกล่าวด้วยอัตรา 1 Gbit/s จะใช้เวลาอีกประมาณ 1 ms กราฟปริมาณข้อมูลในคิวรูปสามเหลี่ยมนี้สมมติว่ามีบัฟเฟอร์เพียงพอ และไม่รวมพรีแอมเบิล ช่องว่างระหว่างเฟรม และทราฟฟิกอื่น
หากนี่เป็นเบิร์สต์เพียงครั้งเดียวในวินาทีนั้น ข้อมูลที่มาถึงจะรวมเป็น 250 kB และอัตราขาเข้าเฉลี่ยจะอยู่ที่ประมาณ 2 Mbit/s เท่านั้น ถึงกระนั้น เบิร์สต์นี้ยังต้องใช้บัฟเฟอร์สำหรับข้อมูล 125 kB ในช่วงหนึ่งมิลลิวินาทีที่ข้อมูลมาถึง หากพื้นที่ที่จัดสรรให้ใช้งานได้มีน้อยกว่านี้ การทิ้งเฟรมจะเริ่มเร็วขึ้น และเส้นกราฟปริมาณข้อมูลในคิวจะถูกตัดที่ขีดจำกัดความจุ ดังนั้น อัตราการใช้งานเฉลี่ยต่ำจึงไม่ได้พิสูจน์ว่าไม่มีความแออัดชั่วขณะ และไม่ได้ตัดความเป็นไปได้ของการทิ้งเฟรมขาออก
3 บัฟเฟอร์รองรับเบิร์สต์และเพิ่มเวลารอ
เฟรมในคิวขาออกต้องรอให้งานที่อยู่ก่อนหน้าดำเนินการเสร็จ การนำจำนวนไบต์ในคิวคูณด้วยแปดแล้วหารด้วยอัตราขาออกช่วยประมาณเวลาที่ต้องใช้ให้บริการได้ พฤติกรรมจริงยังขึ้นอยู่กับขอบเขตเฟรม โอเวอร์เฮดของลิงก์ และการจัดตาราง บัฟเฟอร์ที่ใหญ่ขึ้นสามารถรองรับเบิร์สต์ระยะสั้นที่ยาวนานขึ้นได้ แต่อาจทำให้เฟรมรอนานขึ้นด้วย เมื่ออัตราขาเข้าเกินขาออกอย่างต่อเนื่อง บัฟเฟอร์ทุกขนาดที่มีจำกัดย่อมเต็มในที่สุด พื้นที่จัดเก็บเพิ่มเติมไม่ได้ขจัดปัญหาความจุไม่เพียงพอที่เกิดขึ้นอย่างต่อเนื่อง
พฤติกรรมเมื่อพื้นที่จัดเก็บหมดขึ้นอยู่กับการออกแบบและนโยบาย วิธี tail drop ที่ใช้กันทั่วไปจะปฏิเสธเฟรมที่เพิ่งมาถึงเมื่อคิวเต็ม แต่อาจมีการใช้เกณฑ์อื่น กฎลำดับความสำคัญ หรือกลไกทิ้งเฟรมก่อนคิวเต็ม อย่าสมมติว่ากลยุทธ์ของชิปหนึ่งตัวเป็นค่าเริ่มต้นของสวิตช์อุตสาหกรรมทุกตัว TCP อาจกู้คืนข้อมูลผ่านการตอบรับและการส่งซ้ำ ขณะที่แอปพลิเคชันต้องรอเพิ่มขึ้น ส่วน UDP และแอปพลิเคชันเรียลไทม์บางประเภทต้องมีกลไกจัดการการสูญเสียหรือการหมดเวลาของตนเอง
การควบคุมการไหลระดับชั้นลิงก์ก็มีข้อจำกัดเช่นกัน ตรวจสอบว่าเปิดใช้งานอยู่หรือไม่ อุปกรณ์ปลายทางตอบสนองหรือไม่ ส่งผลต่อทราฟฟิกใด และทำให้การบล็อกลามไปยังแอปพลิเคชันอื่นหรือไม่ การเปิดใช้การควบคุมการไหลไม่ใช่สิ่งทดแทนการวางแผนความจุของเครือข่ายควบคุม หากยังไม่ได้ตรวจสอบยืนยัน จะถือว่าเฟรม pause รับประกันเส้นตายของ PLC ไม่ได้
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนในแนวนอนเพื่ออ่านข้อความกำกับแผนภาพในขนาดเต็ม
4 เหตุใด QoS จึงไม่ใช่การรับประกันความหน่วงเป็นศูนย์
โดยทั่วไป QoS จะจำแนกทราฟฟิกตามเงื่อนไข เช่น พอร์ต ลำดับความสำคัญ IEEE 802.1p หรือ IP DSCP จากนั้นแมปไปยังคิวภายใน และให้ตัวจัดตารางเลือกเฟรมถัดไป เครื่องหมายเป็นเพียงข้อมูลสำหรับการจำแนกประเภท หากไม่มีการแมปและการจัดตารางที่สอดคล้องกันตลอดเส้นทาง เฟรมที่มีเครื่องหมายก็ไม่จำเป็นต้องได้รับบริการก่อน การจัดตารางแบบลำดับความสำคัญเคร่งครัดและแบบถ่วงน้ำหนักมีคุณสมบัติด้านความเป็นธรรมต่างกัน ตรวจสอบอัลกอริทึม จำนวนคิว และการควบคุมอัตราสำหรับรุ่นและเฟิร์มแวร์นั้นโดยเฉพาะ
ในการส่งทั่วไปแบบไม่แทรกขัดจังหวะ เฟรมควบคุมขนาดสั้นอาจเข้าสู่คิวลำดับความสำคัญสูงหลังจากขาออกเริ่มส่งเฟรมทั่วไปแล้ว โดยปกติตัวจัดตารางจะรอให้เฟรมนั้นส่งเสร็จก่อนเลือกเฟรมควบคุม เฟรมขนาด 1,518 ไบต์ใช้เวลาประมาณ 121.44 ไมโครวินาทีในการส่งบิตเรียงต่อกันที่อัตรา 100 Mbit/s โดยไม่รวมพรีแอมเบิลและช่องว่างระหว่างเฟรม ที่อัตรา 1 Gbit/s การคำนวณเฉพาะตัวเฟรมแบบเดียวกันให้ค่าประมาณ 12.144 ไมโครวินาที ตัวเลขเหล่านี้เป็นการคำนวณเพื่อประกอบคำอธิบาย ไม่ใช่ค่าความหน่วงของอุปกรณ์ที่รับประกัน
การแทรกส่งเฟรมอีเทอร์เน็ตโดยเฉพาะต้องอาศัยความสามารถที่เกี่ยวข้อง การกำหนดค่า และความร่วมมือจากอุปกรณ์ปลายทาง ไม่สามารถอนุมานได้จากข้อความที่ระบุว่ารองรับ QoS แม้แต่ทราฟฟิกควบคุมที่มีลำดับความสำคัญสูงก็อาจแย่งใช้ทรัพยากรกับทราฟฟิกควบคุมอื่น ขณะที่ขั้นตอนอื่นยังเพิ่มเวลารอ การออกแบบให้มีพฤติกรรมที่กำหนดได้แน่นอนเริ่มจากความหน่วงสูงสุดที่แอปพลิเคชันยอมรับได้และโหลดสูงสุด ตรวจสอบยืนยันแต่ละช่วง และหลีกเลี่ยงการกำหนดให้ทุกเฟรมมีลำดับความสำคัญสูงสุด
5 แยกความแออัดออกจากข้อผิดพลาดของลิงก์ทางกายภาพ
เริ่มจากบันทึกความเร็วพอร์ตและสถานะดูเพล็กซ์ ตัวนับไบต์ขาเข้าและขาออก ตัวนับการทิ้ง และตัวนับข้อผิดพลาด CRC หรือ FCS ระบุทิศทาง หน่วย และช่วงเวลาอัปเดตของตัวนับแต่ละตัว การทิ้งขาออกที่เพิ่มขึ้นมักชี้ไปที่ทรัพยากรขาออกหรือนโยบาย ส่วนข้อผิดพลาด CRC ควรนำไปสู่การตรวจสอบความสมบูรณ์ของลิงก์รับข้อมูล ทั้งสองอย่างอาจเกิดขึ้นพร้อมกันได้ ตัวนับเพียงตัวเดียวไม่สามารถตัดสาเหตุอื่นทั้งหมดออกได้ ควรเชื่อมโยงข้อมูลเหล่านี้กับช่วงเวลาที่เฟรมของแอปพลิเคชันขาดหายหรือเกิดการหมดเวลา
เพิ่มความละเอียดด้านเวลาของการสังเกต และตรวจสอบปริมาณข้อมูลในคิว ค่าสูงสุด หรือประเภทการทิ้ง หากอุปกรณ์รองรับ หากอุปกรณ์ไม่มีตัวชี้วัดเหล่านี้ ให้ใช้ทราฟฟิกที่ควบคุมได้ในสภาพแวดล้อมทดสอบ เพื่อเปรียบเทียบผู้ส่งหนึ่งตัว ผู้ส่งสองตัวที่ซิงโครไนซ์กัน และการส่งแบบเหลื่อมเวลา วัดค่าตัวนับที่เพิ่มขึ้น ณ ขาออกเดียวกันและการตอบสนองของแอปพลิเคชัน พอร์ตมิเรอร์มีขีดจำกัดความจุของตนเอง การสูญเสียบนเส้นทางจับข้อมูลที่ทำมิเรอร์ไม่ได้หมายความโดยอัตโนมัติว่ามีการสูญเสียที่ขาออกของแอปพลิเคชัน
6 วิธีตรวจรับอุปกรณ์ FCTEL ในทางปฏิบัติ
เอกสารทางการของ FCTEL สำหรับสวิตช์อุตสาหกรรม Layer 3 แบบจัดการได้ชนิดติดราง DIN ซึ่งมีพอร์ตใยแก้วนำแสงความเร็ว 10 กิกะบิตจำนวนสี่พอร์ต และพอร์ตไฟฟ้ากิกะบิตจำนวนแปดพอร์ต ระบุการทำงานแบบรับเก็บแล้วส่งต่อ การจัดการคิวลำดับความสำคัญ IEEE 802.1p และ DSCP รวมถึงสถิติพอร์ต คุณสมบัติที่มีเอกสารระบุเหล่านี้ให้บริบทของผลิตภัณฑ์สำหรับการออกแบบและการทดสอบตรวจรับ แต่ไม่ได้ยืนยันการรองรับคุณสมบัติตรวจติดตามไมโครเบิร์สต์แบบใดโดยเฉพาะ การแทรกส่งเฟรม หรือการจัดสรรบัฟเฟอร์ต่อพอร์ตตามค่าที่กำหนด ตรวจสอบการกำหนดค่าและสถิติที่มีให้ใช้กับคู่มือและเฟิร์มแวร์ที่ตรงกัน
ระบุตำแหน่งคอขวดที่แท้จริงก่อนประเมินการเพิ่มความจุขาออก การลดอัตราข้อมูลขาเข้าจากต้นทาง ณ ขณะหนึ่ง การส่งแบบเหลื่อมเวลา และการจัดตารางคิวที่เหมาะสม การรวมลิงก์ไม่ได้รับประกันว่าโฟลว์ของแอปพลิเคชันหนึ่งจะใช้ลิงก์สมาชิกทุกเส้นพร้อมกันได้ ให้ตรวจสอบการแฮชและการกระจายทราฟฟิก หลังเปลี่ยนแปลง ให้ทดสอบด้วยโหลดสูงสุดแบบเดิมซ้ำ และบันทึกการทิ้ง เวลารอ ความครบถ้วนถูกต้องของข้อมูลแอปพลิเคชัน และการกู้คืน การแสดงให้เห็นว่าปรับปรุงได้ภายในขีดจำกัดของแอปพลิเคชันควบคุม คือสิ่งที่ทำให้เข้าใจความขัดข้องเป็นครั้งคราวภายใต้อัตราการใช้งานเฉลี่ยต่ำได้
เอกสารอ้างอิงทางเทคนิค: Cisco: กลไกไมโครเบิร์สต์และการตรวจติดตามเฉพาะแพลตฟอร์ม. แหล่งข้อมูล FCTEL ที่เกี่ยวข้อง: บทความทางเทคนิค และ เอกสารผลิตภัณฑ์สวิตช์อุตสาหกรรม (ภาษาจีน).
