อัตราการสูญเสียแพ็คเก็ตด้วย iperf และ tcpdump


10

iperfผมทดสอบเส้นสำหรับคุณภาพการเชื่อมโยงกับ ความเร็วที่วัดได้ (UDP พอร์ต 9005) คือ 96Mbps ซึ่งใช้ได้เนื่องจากเซิร์ฟเวอร์ทั้งสองเชื่อมต่อกับ 100Mbps กับอินเทอร์เน็ต ในทางกลับกันอัตราการสูญเสียดาตาแกรมก็แสดงให้เห็นว่าเป็น 3.3-3.7% ซึ่งฉันพบว่าน้อยเกินไป tcpdumpใช้โปรโตคอลการถ่ายโอนความเร็วสูงฉันบันทึกแพ็คเก็ตทั้งสองด้านด้วย กว่าที่ฉันคำนวณการสูญเสียต - เฉลี่ย 0.25% มีคำอธิบายทุกคนที่แตกต่างกันมากอาจมาจากไหน การสูญเสียตที่ยอมรับได้ในความคิดของคุณคืออะไร?


คุณใช้โปรโตคอลใดเมื่อดมกับ tcpdump เป็น tcp หรือ udp หรือไม่
PiL

ฉันใช้ udp สำหรับการทดสอบทั้งสอง
stefita

อืม ... คุณลองใช้แพ็คเก็ตดมกลิ่นอื่นได้หรือไม่
PiL

2
Wireshark จะใช้แบ็กเอนด์เดียวกันกับ tcpdump เพื่อจับแพ็คเก็ตดังนั้นมันจะไม่ให้ผลลัพธ์ที่แตกต่าง (libpcap หรือ winpcap ขึ้นอยู่กับแพลตฟอร์ม)
Jed Daniels

1
คุณสามารถวัดการสูญเสียแพ็กเก็ตด้วยtcpdumpในระหว่างiperfเซสชันได้หรือไม่? เป็นการประมาณที่เหมาะสมกว่าของคุณ ตรวจสอบสถานะเซิร์ฟเวอร์ระหว่างการทดสอบครั้งที่สอง - อาจเป็นเพราะแพ็คเก็ตลดลงหรือไม่
lexsys

คำตอบ:


3

ฉันได้รับข้อมูลที่สำคัญกับ iPerf ในโหมด UDP เนื่องจาก CPU ไม่สามารถติดตามได้ ด้วยเหตุผลบางอย่าง iPerf กับ UDP ดูเหมือนว่าจะมีมาก CPU เข้มข้นมากขึ้นกว่า iPerf กับ TCP คุณเคยมีอัตราการสูญเสียเท่ากันหรือไม่เมื่อคุณตั้งค่า iPerf ให้เท่ากับครึ่งหนึ่ง

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

[แก้ไข 1] ความคิดอื่น ๆ ที่ฉันมีในหัวข้อ:

  1. ลองเพิ่มอัตราของ iPerf หากมีปัญหาในระบบอยู่ที่ไหนสักแห่งเป็นไปได้ว่าคุณอาจประสบกับการสูญเสียเท่าเดิมไม่ว่าอัตรานั้นจะเป็นเท่าไหร่ หากคุณอยู่ในขอบเขตของฮาร์ดแวร์ของคุณหรือผู้ให้บริการของคุณทำอะไรบางอย่างของREDคุณจะไม่มีการสูญเสียในอัตราที่แน่นอนและจากนั้นการสูญเสียที่เพิ่มขึ้นที่สูงกว่าที่คุณไป
  2. ทำการวัด tcpdump ของเซสชัน iPerf เพียงเพื่อตรวจสอบว่าการทดสอบของคุณถูกต้อง
  3. ลอง iPerf ด้วย TCP สิ่งนี้จะไม่รายงานการสูญเสีย แต่ถ้าคุณได้รับการสูญเสียการเชื่อมต่อจะไม่สามารถเพิ่มขนาดได้สูงมาก เนื่องจากความหน่วงแฝงจะส่งผลกระทบต่อสิ่งนี้ด้วยดังนั้นให้ทดสอบจุดสิ้นสุดด้วยเวลาแฝงที่น้อยที่สุดเท่าที่จะทำได้
  4. ขึ้นอยู่กับอุปกรณ์ที่คุณมีในการเชื่อมต่อของคุณตรวจสอบให้แน่ใจว่าคุณอยู่ใกล้มันมากที่สุด เช่นหากคุณมีสวิตช์หลายตัวระหว่างระบบทดสอบของคุณกับเราเตอร์ขอบย้ายไปยังสวิตช์ที่เชื่อมต่อโดยตรง
  5. หากคุณมีสวิตช์ที่มีการจัดการตรวจสอบสถิติบนสวิตช์เพื่อให้แน่ใจว่าไม่มีการสูญเสียเกิดขึ้นที่นั่น ฉันพบสวิตช์ที่ถูกกว่าบางตัวที่เริ่มลดลงเมื่อคุณเข้าใกล้กับ 100Mbps ของการรับส่งข้อมูลบน UDP ที่สวิตช์เหล่านั้น (ส่วนใหญ่เป็นสวิตช์เก่าที่ไม่มีการจัดการและราคาถูก)
  6. ลอง iPerfs พร้อมกันจากสองไคลเอนต์ที่แตกต่างกันไปยังโฮสต์ที่แตกต่างกันสองเพื่อให้คุณสามารถมั่นใจได้ว่าข้อ จำกัด ไม่ได้เป็นผลมาจาก CPU หรือ NIC การ์ดท้องถิ่นราคาถูก

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

0

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


0

คุณเคยใช้ tcpdump เพื่อตรวจสอบการสูญหายของแพ็คเก็ตเมื่อใช้ iPerf เพื่อให้แน่ใจว่าการสูญเสียแพ็กเก็ตที่คุณคำนวณด้วย tcpdump ตรงกับ iperf หรือไม่

คุณอาจค้นพบว่าวิธีการวัดของคุณนั้นไม่เทียบเท่ากัน


0

iperf ไม่ยกเลิกแพ็กเก็ตที่มาจากลำดับด้วย UDP โดยอัตโนมัติหรือไม่ คุณอาจดูกระวนกระวายใจเล็กน้อยในการเชื่อมต่อ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.