أسئلة RTT (زمن الاستجابة)

أُعيد استخدام لقطات الشاشة الأصلية من الوثائق الكورية. قد تختلف لغة الواجهة وأسماء القوائم في نسختك.

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

ما هو Ping؟

راجع وثيقة Ping أو التأخر (Lag) لشرح مفصل.

هل انخفاض متوسط زمن الاستجابة أفضل؟

نعم. كلما انخفض متوسط زمن الاستجابة، كان الاتصال أسرع.

هل انخفاض الانحراف المعياري لزمن الاستجابة أفضل؟

نعم. :-) كلما اقترب الانحراف المعياري من 0، دلّ ذلك على أن الاتصال مستقر جدًا.

أيهما أهم: المتوسط أم الانحراف المعياري؟

كلاهما مهم. إذا اعتبرنا المتوسط مقياسًا للسرعة، فالانحراف المعياري مؤشر لاستقرار الاتصال. إذا كنت تختار بين خادمي ترحيل بسرعتين متقاربتين وانحرافين مختلفين، فالأفضل هو الأقرب انحرافه المعياري إلى 0.

كيف أحصل على أسرع زمن استجابة؟

يعني ذلك العثور على مسار الإنترنت الذي يحقق أقل RTT بين «حاسوب المستخدم» و«خادم اللعبة» الوجهة. إذا كانت اللعبة مسجلة في Mudfish، فيمكن البحث عن أقصر مسار كما يلي:

1. (الشرح للإصدار v4) شغّل Launcher وجهّز عنصر اللعبة. يجب الوصول إلى لوحة التحكم عبر Launcher.
2. انقر على أيقونة اللعبة في لوحة التحكم.
3. في علامة تبويب «الإعدادات»، انقر على «الوضع المتقدم» لخادم الترحيل، ثم أيقونة العدسة المكبرة .
4. في النافذة المنبثقة، انقر على وجهة خادم اللعبة لعرض أقصر المسارات المحسوبة بواسطة Mudfish. ستوضح ما إذا كان المرور عبر خادم ترحيل واحد أسرع أم المرور عبر خادمين.

لمزيد من الطرق، راجع كيفية خفض RTT (زمن الاستجابة).

ما المقصود بخادم الترحيل ذي أفضل زمن استجابة؟

يشير تعبير «زمن استجابة جيد» عادة إلى خادم ترحيل يوفر مسارًا سريعًا عبر «حاسوب المستخدم → خادم الترحيل → خادم اللعبة». كما ذُكر، لا يعني ذلك زمن المقطع «حاسوب المستخدم ↔ خادم الترحيل» وحده، ولا مسار «خادم الترحيل ↔ خادم اللعبة» وحده.

للعثور على خادم ترحيل بأفضل زمن استجابة في Mudfish، يمكنك عادة الاستعانة بالنتائج التالية:

1. شغّل Launcher وجهّز عنصر اللعبة. يُنصح بالوصول إلى لوحة التحكم عبر Mudfish Launcher.
2. انقر على أيقونة اللعبة في لوحة التحكم.
3. في علامة تبويب «الإعدادات»، انقر على «الوضع الأساسي» لخادم الترحيل ثم أيقونة العدسة المكبرة . في النافذة المنبثقة، انقر على موقع خادم اللعبة المطلوب لعرض المخطط المحسوب ودرجات التقييم. عادة يكون الخادم المطلوب هو الأقل درجة.

زمن الاستجابة لم يتغير! يبدو أن Mudfish لا يؤثر فيه.

الأسئلة التالية تساعد على التشخيص الذاتي. تحقق أولًا مما إذا كنت قد جرّبت هذه الإجراءات.

السؤال	نعم	لا
هل تأكدت من التطبيق الصحيح باستخدام طريقة التحقق من التطبيق؟
1. هل تمر حركة اللعبة عبر Mudfish بصورة صحيحة؟ 1
2. هل اختيار خادم الترحيل مضبوط على «الاختيار التلقائي»؟ 2
3. هل جرّبت تغيير خادم الترحيل الحالي إلى خوادم أخرى؟ 3
4. هل جرّبت وضع ADN؟ 4
5. هل جرّبت وضع FastConnect؟ 5
6. هل تستخدم TCP حاليًا كبروتوكول اتصال؟ 6

لماذا يختلف RTT في المخطط المتوقع بالواجهة عن RTT الفعلي داخل اللعبة؟

قد يحدث هذا لأسباب متعددة:

1. اختلاف نطاق IP المستخدم لقياس RTT بين Mudfish واللعبة

   تقيس جميع خوادم ترحيل Mudfish دوريًا RTT إلى خوادم الألعاب وترسل النتائج إلى الخادم المركزي. لكن إذا كانت وجهة القياس، عادة عنوان IPv4، مختلفة عن الوجهة التي تقيسها اللعبة، فقد تختلف القيم.

   أحيانًا يحدد Mudfish وجهة خاطئة لقياس RTT، فيقيس موقعًا غير خادم اللعبة الفعلي وتحدث المشكلة.

2. اختلاف بروتوكول قياس RTT بين Mudfish واللعبة

   يقيس Mudfish RTT أساسًا باستخدام TCP. إذا كانت حركة اللعبة تعتمد على UDP بدلًا من TCP، فقد تختلف قيمة المخطط عن القيمة الفعلية؛ إذ قد تغيّر أجهزة QoS عادة أولوية معالجة الحزم.

3. تأثير حمل خادم اللعبة

   إذا كانت اللعبة تقيس RTT إلى الخادم الذي تُجرى عليه اللعبة فعليًا، فقد ينشأ اختلاف بسبب حمله.

   ذلك لأن مخطط RTT في Mudfish لا يقيس خادم اللعبة الفعلي، بل الشبكة التي يوجد فيها أو شبكة يُعتقد أنها قريبة منه.

4. تأثير حمل الشبكة التي يوجد فيها خادم اللعبة

   إذا كانت شبكة خادم اللعبة تعاني حملًا بسبب كثرة الحركة، ولم يكن Mudfish يقيس RTT إلى ذلك الجزء نفسه من الشبكة، فقد تختلف المخططات.

5. الحمل على الحاسوب المستخدم نفسه

   في حالات نادرة، قد يبطئ الحمل الناتج عن تشغيل اللعبة معالجة نظام التشغيل عمومًا، فينشأ اختلاف في RTT.

يظهر المخطط الآني أحيانًا القيمة 3000.

تعني قيمة 3000 ms في Mudfish فقدان حزم. أي إن اختبار زمن الاستجابة عبر خادم الترحيل أدى إلى فقدان حزم لسبب ما. توجد أسباب متعددة، وأكثرها شيوعًا:

• مشكلة في اتصال الإنترنت الحالي (ISP).

  في هذه الحالة، ستلاحظ مشكلات RTT مع خوادم ترحيل كثيرة في قائمة «الحالة → خوادم الترحيل». إذا لم تظهر المشكلة مع خوادم متعددة، فقد لا يكون اتصال الإنترنت هو السبب.

• مشكلة في خادم الترحيل المستخدم.

  جرّب تغيير خادم الترحيل.

• مشكلة في شبكة خادم اللعبة.

جميع قيم زمن الاستجابة هي 3000

تحدث المشكلة عادة لأن 1) جدار حماية في بيئة الشبكة يمنع قياس RTT بين «المستخدم ↔ خادم الترحيل»، أو 2) مشكلة في خادم Mudfish تمنع قياس RTT بين «خادم الترحيل ↔ خادم اللعبة».

إذا رجّحت السبب 1، فجرّب التالي:

• افتح «الإعدادات → البرنامج» في واجهة Mudfish، وابحث عن «طريقة فحص RTT». غيّرها إلى خيار مختلف من ICMP أو TCP أو UDP، ثم أعد تشغيل Mudfish.

  

إذا رجّحت السبب 2، فاترك منشورًا في منتدى Mudfish لكي نتمكن من إصلاحه.

Footnotes

1. يجب فحص ذلك إذا لم يتغير زمن الاستجابة إطلاقًا رغم تشغيل Mudfish. أثناء اللعب، تحقق مما إذا كان مخطط «حركة البيانات الآنية» في لوحة التحكم يتحرك أم يبقى ساكنًا. ↩

2. إذا كان مضبوطًا على «الاختيار التلقائي»، فاختر خادم ترحيل آخر يدويًا واختبره. ↩

3. قد تكون حالة شبكة خادم الترحيل المستخدم سيئة مؤقتًا. ↩

4. إذا تعذر تجاوز مقطع ازدحام الشبكة عبر خادم ترحيل 1، فيمكن استخدام وضع ADN للمرور عبر خادمي ترحيل 2. ↩

5. إذا كانت اللعبة نفسها تعتمد على TCP، فمن المفيد تجربة FastConnect. ↩

6. إذا كان UDP الافتراضي يعمل دون مشكلات، فلا يوجد '''أي''' سبب لاستخدام TCP. ↩