سؤال هل من الممكن معالجة ملايين datagrams في الثانية مع Windows؟


أنا التحقيق إذا كان بإمكاني تنفيذ تطبيق HPC على ويندوز ذلك يتلقى مخططات بيانات الإرسال المتعدد لـ UDP صغيرة (في الغالب 100-400 بايت) بمعدل عالٍ ، باستخدام عشرات أو حتى 200 مجموعة بث متعدد (بمعنى استخدام MSI-X و RSS يمكنني القياس إلى عدة نوى) ، يقوم ببعض المعالجة لكل حزمة ، ثم يرسلها. إرسال عبر برنامج التعاون الفني تمكنت من الصعود بقدر ما كنت في حاجة إلى (6.4Gb / ثانية) دون أن تصل إلى الجدار ، ولكن تبين أن استقبال مخططات البيانات بمعدلات pps عالية يمثل مشكلة.

في الاختبار الأخير على جهاز NUMA عالي المواصفات مع NIC 10 جيجابت إيثرنت NIC على Windows 2012 R2 ، لم أتمكن إلا من استقبال مئات الآلاف من مخططات بيانات UDP في الثانية (إسقاط مبكر ، أي بدون معالجة البيانات فعليًا ، لإزالة تكاليف المعالجة الخاصة بتطبيقي من المعادلة لمعرفة مدى السرعة التي تحصل عليها) باستخدام نوى 2 × 12 ، ويبدو أن جزء النواة من 12 مجموعة متعددة البث المختبرة قد تم توزيعه عبر 8 أو 10 قلب من عقدة NUMA واحدة (طوابير RSS القصوى تم تعيينها إلى 16) - وإن كان ذلك باستخدام تطبيق .net ، فيجب أن تتمكن التطبيقات الأصلية من الانتقال بشكل أسرع.

لكن حتى لين هولجيت  تمكنت فقط لتلقي الحزم UDP في 500kpps في اختبارات Windows RIO عالية الأداء الخاصة بهباستخدام حمولة UDP يبلغ 1024 بايت.

في QLogic في whitepaper (نظام التشغيل تحت الاختبار لم يرد ذكره) يتم تعيين حدود "توجيه الحزم الصغيرة فائقة متعددة الخيوط" (بحيث يتضمن كل من استقبال والإرسال اللاحقة؟) في 5.7Mpps. في مقالات على شبكات لينكس، يتم تعيين الحدود في 1Mpps إلى 2Mpps لكل نواة (يقال أنه يزيد أو يقل خطيًا) أو حتى 15Mpps مع حلول خاصة تتجاوز النواة.

مثلا netmap

يمكن أن تولد حركة المرور في معدل الخط (14.88Mpps) على وصلة 10GigE بنواة واحدة فقط تعمل بسرعة 900 ميجا هرتز. وهذا يساوي حوالي 60-65 دورة على مدار الساعة لكل حزمة ، ويتوازن بشكل جيد مع النوى وتواتر الساعة (مع 4 نوى ، يتم تحقيق معدل خط في أقل من 450 ميغاهرتز). يتم الوصول إلى معدلات مماثلة على جانب التلقي.

إلى أي مدى يمكنني اتخاذ (أحدث إصدارات) Windows / Windows Server ، ولا سيما تلقي بروتوكول UDP المتعدد كما هو موضح في الفقرة الرائدة؟

تصحيح توجد مشاركة مدونة في Cloudflare - وقسم تعليق مثير للاهتمام - حول كيفية القيام بذلك على Linux: كيفية الحصول على مليون حزمة في الثانية، وهناك المقابلة صفحة تعليقات الهاكر.


11
2018-06-02 12:55


الأصل


Ramhound من الناحية النظرية ، فمن الممكن على الأرجح في نظام التشغيل Windows. ولكن كيف يمكن في الممارسة؟ لقد صادفت الآن عددًا قليلاً من التقارير من الأشخاص الذين حققوا هذه المستويات في Linux على الأجهزة القياسية ، ولكن ليس واحدًا في أي مكان قريب من Windows. وكيف تعتقد أنه يمكنني تقليل نطاق السؤال؟ هذا فقط: "ما هي أعلى معدلات الإرسال المتعدد لـ UDP في Windows؟". الجزء الأكبر من النص في سؤالي هو مجرد أمثلة يجب أن تظهر أنه من الممكن مع لينكس - وأنني فعلت واجباتي المنزلية. - Eugene Beresovsky
Ramhound "إذا كان من الممكن على لينكس ممكن على ويندوز". أنا على التوالي لا أوافق ... نظام واحد أن يتبادر إلى ذهني على الفور هو iptables .. نعم حسن الحظ محاكاة هذا النظام على النوافذ. ^ _ ^ - NiCk Newman
لم أكن بالفعل أحاول ذلك بشدة ، لذا يمكنك دائمًا أخذ جميع الرموز المتوفرة لدي لاختبار RIO الذي قمت به واستمراري في الدفع. - Len Holgate


الأجوبة:


وفقا لمايكروسوفت ، الاختبارات في مختبرهم أظهر هذا "على خادم معين في الاختبار المبكر" لل RIO، كانوا قادرين على التعامل

  • 2Mpps دون خسارة في Windows Server 2008R2 ، أي بدون RIO
  • 4Mpps على (خادم ما قبل الإصدار) Windows Server 8 باستخدام RIO

لقطة من هذا الفيديو (44:33):

enter image description here

لذا فإن الإجابة على سؤالي Is it possible to process millions of datagrams per second with Windows? سيكون: نعم فعلا، ويبدو أنه كان حتى قبل ريو ، في Windows Server 2008R2.

ولكن بالإضافة إلى الأرقام الرسمية ، خاصة في البرامج التي لم يتم إطلاقها ، والتي يجب أخذها مع قليل من الملح ، مع المعلومات المتفرقة فقط في هذا العرض ، فإن العديد من الأسئلة حول الاختبار ، وبالتالي كيفية تفسير النتائج بشكل صحيح ، تظل قائمة. أهمها:

  1. هل الأرقام الخاصة بالإرسال؟ يستلم؟ أو ربما للتوجيه (على سبيل المثال ، تلقي + إرسال)؟
  2. ما حجم الحزمة؟ -> ربما يكون أقل قدر ممكن ، كما هو الحال عادة عند محاولة الحصول على أرقام pps التباهي
  3. عدد الاتصالات (في حالة TCP) / حزمة تدفقات (إذا كان UDP)؟ -> على الأرجح ما يلزم لتوزيع عبء العمل بحيث يمكن استخدام كل النوى الموجودة
  4. ما إعداد الاختبار؟ مواصفات الجهاز و NIC والأسلاك

الأول هو أمر حاسم ، لأن Sends و Receives تتطلب خطوات مختلفة ويمكن أن تظهر اختلافات جوهرية في الأداء. بالنسبة للأرقام الأخرى ، يمكننا أن نفترض أن أقل حجم للرزم ، مع تيار واحد على الأقل للتوصيل / الحزمة لكل نواة كان يتم استخدامه على جهاز عالي المواصفات للحصول على أقصى عدد ممكن من أرقام Mpps.


تصحيح أنا فقط تعثرت على وثيقة إنتل على معالجة حزم عالية الأداء على Linux ، ووفقًا لذلك ، فإن (Linux)

يمكن للنظام الأساسي الحفاظ على معدل معاملات يبلغ حوالي 2 مليون معاملة في الثانية

باستخدام مجموعة شبكات Linux القياسية (على مضيف فعلي يحتوي على قلبين 2x8). تتضمن المعاملة في اختبار الطلب / الرد كلاهما

  1. استقبال حزمة UDP
  2. إعادة توجيه لاحقة من تلك الحزمة

(باستخدام netperf's netserver). كان الاختبار يدير 100 صفقة في نفس الوقت. هناك الكثير من التفاصيل في الصحيفة ، للمهتمين. أتمنى أن يكون لدينا شيء من هذا القبيل لمقارنة Windows ... على أي حال ، إليك المخطط الأكثر ملاءمة لاختبار طلب / الرد هذا:

enter image description here


5
2018-06-07 23:32





ليرة تركية، والدكتور

لإعطاء إجابة محددة ، يبدو أن المزيد من الاختبارات ضروري. لكن الأدلة الظرفية تشير إلى أن نظام التشغيل Linux هو نظام التشغيل المستخدم بشكل عملي حصريًا في مجتمع الكمون المنخفض جدًا ، والذي يعالج أيضًا بشكل روتيني أحمال عمل Mpps. هذا لا يعني أنه من المستحيل مع Windows ، ولكن من المحتمل أن يكون نظام التشغيل Windows متخلفًا قليلاً ، على الرغم من أنه قد يكون من الممكن تحقيق أرقام Mpps. ولكن هذا يحتاج إلى اختبار للتأكد ، وعلى سبيل المثال ، لمعرفة ما (وحدة المعالجة المركزية) تكلف هذه الأرقام يمكن تحقيقه.

حاشية هذه ليست إجابة أعتزم قبولها. الغرض منه هو إعطاء أي شخص مهتم في إجابة للسؤال بعض التلميحات حول المكان الذي نقف فيه ومكان إجراء مزيد من الاستقصاء.


لين هولجيت ، الذي يبدو أنه هو الشخص الوحيد الذي قام باختبار RIO للحصول على المزيد من الأداء من Windows التشبيك (ونشر النتائج) ، مجرد توضيح في تعليق على مدونته أنه كان يستخدم مجموعة واحدة من عناوين IP / Port لإرسال حزم UDP.

وبعبارة أخرى ، له يجب أن تكون النتائج قابلة للمقارنة إلى حد ما مع الأرقام الأساسية الوحيدة في الاختبارات على لينكس (على الرغم من أنه يستخدم 8 خيوط - والتي ، بدون التحقق من شفرته حتى الآن ، يبدو ضارًا بالأداء عند معالجة حزمة واحدة فقط من حزم UDP وعدم القيام بأي معالجة ثقيلة للحزم ، ويذكر أنه لا يتم استخدام سوى عدد قليل من مؤشرات الترابط ، من المنطقي). هذا على الرغم من قوله:

لم أكن أحاول أن أحصل على أقصى قدر من الأداء لمجرد مقارنة الأداء النسبي بين واجهات برمجة التطبيقات القديمة والجديدة ولذا لم أكن شاملاً في الاختبار.

لكن ما هو التخلي عن منطقة الراحة (النسبية) في IOCP القياسية لعالم RIO الأكثر تقاربًا بخلاف "جاهد"؟ على الأقل بقدر ما يتعلق الأمر دفق حزمة UDP واحدة.

أعتقد أن ما يعنيه - كما فعل في أساليب التصميم المختلفة في العديد من اختبارات RIO - هو أنه لم يكن على سبيل المثال. ضبط إعدادات NIC للضغط على آخر جزء من الأداء. التي ، على سبيل المثال في حالة ما اذا تلقي حجم المخزن المؤقت يمكن أن يكون لها تأثير إيجابي كبير على UDP تتلقى الأداء وفقدان البيانات.

ولكن المشكلة عند محاولة إجراء مقارنة مباشرة لنتائجه مع اختبارات Linux / Unix / BSD الأخرى هي: معظم الاختبارات ، عند محاولة دفع حدود "الحزم في الثانية" ، تستخدم أصغر حجم ممكن للحزمة / الإطار ، أي إيثرنت إطار 64 بايت. اختبر لين حزم 1024 بايت (-> إطار 1070 بايت) ، والتي (خاصة بالنسبة لـ No-Nagle UDP) يمكن أن تحصل على أرقام "bits per second" أعلى من ذلك بكثير ، ولكن قد لا تدفع حدود pps إلى أقصى ما يمكن عند الحزم الصغيرة . لذا لن يكون من العدل مقارنة هذه الأرقام كما هي.

تلخيص نتائج بحثي في ​​Windows UDP تلقي الأداء حتى الآن:

  • لا أحد يستخدم Windows فعلاً عند محاولة تطوير تطبيقات وقت الاستجابة المنخفضة و / أو الإنتاجية العالية جدًا ، فهذه الأيام يستخدمون Linux
  • من الناحية العملية جميع اختبارات الأداء والتقارير مع النتائج الفعلية (أي ليس مجرد إعلان عن المنتجات) هذه الأيام موجودة على لينكس أو بي إس دي (بفضل لين لكونها رائدة وتعطينا نقطة مرجعية واحدة على الأقل!)
  • هل UDP (مقابس قياسية) على نظام Windows أسرع / أبطأ من Linux؟ لا أستطيع أن أخبرك حتى الآن ، يجب أن أقوم باختباري الخاص
  • هل UDP عالي الأداء (RIO مقابل netmap) على نظام Windows أسرع / أبطأ من نظام التشغيل Linux؟ لينكس بسهولة يعالج كامل سرعة خط 10GB مع نواة واحدة في 900MHz ، ويندوز ، في أفضل حالة نشرت يمكن أن تصل إلى 43٪ أو 492kpps لحجم حزمة UDP كبير من 1024 ، أي أن أرقام bps للأحجام الأصغر قد تكون أسوأ بشكل ملحوظ ، على الرغم من أن أرقام pps سترتفع على الأرجح (إلا إذا كانت معالجة المقاطعة أو بعض المساحة النواة الأخرى هي الحد عامل).

بالنسبة إلى سبب استخدامهم للينكس ، يجب أن يكون ذلك لأن تطوير الحلول التي تتضمن تغييرات في النواة مثل netmap أو RIO - ضروري عند دفع الأداء إلى حدود - يكاد يكون مستحيلاً مع نظام مغلق مثل Windows ، إلا إذا تم تسجيل رواتبك في ريدموند ، أو لديك عقد خاص مع Microsoft. ولهذا السبب RIO هو منتج MS.

أخيرًا ، فقط لأعطي بعض الأمثلة المتطرفة لما اكتشفته وما يجري في أرض لينكس:

بالفعل منذ 15 عاما ، كان بعض تلقي 680kpps باستخدام 800 ميغاهرتز بنتيوم الثالث وحدة المعالجة المركزية ، 133 ميغاهرتز الحافلة الأمامية على NIC 1GbE.  تصحيح: كانوا يستخدمون انقر، جهاز توجيه وضع kernel يتجاوز الكثير من مكدس شبكة الاتصال القياسية ، بمعنى أنها "cheated".

في عام 2013 ، تصميم أرغون تمكن للحصول على

ضع علامة على الفترات الزمنية للتداول حتى 35ns [nano seconds]

راجع للشغل كما يدعون ذلك

تتم كتابة الغالبية العظمى من كود الحوسبة الحالي للتداول اليوم لـ Linux على معماريات المعالج x86.

ويستخدم الأرجون مفتاح Arista 7124FX، أن (بالإضافة إلى FPGA) لديه نظام التشغيل

بنيت على أساس نواة لينكس القياسية.


2
2018-06-05 20:27





سوف تحتاج بالتأكيد "قياس" تكوينات مختلفة والسيناريوهات. ويمكن القيام بذلك AFAIK مع اثنين من معدات المقدمة من قبل شركتين. إيكسيا و SPIRENT. أنها توفر مولدات المرور القائمة على الأجهزة قادرة على ضخ حركة المرور في سرعة الخط. وهي تقدم اختبار المنحدر حيث يمكنك اكتشاف السرعة التي قد ينهار بها نظامك الخاص. الأجهزة غالية الثمن ولكن يمكنك استئجارها.


0
2018-06-13 06:50