Gluon: طلب الميزة: استخدم ميزات 802.11s للتحكم بشكل أفضل في الروابط الشبكية
للحصول على أداء أفضل ، قد يكون من الجيد التحكم في بعض روابط الشبكة
يتميز 802.11s ببعض الخيارات التي يمكننا استخدامها للتحكم في روابط الشبكة الخاصة بالعقدة.
على سبيل المثال ، يمكننا توفير قائمة بيضاء أو سوداء للعقد التي تتشابك معها العقدة:
https://github.com/o11s/open80211s/wiki/HOWTO#advanced -tinkering
معلمات 802.11s الممكنة الأخرى هي:
معلمات الشبكة الممكنة هي:
- شبكة_ريتري_مهلة
- mesh_confirm_timeout
- شبكة_ملكية_مهلة
- شبكة_الحد الأقصى_الارتباطات
- mesh_max_retries
- mesh_ttl
- mesh_element_ttl
- شبكة_الآلية_الفتح_الروابط
- mesh_hwmp_max_preq_retries
- شبكة_مسار_وقت_ التحديث
- mesh_min_discovery_timeout
- mesh_hwmp_active_path_timeout
- mesh_hwmp_preq_min_interval
- mesh_hwmp_net_diameter_traversal_time
- شبكة_hwmp_rootmode
- mesh_hwmp_rann_interval
- شبكة_الإعلانات
- شبكة_تقديم
- mesh_sync_offset_max_neighor
- mesh_rssi_threshold
- mesh_hwmp_active_path_to_root_timeout
- mesh_hwmp_root_interval
- mesh_hwmp_confirmation_interval
- وضع_الطاقة_الشبكة
- شبكة_واكي_نافذة
- شبكة_الروابط_المهلة
سيكون من الجيد أيضًا أن تظهر معلمات تفريغ محطة iw dev mesh0 مثل معدلات البت والإنتاجية المتوقعة عند الحالة. (راجع للشغل: أعتقد أن الفاصل الزمني للإشارة 100 يمكن أن يكون أطول.)
A-Kasper
ال 4 كومينتر
أعتقد أن معظم خيارات 11 ثانية ليست ممتعة للغاية بالنسبة لنا ، لأننا نقوم بجميع قرارات التوجيه في بروتوكول توجيه ذي طبقة أعلى ونستخدم فقط 11 ثانية كبديل للوضع المخصص.
تم إجراء بعض الأعمال المتعلقة بالسماح بروابط القائمة السوداء في freifunk-gluon / packs # 118 ، لكنها لم تنته بعد.
من المحتمل أن تكون زيادة الفاصل الزمني للإشارة فكرة جيدة ، فنحن نحتاج فقط إلى تحديد قيمة جيدة (أيضًا ، تستخدم جميع VIFs نفس الفاصل الزمني للإشارة ، لذا ستؤثر التغييرات على واجهات AP أيضًا).
NeoRaider
في ٧ يوليو ٢٠١٧
لن تؤدي زيادة الفاصل الزمني للإشارة إلى حل مشكلة ازدحام التردد. لا تتوقع زيادة كبيرة في النطاق الترددي من ذلك (بحد أقصى 10٪). ما تريده حقًا هو TDMA أو RTS / CTS على الأقل في حالة تداخل BSS. على سبيل المثال ، قام http://netshe.ru/ ببناء تطبيق TDMA المستند إلى batadv14 والذي لا يستخدم فقدان الحزمة ولكن معلومات wifi nl80211 للحسابات المترية (لكنها مغلقة المصدر ولا يتم صيانتها بشكل جيد بما فيه الكفاية).
ATH9K HMAC https://github.com/szehl/ath9k-hmac هو تطبيق لإثبات صحة استخدام اختراق بسيط لجعل TDMA يعمل دون كسر CSMA / CA. باستخدام هذا ، يمكن التأكد من أن شبكات AP لا تتداخل مع شبكات Mesh ، ولكنها ستحتاج إلى شخص مثل NeoRaider لتنظيف هذا لدعم kernel المنبع. تمت كتابة واجهة اتصال netlink الخاصة بمساحة المستخدمين بلغة C ++ وتحتاج إلى إعادة كتابتها في لغة C أولاً. لا يوجد أيضًا معالج للإعداد الديناميكي لقواعد TDMA.
CodeFetch
في ١٨ نوفمبر ٢٠١٧
ربما وجدت مشكلة تجعل أداء 802.11 أسوأ.
تحتوي 802.11s على ميزة تسمى MCCA وهي آلية لتجنب الاصطدام تعمل على غرار TDMA. تتم مزامنة كافة أجهزة 802.11 المجاورة (راجع مزامنة شبكة 802.11s ) افتراضيًا. هذا دقيق بشكل مذهل (متوسط <10 ميكروثانية). على عكس TDMA MCCA لا يستخدم فترات زمنية ولكن فترات DTIM. يمكن لعقدة 802.11s أن تطلب عبر البث الأحادي أو المتعدد مثل فاصل DTIM لاستخدامها. سترفض جميع العقد المجاورة ذلك أو تقبله عن طريق الرد بناءً على أي تداخل مع الفواصل الزمنية الخاصة بها. وبالتالي فإن MCCA هي نوع من ميزة TDMA ذاتية التنظيم لـ 802.11s وهي رائعة حقًا وأتمنى أن أعرف عنها من قبل.
بقدر ما أستطيع أن أرى فترات DTIM لواجهة الشبكة ليس لها أي تأثير على VIFs الأخرى.
تحرير: أعتقد أن هذه ليست المشكلة الكبيرة حيث يبدو أن MCCA غير مطبق في ath9k على الإطلاق. هل يمكن أن تواجه EDCA أي مشاكل مع VIFs المتعددة (هل تستخدم جدولة قائمة الانتظار)؟ ماذا عن برامج تشغيل Broadcom / ralink؟ أعتقد أنه يمكن للمرء التحقق من IEs إذا كان الكود مغلق المصدر أو محيرًا للغاية. للأسف لا أعرف التنسيق الصحيح لذلك ووجدت هذا فقط:
يمكن لكل محطة
تمكين دعمه لـ MCCA وإظهار هذا الدعم من خلال تعيين 1 بت تمكين MCCA ،
وهو موجود في الحقل الفرعي Mesh Capability الخاص بعنصر تكوين الشبكة الموجود في
منارات واستجابات التحقيق. قد تدعم محطة أخرى MCCA ولكنها لا تنفذها (ملف
يتضمن الحقل الفرعي Mesh Capability أيضًا بت MCCA المدعوم). في هذه الحالة ، يمكن للمحطة
المشاركة في آلية MCCA ، ولكن لا يمكن بدء أي حجز MCCA.
انظر https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf
CodeFetch
في ١٣ ديسمبر ٢٠١٧
الإغلاق: معظم خيارات 11s ليست ذات صلة بـ Gluon. إذا وجدنا خيارًا معينًا مثيرًا للاهتمام للدعم ، فيجب فتح مشكلة منفصلة.
أنظر أيضا:
- # 421 (منع ارتباطات الشبكة الفردية)
- # 2028 (تكوين الفاصل الزمني للمنارة)
NeoRaider
في ٣٠ مايو ٢٠٢٠
القضايا ذات الصلة
CodeFetch
·
5تعليقات
HACKER-3000
·
5تعليقات
sargon
·
4تعليقات
rubo77
·
5تعليقات
rubo77
·
6تعليقات
التعليق الأكثر فائدة
أعتقد أن معظم خيارات 11 ثانية ليست ممتعة للغاية بالنسبة لنا ، لأننا نقوم بجميع قرارات التوجيه في بروتوكول توجيه ذي طبقة أعلى ونستخدم فقط 11 ثانية كبديل للوضع المخصص.
تم إجراء بعض الأعمال المتعلقة بالسماح بروابط القائمة السوداء في freifunk-gluon / packs # 118 ، لكنها لم تنته بعد.
من المحتمل أن تكون زيادة الفاصل الزمني للإشارة فكرة جيدة ، فنحن نحتاج فقط إلى تحديد قيمة جيدة (أيضًا ، تستخدم جميع VIFs نفس الفاصل الزمني للإشارة ، لذا ستؤثر التغييرات على واجهات AP أيضًا).