الخلاصة

  • RFC 9699 وثيقة معلوماتية عن حالة استخدام، وليست معيار أداء أو تقرير نجاح لتشغيل تجاري.
  • المسافة الأقصر لا تلغي انتظار النفاذ اللاسلكي أو طابور المعالجة، والطلب المتقطع يجعل المتوسط وحده غير كاف.
  • ينبغي أن تشمل أدلة القبول المهام المتأخرة والمفقودة والتشغيل المخفض، مع تحديد عبء العمل ومسؤولية كل طرف.

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

هنا تكمن أهمية RFC 9699، الصادر في ديسمبر 2024. تعرض الوثيقة حالة استخدام للواقع الممتد على بنية حوسبة طرفية، وتستعين بمشهد توضيحي لزوار برج لندن. تصنيفها Informational، لا Standards Track؛ فلا يجوز تحويل المشهد إلى مشروع منشور بالفعل، أو تحويل رقم الوثيقة إلى شهادة بأن تجربة المستخدم اجتازت الاختبار.

الطلب مرتبط بما يراه المستخدم ويفعله

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

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

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

أي تأخير تقيسه الأرقام؟

تستشهد الوثيقة بهدف قدره 20 ملي ثانية، وبنطاق أفضل من 7 إلى 15 ملي ثانية. وفي مثال لتوزيع الميزانية الزمنية، تستغرق الشاشة نحو 12 إلى 13 ملي ثانية. هذه أرقام تصميم مستندة إلى مراجع الوثيقة، وليست حدا طبيا عالميا أو قياسا لجميع النظارات المعاصرة. وتناقش الوثيقة أيضا زمن استجابة الخادم؛ وهو ليس مرادفا للمدة من حركة الرأس إلى ظهور النتيجة.

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

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

أين تنتهي مسؤولية النقل؟

توفر آليات الشبكة ضمانات ضمن شروطها، لا خارجها. يضع RFC 8655 الخاص بمعمارية DetNet العمل داخل نطاق إداري واحد أو مجموعة مغلقة من النطاقات المتعاونة، وليس عبر أي مسار على الإنترنت. وحتى حين يلتزم النقل بحدوده، لا يكون بذلك قد أثبت زمن انتظار وحدة الرسوم أو دقة المحاذاة أو سلوك الشاشة.

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

إذن، يمكن للحوسبة القريبة أن تكون مفيدة، لكن النتيجة القابلة للدفاع تحتاج إلى شروط معلنة: أجهزة محددة، ومزيج مهام معلوم، وتوزيع للفشل، ووقت استخدام صالح فعلا. يبين RFC 9699 لماذا يستحق السؤال البحث، ولا يقدم جوابا تجاريا جاهزا.