Riot: IEEE802.15.4: HW Auto ACK يعتبر ضارًا

في معظم الحالات ، يمكن أن تكون هذه الممارسة ضارة.

من الناحية الواقعية ، كم مرة يتسبب هذا في ضرر فعلي؟ ما النسبة المئوية للرسائل التي تم تلقيها أثناء تجاهلها بالفعل بواسطة MCU؟

يتحول الراديو إلى وضع TX عند استقباله (# 11256)

هذه الحالة هي فريدة من نوعها لأجهزة الراديو ذات المخزن المؤقت للاستقبال / الإرسال المشترك ، أليس كذلك؟ لذلك يؤثر فقط على فئة الأجهزة at86rf2xx

يمكن أن ينتج عن هذا سلوكيات غريبة ، ...

هل لديك بعض الأمثلة حيث يسبب هذا مشاكل؟

وبالتالي ، أقترح ترك Auto ACK اختياريًا وتنفيذ استجابة ACK في البرنامج

هل لديكم بعض الأرقام عن تأثير ذلك على ذلك؟ حجم الفلاش / استخدام ذاكرة الوصول العشوائي ، ولكن أيضًا استخدام الطاقة حيث يجب أن تستيقظ MCU لفترة أطول. كم الوقت المتبقي بين استقبال الإطار ومهلة ack وهل من الواقعي التعامل مع ACK في البرنامج إذا كان الراديو متصلاً عبر SPI؟

إلى جانب وجود L2 أكثر موثوقية

أنا متشكك بعض الشيء بشأن هذا الادعاء (إذا لم يكن ذلك واضحًا بعد من تعليقي) ، فإن التعامل مع L2 acks هو حالة ناعمة في الوقت الفعلي (سيؤدي عدم توفر المواعيد النهائية إلى تدهور الخدمة) والتعامل معها في البرنامج يضع مطلبًا صعبًا على سلوك مكافحة الشغب في الوقت الحقيقي.

لا مانع من استخدام برنامج L2 acks إذا كان مطلبًا صعبًا لبعض طبقات MAC المحددة ، ولكن لم يتم ذكر ذلك من الوصف هنا.

مرحبًا bergzand

من الناحية الواقعية ، كم مرة يتسبب هذا في ضرر فعلي؟ ما النسبة المئوية للرسائل التي تم تلقيها أثناء تجاهلها بالفعل بواسطة MCU؟

بالنسبة للطبقات العليا ، لا تعتبر صفقة كبيرة (مع الأخذ في الاعتبار أنها عادة ما تكون أفضل الجهود).
ومع ذلك ، فإن بعض طبقات MAC و MAC الفرعية (OpenThread و TSCH) تستخدم ACK لتحديث معلومات الجوار.

هذه الحالة هي فريدة من نوعها لأجهزة الراديو ذات المخزن المؤقت للاستقبال / الإرسال المشترك ، أليس كذلك؟ لذلك يؤثر فقط على فئة الأجهزة at86rf2xx

صحيح. أنا فقط أشير إلى السيناريوهات التي قد يحدث فيها ذلك.

هل لديك بعض الأمثلة حيث يسبب هذا مشاكل؟

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

هل لديكم بعض الأرقام عن تأثير ذلك على ذلك؟ حجم الفلاش / استخدام ذاكرة الوصول العشوائي ، ولكن أيضًا استخدام الطاقة حيث يجب أن تستيقظ MCU لفترة أطول. كم الوقت المتبقي بين استقبال الإطار ومهلة ack وهل من الواقعي التعامل مع ACK في البرنامج إذا كان الراديو متصلاً عبر SPI؟

للأسف لا. نظرًا لأنه لم يتم تنفيذه ، فليس لدي أرقام للمقارنة. لدي فقط بعض فروع الاختبار مع ACK التلقائي ، لكنني لم أختبر بشكل أعمق.

أنا متشكك بعض الشيء بشأن هذا الادعاء (إذا لم يكن ذلك واضحًا بعد من تعليقي) ، فإن التعامل مع L2 acks هو حالة ناعمة في الوقت الفعلي (سيؤدي عدم توفر المواعيد النهائية إلى تدهور الخدمة) والتعامل معها في البرنامج يضع مطلبًا صعبًا على سلوك مكافحة الشغب في الوقت الحقيقي.

هناك بعض المعلومات من Tiny OS تفيد بأن برنامج ACK يميل إلى الحصول على نقاط أعلى (https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt) ولكن على الأقل لا توجد ايجابيات خاطئة.
AFAIK لا يتحدث IEEE802.15.4 عن القيود الصعبة (فقط حول قيم المهلة). إذا لم يتم تسليم حزمة ACK في الوقت المناسب ، فسيتم افتراض أنها مفقودة. ولكن كما قيل من قبل ، ليس لدي أي معلومات حول مدى جودة أداء نظام التشغيل مع برامج ACK. سيكون من المثير للاهتمام الحصول على بعض المعايير

لا مانع من استخدام برنامج L2 acks إذا كان مطلبًا صعبًا لبعض طبقات MAC المحددة ، ولكن لم يتم ذكر ذلك من الوصف هنا.

نحتاج إلى تنفيذ برنامج ACK على أي حال لأجهزة الراديو التي لا تدعم Auto ACK والميزات غير المتوفرة في مسرعات الأجهزة (أنا لست على علم بأجهزة الراديو التي تدعم ACKs المحسّنة لأكون صادقًا).
السؤال هو ، هل نريد أن يكون هذا اختياريًا أم إلزاميًا لتكويناتنا الافتراضية؟ كما هو موضح من قبل ، فإن الفكرة ليست إزالة دعم Auto ACK ولكن الحصول على دعم أفضل لـ L2. لا يزال بإمكاننا تمكين Auto ACK إذا أردنا (لهذا السبب اقترحت إضافة قبعات راديو في https://github.com/RIOT-OS/RIOT/pull/11473)

ربما أكون مخطئًا ولكن الحل يبدو بسيطًا:

• نحن ننفذ ARQ (مستقل عن الأجهزة) -> نريد ذلك بغض النظر عن هذه المناقشة.
• نحن نقارن الأداء (وقابلية التشغيل البيني) للأجهزة مقابل تطبيقات البرامج.
• نحن مصممون على إعداد افتراضي خاص بالمنصة ، والذي لا يمنع من تجميع الآخر.

كعقدة جانبية: حقيقة أننا لم نواجه أبدًا المشكلة التي أبرزتها @ jia200x يمكن أن تكون مرتبطة بطبقات MAC المفقودة أعلى الراديو في RIOT. علاوة على ذلك ، مع أجهزة الراديو منخفضة الطاقة المفقودة نتحمل خسارة معينة على أي حال.

ما مدى أهمية ACKs للبرامج لـ 6TiSCH؟ IIRC ، يستخدم OpenWSN برامج ACK جزئيًا لتتبع جودة الارتباط بين الجيران.

ما مدى أهمية ACKs للبرامج لـ 6TiSCH؟ IIRC ، يستخدم OpenWSN برامج ACK جزئيًا لتتبع جودة الارتباط بين الجيران.

لا تتحدث 6TiSCH ضد ACK للأجهزة ، ولكنها تتطلب ACKs محسّنة لتمرير معلومات التوقيت. في OpenWSN ، يتم التعامل مع هذا بواسطة pkg نفسه.

* و ACKs المحسّنة غير مدعومة من قبل الأجهزة التي أعرفها.

علاوة على ذلك ، تكمن مشكلة إمكانات إقرار الأجهزة في بعض الحالات في أنها تتحمل المسؤولية الكاملة عن الآلية دون الكشف بالضرورة عن المعلومات ذات الصلة ، مثل ACK المستلم أو عدد مرات إعادة المحاولة. باستخدام 6TiSCH ، يمكنك إعادة إرسال إطار في خلية أخرى ، الأمر الذي يتطلب هذا النوع من المعلومات. وبالتالي ، فإن قواعد OpenWSN تستند إلى مجموعة ميزات جهاز راديو محدودة وتنفذ جميع مكونات MAC الأخرى في البرنامج.

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