The definition

التعريف

Every service (pipeline) must answer within a threshold called τ (tau). τ is the maximum acceptable end-to-end response time. The latency budget of the application is the interval [0, τ], and a mapping is feasible only when its response time fits inside it.

كل خدمة (pipeline) يجب أن تُجيب ضمن عتبة تُسمّى τ (تاو). وτ هي أقصى زمن استجابة مقبول من الطرف إلى الطرف (end-to-end). وميزانية التأخير (latency budget) للتطبيق هي الفترة [0, τ]، ولا يكون الـ mapping ممكناً إلا إذا وقع زمن استجابته داخلها.

Compare RT with τ, not one latency arrow. Slide 72 draws small, medium and large latency from the client to the edge, fog and cloud, but each arrow is one-way and leaves out processing. The trip out, the processing and the trip back all spend the budget. When the pipeline crosses several layers, every hop and every task's PT join the sum.

قارن RT مع τ، لا سهم تأخير واحداً. ترسم الشريحة 72 تأخيراً صغيراً ومتوسطاً وكبيراً من العميل إلى edge وfog وcloud، لكن كل سهم في اتجاه واحد ولا يشمل المعالجة. رحلة الذهاب والمعالجة ورحلة العودة كلها تستهلك من الميزانية. وعندما تعبر السلسلة عدة طبقات، تنضمّ كل قفزة وكل PT لكل مهمة إلى المجموع.

budget: τ = 100 ms

fog    RT = 20 + 70 + 20  = 110 ms    110 > 100   FAILS by 10
edge   RT =  5 + 70 +  5  =  80 ms     80 ≤ 100   PASSES
cloud  RT = 70 + 20 + 70  = 160 ms    160 > 100   FAILS
       best case PT = 0:  70 + 0 + 70 = 140 ms   still FAILS
       -> only moving closer helps, not a faster server

caution: edge boxes are small. if edge PT grows to 95 ms:
edge   RT =  5 + 95 +  5  = 105 ms   FAILS

Where τ comes from

من أين تأتي τ

τ is set by people and physics, not by the network or the hardware you own. The network and servers only decide how much of the budget you spend. Never invent τ: published studies give defensible numbers spanning four orders of magnitude.

تُحدَّد τ من خلال البشر والفيزياء، لا من خلال الشبكة أو العتاد الذي تملكه. فالشبكة والخوادم تقرّر فقط كم تُنفق من الميزانية. لا تخترع τ أبداً: الدراسات المنشورة تعطي أرقاماً يمكن الدفاع عنها، تمتد عبر أربع مراتب عشرية.

يجمع الجدول قيم τ المنشورة من الأشد إلى الأرخى: نظارات الواقع الممتد (XR) تحتاج زمن motion-to-photon لا يتجاوز 20 ms (والمفضّل من 7 إلى 15 ms، حسب RFC 9699). والمحادثة تحتاج تأخيراً في اتجاه واحد أقل من 150 ms مع سقف 400 ms (ITU-T G.114). وتفاعل الويب يُعدّ جيداً إذا كان INP ≤ 200 ms عند المئين p75. والتعرّف على الوجوه عبر الأجهزة القابلة للارتداء من 370 إلى 1000 ms، والإرشاد خطوة بخطوة 600 ms كحدّ ضيق و2.7 s كحدّ واسع (Chen et al. 2017). ويحافظ المستخدم على انتباهه نحو 10 s (Nielsen).

Check at a percentile, not the mean

افحص عند مئين، لا عند المتوسط

A budget is a promise about what users experience, and users remember the slow requests. So published budgets are stated at a percentile: web.dev rates an interaction good only when 75% of visits are within 200 ms (p75), and Chen et al. judge wearable assistants at the 90th percentile (p90).

الميزانية وعدٌ بما يعيشه المستخدمون، والمستخدمون يتذكرون الطلبات البطيئة. لذلك تُذكر الميزانيات المنشورة عند مئين (percentile): فـ web.dev يعدّ التفاعل جيداً فقط إذا كانت 75% من الزيارات ضمن 200 ms (p75)، وChen et al. يقيّمون المساعدات القابلة للارتداء عند المئين التسعين (p90).

τ = 200 ms, ten measured response times (sorted, ms):
  80  90  90  100  100  110  120  150  260  300

mean = 1400 / 10            = 140 ms    ≤ 200   looks fine
p75  = value #ceil(0.75x10) = #8 = 150  ≤ 200   passes
p90  = value #ceil(0.90x10) = #9 = 260  > 200   FAILS

two users in ten wait longer than τ. the mean hides them.

The four-step design method

طريقة التصميم ذات الخطوات الأربع

Design questions have no single right answer, but they have a right method, and it is the same four steps every time.

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

1. List the tasks of the service pipeline.

   اسرد المهام في سلسلة الخدمة (pipeline).

2. Set τ per task, from a published source, not one τ for the whole app.

   حدّد τ لكل مهمة من مصدر منشور، لا τ واحدة للتطبيق كله.

3. Place each task on device, edge, fog or cloud (the mapping).

   ضع كل مهمة على الجهاز أو edge أو fog أو cloud (أي الـ mapping).

4. Check RT ≤ τ and the trade-offs: battery, privacy, reach, cost.

   تحقّق من RT ≤ τ ومن المقايضات: البطارية، والخصوصية، والنطاق، والتكلفة.

Design exercise 1: smart glasses (slide 73)

تمرين التصميم 1: النظارات الذكية (الشريحة 73)

في النظارات الذكية: الالتقاط وتصغير الإطار وعرض الطبقة المرئية (overlay) تبقى على النظارات لأن حلقة العرض نحو 20 ms ولا تتسع لرحلة شبكة. والتعرّف على الوجوه والإرشاد يُنقلان (offloading) إلى cloudlet حافة قريب، لأن ميزانيتهما من 370 ms إلى 2.7 s. والتخزين والتحليلات وإعادة التدريب تذهب إلى السحابة لأنها بلا موعد تفاعلي.

Step 4 for the glasses: offloading to the edge saves battery (30 to 40% less energy with cloudlets, Ha et al. via Shi et al.) and keeps raw data private (faces never reach a public cloud). The price is network dependence: the glasses need a working wireless link and an edge site wherever the wearer walks. In Chen et al., cloud offload added roughly 100 to 200 ms compared with a cloudlet.

الخطوة 4 للنظارات: النقل إلى الحافة يوفّر البطارية (طاقة أقل بنسبة 30 إلى 40% مع cloudlets، حسب Ha et al. كما لخّصهم Shi et al.) ويُبقي البيانات الخام خاصة (الوجوه لا تصل إلى سحابة عامة). والثمن هو الاعتماد على الشبكة: تحتاج النظارات اتصالاً لاسلكياً يعمل وموقع حافة أينما ذهب مرتديها. وفي Chen et al.، أضاف النقل إلى السحابة نحو 100 إلى 200 ms مقارنة بـ cloudlet.

Design exercises 2 and 3: AR and VR (slides 74–75)

تمرينا التصميم 2 و3: AR وVR (الشريحتان 74–75)

One app, many deadlines. Motion-to-photon (MTP) is the time from a head or device movement to the matching light leaving the display. RFC 9699 gives at most 20 ms, of which the display takes about 12 to 13 ms, leaving only 7 to 8 ms for sensing, rendering and any round trip. Ideal 4G loopback alone is about 25 ms, so per-frame work cannot depend on a remote round trip.

تطبيق واحد ومواعيد كثيرة. زمن motion-to-photon (MTP) هو الزمن من حركة الرأس أو الجهاز حتى خروج الضوء المطابق من الشاشة. يحدّه RFC 9699 بـ 20 ms على الأكثر، تأخذ الشاشة منها نحو 12 إلى 13 ms، فلا يبقى إلا 7 إلى 8 ms للاستشعار والعرض وأي رحلة ذهاب وإياب. وزمن 4G المثالي وحده نحو 25 ms، فلا يمكن أن يعتمد العمل لكل إطار على رحلة بعيدة.

Slide 76 gives the lecturer's short answers: smart glasses use the edge for low-latency recognition and the cloud for storage and complex computation; industrial AR uses the edge for real-time sensor interaction and the cloud for large datasets and analytics; VR headsets use the edge for frame rendering and the cloud for large datasets. The captions leave out the device layer, which in reality runs tracking and display.

تعطي الشريحة 76 إجابات المحاضر المختصرة: النظارات الذكية تستخدم edge للتعرّف منخفض التأخير وcloud للتخزين والحسابات المعقدة، والواقع المعزّز الصناعي يستخدم edge للتفاعل اللحظي مع الحساسات وcloud للبيانات الضخمة والتحليلات، ونظارات VR تستخدم edge لعرض الإطارات وcloud للبيانات الضخمة. وتُسقط هذه التعليقات طبقة الجهاز، التي تشغّل في الواقع التتبّع والعرض.

The summary (slide 77)

الخلاصة (الشريحة 77)

Before, you architected an application on one layer only, the server layer. Because we live in the Data, IoT and ML era, the server now has to span the E2C continuum. For every service, each task in the pipeline is individually mapped to a layer. And response time is the main criterion guiding the design: RT = f(Latency, PT), concretely the sum of every hop's latency plus every task's processing time.

في السابق كنت تصمّم التطبيق على طبقة واحدة فقط هي طبقة الخادم. ولأننا نعيش في عصر البيانات وإنترنت الأشياء وتعلّم الآلة (Data/IoT/ML)، صار على الخادم أن يمتد على E2C continuum. ولكل خدمة، تُوضع كل مهمة في السلسلة على حدة على طبقة. وزمن الاستجابة هو المعيار الأساسي الذي يوجّه التصميم: RT = f(Latency, PT)، أي عملياً مجموع تأخير كل قفزة زائد زمن معالجة كل مهمة.