ابتدا مقصد، نه یک حد قبولی همگانی
برای بازی سریع معمولاً زمان رفت‌وبرگشت پایین و پایدار تا سرور واقعی بازی بهتر است. جدول یک راهنمای تحریری برای مقایسه است، نه استاندارد رسمی یا تضمین یک بازی مشخص.
| زمان رفت‌وبرگشت | تفسیر تقریبی |
|---|---|
| کمتر از 50 ms | هدف تأخیر کم برای تعامل سریع. |
| 50–100 ms | ممکن است قابل بازی باشد؛ بازی و پایداری را بررسی کنید. |
| 100–150 ms | تأخیر ممکن است در بازی سریع محسوس‌تر شود. |
| بیشتر از 150 ms | معمولاً پاسخ کندتر، اما نه اثبات خرابی اتصال. |
جدول را شرط همگانی تماس یا ویدیو ندانید. تماس به نوسان، اتلاف و بافر هم وابسته است؛ ویدیوی بافری به ظرفیت و پایداری بستگی زیادی دارد. یک اندازه‌گیری مرورگر تجربه را تضمین نمی‌کند.
پینگ، تأخیر و پایداری
فرمان معمول ping از پژواک ICMP استفاده می‌کند. RTT رفت و برگشت را شامل می‌شود؛ نصف کردن آن تأخیر یک‌طرفه را قابل اعتماد تعیین نمی‌کند، چون مسیرها و صف‌ها ممکن است متفاوت باشند. Mbps ظرفیت است، نه همان تأخیر با واحد ms.
تغییر تأخیر اغلب jitter نامیده می‌شود و اتلاف بسته معیار دیگری است. مقصد و روش را هم ثبت کنید؛ ابزارها ممکن است آمار متفاوتی بسازند.
IPdidi واقعاً چه می‌سنجد؟
آزمون پینگ دو درخواست آماده‌سازی و سپس 40 اندازه‌گیری HTTP به /ping.txt در نقطه Cloudflare ارائه‌دهنده سایت انجام می‌دهد. ICMP نمی‌فرستد و سرور بازی را اندازه نمی‌گیرد.
معمولاً فاصله requestStart تا responseStart را می‌گیرد که ممکن است پردازش سرور را هم شامل شود. اگر در دسترس نباشد، زمان سپری‌شده fetch همراه با خواندن پاسخ استفاده می‌شود. RTT خالص شبکه تضمین نیست.
نوسان نمایش‌داده‌شده میانگین تغییر مطلق نمونه‌های موفق مجاور است. پایان مهلت یا خطای HTTP نمونه ناموفق است، نه درصد اتلاف بسته IP. امتیاز کاربردها قواعد تقریبی سایت‌اند. توضیح از بررسی کد است، نه آزمایش خط یا دستگاه شما.
شرایط یکسان را مقایسه کنید
- مقصد، ابزار، زمان، Wi-Fi یا کابل، VPN، میانگین، نوسان و خطاها را ثبت کنید.
- هنگام بی‌کاری و دانلود یا آپلود معمول، با همان مقصد و روش تکرار کنید.
- در صورت امکان Ethernet و Wi-Fi را مقایسه کنید؛ برای جداسازی اثر بی‌سیم مفید است، نه تضمین عدد کمتر.
- عیب‌یابی خود بازی یا برنامه تماس را ببینید. نتیجه خوب تا یک نقطه، مشکل محلی، مسیر، سرور یا برنامه در شرایط دیگر را رد نمی‌کند.
برای ICMP در پایانه ping example.com را اجرا و در صورت ادامه با Ctrl+C متوقف کنید. مقصد ممکن است پژواک را فیلتر کند؛ بی‌پاسخی به‌تنهایی توقف سرویس را ثابت نمی‌کند.
هر بار یک تغییر و اندازه‌گیری دوباره
- انتقال بزرگ و پشتیبان‌گیری را موقتاً متوقف کنید تا صف زیر بار بررسی شود.
- جای Wi-Fi و باند یا کانال خلوت‌تر را مقایسه کنید؛ 5 GHz پشت دیوار یا در فاصله زیاد همیشه بهتر نیست.
- منطقه مناسب بازی و VPN روشن/خاموش را در یک فعالیت مقایسه کنید. VPN یا طرح سریع‌تر تأخیر کمتر را تضمین نمی‌کند.
- اگر روتر مدیریت صف دارد، راهنمای رسمی را دنبال کنید؛ می‌تواند به صف کمک کند نه حذف فاصله انتشار.
- اگر مشکل ماند، مقصدها، زمان‌ها و نتایج بی‌کاری و زیر بار را به پشتیبانی بدهید، نه فقط کمترین عدد.
قبل و بعد از همان آزمون استفاده کنید و از اختلاف دو مقصد متفاوت به‌تنهایی علت نسازید.
پرسش‌های رایج
آیا 100 ms همیشه بد است؟
به کار، مقصد، پروتکل و پایداری بستگی دارد؛ عددی برای بررسی است، نه حد قبولی همگانی.
آیا خطای HTTP همان اتلاف بسته است؟
خیر. علت‌های مختلف دارد و این آزمون نرخ اتلاف شبکه را تعیین نمی‌کند.
چرا بازی عدد دیگری دارد؟
مقصد، ترافیک و پردازش متفاوت‌اند. عیب‌یابی خودش را مقایسه کنید، نه تفریق اندازه‌گیری‌های نامرتبط.
منابع و دامنه
این راهنما معیارها و روند مقایسه را توضیح می‌دهد و مدعی تشخیص خرابی اتصال شما یا آزمایش دستگاه خاصی نیست.
تاریخ بررسی منابع: 2026-11-05.