TL; DR
เพื่อให้คำตอบที่ชัดเจนการทดสอบเพิ่มเติมดูเหมือนจำเป็น แต่หลักฐานชี้ให้เห็นว่าลีนุกซ์เป็นระบบปฏิบัติการที่ใช้งานได้จริงในชุมชนที่มีความล่าช้าน้อยมากซึ่งยังประมวลผลปริมาณงาน Mpps เป็นประจำ ไม่ได้หมายความว่าเป็นไปไม่ได้กับ Windows แต่ Windows อาจจะล้าหลังไปเล็กน้อยแม้ว่ามันอาจเป็นไปได้ที่จะได้รับหมายเลข Mpps แต่นั่นจำเป็นต้องมีการทดสอบเพื่อยืนยันและเช่นหากพิจารณาว่าอะไร (CPU) มีค่าใช้จ่ายตัวเลขเหล่านั้นสามารถทำได้
NB นี่ไม่ใช่คำตอบที่ฉันตั้งใจจะยอมรับ มันมีวัตถุประสงค์เพื่อให้ทุกคนที่สนใจในการตอบคำถามบางคำแนะนำเกี่ยวกับสถานที่ที่เรายืนและสถานที่ที่จะตรวจสอบเพิ่มเติม
Len Holgate ผู้ซึ่งอ้างอิงจาก google ดูเหมือนจะเป็นคนเดียวที่ได้ทำการทดสอบ RIO เพื่อให้มีประสิทธิภาพมากขึ้นจากระบบเครือข่าย Windows (และเผยแพร่ผลลัพธ์) ได้ชี้แจงในข้อคิดเห็นในบล็อกของเขาว่าเขาใช้คำสั่งผสม IP / พอร์ตเดียว สำหรับการส่งแพ็กเก็ต UDP
กล่าวอีกนัยหนึ่งผลลัพธ์ของเขาควรเปรียบเทียบกับตัวเลขแกนเดี่ยวในการทดสอบบน Linux (แม้ว่าเขาจะใช้ 8 เธรด - ซึ่งโดยไม่ต้องตรวจสอบรหัสของเขาก็ดูเหมือนจะเป็นอันตรายต่อประสิทธิภาพเมื่อจัดการกระแสแพ็คเก็ต UDP เพียงครั้งเดียว ทำการประมวลผลอย่างหนักของแพ็กเก็ตและเขากล่าวถึงเพียงไม่กี่เธรดที่ใช้จริงซึ่งจะทำให้เข้าใจได้) แม้ว่าเขาจะพูดว่า:
ฉันไม่ได้พยายามอย่างหนักเพื่อให้ได้ประสิทธิภาพสูงสุดเพียงเพื่อเปรียบเทียบประสิทธิภาพที่สัมพันธ์กันระหว่าง API เก่าและใหม่ดังนั้นฉันจึงไม่ได้ทำการทดสอบอย่างละเอียด
แต่อะไรคือสิ่งที่ทำให้โซนความสะดวกสบาย (สัมพัทธ์) ของ IOCP มาตรฐานสำหรับโลก RIO คร่าวๆนอกจาก "พยายามอย่างหนัก"? อย่างน้อยที่สุดก็จะเกี่ยวข้องกับแพ็คเก็ต UDP กระแสข้อมูล
ฉันเดาว่าเขาหมายถึงอะไร - ในขณะที่เขาลองวิธีการออกแบบที่หลากหลายในการทดสอบ RIO หลายครั้ง - ก็คือเขาไม่ได้ปรับแต่งการตั้งค่า NIC อย่างละเอียดเพื่อบีบเอาประสิทธิภาพขั้นสุดท้ายออกมา ซึ่งเช่นในกรณีของขนาดบัฟเฟอร์ที่รับอาจมีผลกระทบเชิงบวกอย่างมากต่อ UDP ที่ได้รับประสิทธิภาพและตัวเลขการสูญเสียต
อย่างไรก็ตามปัญหาเมื่อพยายามเปรียบเทียบผลลัพธ์ของเขาโดยตรงกับการทดสอบอื่น ๆ ของ Linux / Unix / BSD คือ: การทดสอบส่วนใหญ่เมื่อพยายามผลักขอบเขต "แพ็คเก็ตต่อวินาที" ให้ใช้ขนาดแพ็กเก็ต / เฟรมที่เล็กที่สุดที่เป็นไปได้เช่น Ethernet เฟรมขนาด 64 ไบต์ Len ทดสอบแพ็คเก็ต 1024 ไบต์ (-> เฟรม 1070 byte) ซึ่ง (โดยเฉพาะสำหรับ No-Nagle UDP) คุณจะได้รับตัวเลข "บิตต่อวินาที" ที่สูงขึ้นมาก แต่อาจไม่ผลักขอบเขต pps เท่าที่จะทำได้ด้วยแพ็กเก็ตขนาดเล็ก . ดังนั้นจึงไม่ยุติธรรมที่จะเปรียบเทียบตัวเลขเหล่านี้ตามที่เป็นอยู่
การสรุปผลการสืบเสาะของฉันใน Windows UDP ได้รับประสิทธิภาพ:
- ไม่มีใครใช้ Windows จริงๆเมื่อพยายามพัฒนา latency ต่ำพิเศษและ / หรือแอปพลิเคชั่นปริมาณงานสูงวันนี้พวกเขาใช้ Linux
- การทดสอบประสิทธิภาพและการรายงานผลจริงทั้งหมด (เช่นไม่ใช่การโฆษณาผลิตภัณฑ์) แทบทุกวันนี้อยู่บน Linux หรือ BSD (ขอบคุณ Len ที่เป็นผู้บุกเบิกและให้การอ้างอิงกับเราอย่างน้อยหนึ่งจุด!)
- UDP (ซ็อกเก็ตมาตรฐาน) บน Windows เร็วกว่า / ช้ากว่าบน Linux หรือไม่ ฉันยังไม่สามารถบอกได้จะต้องทำการทดสอบของฉันเอง
- UDP ประสิทธิภาพสูง (RIO vs netmap) บน Windows เร็วกว่า / ช้ากว่าบน Linux หรือไม่ Linux จัดการสายความเร็ว 10Gb ได้อย่างง่ายดายด้วยคอร์เดียวที่ 900MHz, Windows, ในกรณีที่ดีที่สุดที่เผยแพร่สามารถเพิ่มสูงถึง 43% หรือ 492kpps สำหรับขนาดแพ็คเก็ต UDP ขนาดใหญ่ 1024 เช่นตัวเลข bps สำหรับขนาดเล็กอาจจะมีนัยสำคัญ แย่กว่านั้นแม้ว่าตัวเลข pps จะเพิ่มขึ้น (ยกเว้นการจัดการขัดจังหวะหรือค่าใช้จ่ายพื้นที่เคอร์เนลอื่น ๆ เป็นปัจจัย จำกัด )
สำหรับเหตุผลที่พวกเขาใช้ linux นั้นจะต้องเป็นเพราะการพัฒนาโซลูชันที่เกี่ยวข้องกับการเปลี่ยนแปลงเคอร์เนลเช่น netmap หรือ RIO - จำเป็นเมื่อผลักดันประสิทธิภาพให้ถึงขีด จำกัด - เป็นไปไม่ได้เลยที่ระบบปิดเช่น Windows จะเป็นไปไม่ได้ หรือคุณมีสัญญาพิเศษกับ Microsoft นี่คือเหตุผลที่ RIO เป็นผลิตภัณฑ์ MS
ในที่สุดเพียงแค่ให้ตัวอย่างสุดยอดของสิ่งที่ฉันค้นพบและเกิดขึ้นในพื้นที่ Linux:
เมื่อ 15 ปีที่แล้วบางคนได้รับ 680kpps โดยใช้ซีพียู Pentium III 800 mHz , บัสด้านหน้า 133 mHz ใน 1GbE NIC แก้ไข : พวกเขาใช้คลิกเราเตอร์โหมดเคอร์เนลที่ข้ามเครือข่ายสแต็กมาตรฐานส่วนใหญ่นั่นคือพวกเขา "โกง"
ในปี 2013 Argon Design ได้รับการจัดการ
เลือกติ๊กเพื่อแลกเปลี่ยน latencies ให้น้อยที่สุด 35ns [nano seconds]
Btw พวกเขายังอ้างว่า
รหัสการคำนวณที่มีอยู่ส่วนใหญ่สำหรับการซื้อขายในปัจจุบันถูกเขียนขึ้นสำหรับ Linux บนสถาปัตยกรรมโปรเซสเซอร์ x86
และ Argon ใช้สวิตช์ Arista 7124FXซึ่ง (นอกเหนือจาก FPGA) มีระบบปฏิบัติการ
สร้างขึ้นบนเคอร์เนล Linux มาตรฐาน
