Gluon: أداء VXLAN السيئ

تم إنشاؤها على ٢١ يناير ٢٠١٨  ·  5تعليقات  ·  مصدر: freifunk-gluon/gluon

أثناء اختبار النظام الرئيسي الحالي ، لاحظت انخفاضًا كبيرًا في الأداء عند استخدام VXLAN للشبكة السلكية بدلاً من الطريقة القديمة التي تربط واجهة الشبكة السلكية مباشرةً بـ bat0:

إعدادات الاختبار: TP-Link TL-WDR4300 v1 مقابل Siemens Futro S550 ، كلاهما متصلان بنفس المحول القادر على GBE ، وتم تشغيل VPN في WDR4300:

  1. اختبار مع شبكة Wiremesh القديمة:

بدأ من WDR4300:

root<strong i="10">@ffnoc12</strong>:~# batctl tp -t 10000 a6:07:f9:5a:71:db
Test duration 10010ms.
Sent 382825692 Bytes.
Throughput: 36.47 MB/s (305.95 Mbps)

بدأت من Offloader

root<strong i="14">@ffnocoffloader</strong>:~# batctl tp -t 10000 46:3d:e1:c3:7f:63
Test duration 10020ms.
Sent 457679556 Bytes.
Throughput: 43.56 MB/s (365.41 Mbps)
  1. نفس الاختبار مع VXLAN:

تم البدء في WDR:

root<strong i="20">@ffnoc12</strong>:~# uci set network.mesh_wan.legacy='0'
root<strong i="21">@ffnoc12</strong>:~# uci commit network
root<strong i="22">@ffnoc12</strong>:~# /etc/init.d/network restart
root<strong i="23">@ffnoc12</strong>:~# batctl tp -t 10000 a6:07:f9:5a:71:db
Test duration 10020ms.
Sent 30967956 Bytes.
Throughput: 2.95 MB/s (24.72 Mbps)

تم البدء في Offloader:

root<strong i="27">@ffnocoffloader</strong>:~# batctl tp -t 10000 46:3d:e1:c3:7f:63
Test duration 10110ms.
Sent 47189196 Bytes.
Throughput: 4.45 MB/s (37.34 Mbps)

بالنسبة للمجالات ، منع اختصار VXLAN (أو أي خيار لمصادقة شبكة Wiremesh) هي فكرة جيدة ، ولكن لأغراض RF Backbone ، هذا بطيء جدًا.

bug regression

التعليق الأكثر فائدة

كان هذا الفحص مع iperf على WDR3600. من الواضح أن هذا أضر بأداء الاختبار ، لكنني أردت فقط اختبار الأداء النسبي مع وبدون VXLAN ، وليس الحد الأقصى من الإنتاجية التي يمكن تحقيقها.

ال 5 كومينتر

لقد اختبرت هذا مع كل من iperf و batctl tp ؛ يمكنني إعادة إنتاج انخفاض الأداء الشديد باستخدام batctl ، ولكن ليس مع iperf (أو بالأحرى ، مع iperf ، كان الأداء سيئًا إلى حد ما حتى في الوضع القديم). السبب هو التجزئة: يتم اختيار حجم الحزمة التي يستخدمها مقياس سرعة نقل batctl بحيث تمر عبر رابط 1500 بايت بدون تجزئة ، ولكن يجب تجزئتها عبر ارتباط 1430 بايت.

لذلك ، تعد الأرقام التي قدمها iperf أكثر دقة لسيناريوهات الحياة الواقعية ، حيث يكون التجزئة ضروريًا عادةً في كل من الوضع VXLAN والوضع القديم (أو في أي منهما ، مع تثبيت MSS المناسب). لقد دفعت بعض التحسينات للتشبيك السلكي (2950cc3f596d5565390aaa1188cdb67d2401840b يؤثر على كل من الوضع القديم ووضع VXLAN ، a9edd43693a02e0829d04a83a13ebbf0f7eef3ee و e54b37d835624059d005b3f77. ستكون هناك أيضًا متابعة لـ 7ae8a511267e7f280862fcd57f8ae394b947b799 في غضون أيام قليلة.

مع تطبيق كل هذه التصحيحات (بما في ذلك المتابعة) ، قمت بقياس الأرقام التالية باستخدام iperf على WDR3600 (باستخدام دفتر ملاحظاتي على الجانب الآخر) بدون تثبيت MSS:

  • RX القديم: 96.9 ميجابت / ثانية
  • TX القديم: 107 ميجابت / ثانية
  • VXLAN RX: 56.5 ميجابت / ثانية
  • VXLAN TX: 46.2 ميجابت / ثانية

لتقليل MSS لتجنب التجزئة ، أحصل على الأرقام التالية:

  • RX القديم: 164 ميجابت / ثانية
  • TX القديمة: 149 ميجابت / ثانية
  • VXLAN RX: 88.5 ميجابت / ثانية
  • VXLAN TX: 74.3 ميجابت / ثانية

لذا فإن VXLAN يكلف الأداء بلا شك ، لكنه ليس بأي حال من الأحوال سيئًا كما يوحي batctl tp . سأبحث في المزيد من خيارات التحسين (على سبيل المثال ، ip6tables ، المسؤولة عن جزء كبير من انخفاض الأداء).

هل قمت بتشغيل iperf على wdr3600؟ إذا كان الأمر كذلك ، ألم يكن هذا الاختبار مقيدًا بأداء وحدة المعالجة المركزية التي يستخدمها iperf نفسه؟
لقد فعلنا دائمًا iperf مع أجهزة x86 حقيقية على كلا الطرفين ، فقط.
إذا كنت على المسار الخطأ ، يرجى تجاهل :- D

كان هذا الفحص مع iperf على WDR3600. من الواضح أن هذا أضر بأداء الاختبار ، لكنني أردت فقط اختبار الأداء النسبي مع وبدون VXLAN ، وليس الحد الأقصى من الإنتاجية التي يمكن تحقيقها.

باستخدام d87a798ac3d1e8cef3d83c22c4482afd21886c34 ، تم إجراء جميع تحسينات الإنتاجية الممكنة بسهولة. سيتم إعادة النظر في أداء جدار الحماية بعد الإصدار التالي.

ربما يمكننا توثيق مدى تحسن الأداء مقارنة بالقياسات lephisto و NeoRaider التي أجراها في يناير؟
أو العكس ، إلى أي مدى لا يزال الأداء يعاني مقارنةً بالتشابك القديم.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات