ব্যান্ডউইডথ, থ্রুপুট, ল্যাটেন্সি ও জিটার ব্যাখ্যা
বহনক্ষমতা, মাপা স্থানান্তরের হার, বিলম্ব ও তার পরিবর্তন আলাদা প্রশ্নের উত্তর দেয়। বাফারিংয়ের জন্য একটি সংখ্যাকে দোষ দেওয়ার আগে পূর্ণ নেটওয়ার্ক তুলনা বুঝুন।
সংক্ষেপে: ব্যান্ডউইডথ উপলব্ধ বা নামমাত্র বহনক্ষমতার ধারণা; থ্রুপুট নির্দিষ্ট পরীক্ষায় মাপা উপযোগী ডেটার হার। ল্যাটেন্সি হলো বিলম্ব, আর জিটার নির্দিষ্ট পদ্ধতিতে বিলম্বের পরিবর্তন বোঝায়। প্যাকেট হারানো আবার আলাদা বিষয়। ভিডিও এক বা একাধিক বিষয়ে প্রভাবিত হতে পারে, তাই সংখ্যার অর্থ করার আগে পদ্ধতি ও পথ লিখে রাখুন।
প্রতিটি মাপ আংশিক চিত্র দেয়। একই একক হলেও দুটি পরীক্ষা ভিন্ন প্রান্তবিন্দু, প্রোটোকল, দিক, সময়কাল, পথ বা ট্র্যাফিক পরিস্থিতি মাপতে পারে।
ব্যান্ডউইডথ বাস্তবে পৌঁছানো ডেটার ফল নয়
ব্যান্ডউইডথকে অনেকে গতির সংক্ষিপ্ত নাম হিসেবে ব্যবহার করেন, কিন্তু বহনক্ষমতার লেবেল বলে না নির্দিষ্ট সময়ে অ্যাপের কত ডেটা পৌঁছেছে। ভাগ করা লিংক, প্রোটোকলের অতিরিক্ত ডেটা, ভিড়, রেডিওর অবস্থা, ডিভাইসের সীমা ও দূরের প্রান্তবিন্দু পর্যবেক্ষিত থ্রুপুট কমাতে পারে।
তাই প্ল্যানের হার, Wi-Fi লিংকের হার, Ethernet লেবেল ও অ্যাপের থ্রুপুট আলাদা মান। অন্যটির সঙ্গে তুলনা করার আগে স্ক্রিনে কোনটি দেখাচ্ছে তা লিখুন।
থ্রুপুটের পরীক্ষার পরিসর দরকার
থ্রুপুট হলো মাপা স্থানান্তরের হার। RFC 6349 TCP থ্রুপুট পরীক্ষার কাঠামো বর্ণনা করে এবং পরীক্ষার পদ্ধতির ওপর জোর দেয়। ফলের সঙ্গে প্রান্তবিন্দু, দিক, প্রোটোকল, সময়কাল, সংযোগের সংখ্যা, ডিভাইস, পথ ও সময় থাকা দরকার।
বাড়ির নেটওয়ার্কের বুনিয়াদি নির্দেশিকা (ইংরেজিতে) ডিভাইস ও উৎসের মধ্যকার পথ দেখায়। কাছের পরীক্ষার সার্ভার প্রতিটি অনুমোদিত উৎসের পথ পুনরায় তৈরি করে না, আর ক্ষণিকের সর্বোচ্চ হারকে অ্যাপের ধারাবাহিক কর্মক্ষমতা হিসেবে দেখানো উচিত নয়।
ল্যাটেন্সি হলো অতিক্রান্ত বিলম্ব
মাপা পথে ডেটা বা সাড়া যেতে কত সময় লাগে তা ল্যাটেন্সি বর্ণনা করে। RFC 7679-এর পদ্ধতিতে একমুখী বিলম্বের জন্য ঘড়ির সমলয় এবং সময় মাপার অনিশ্চয়তার হিসাব দরকার; অনেক ভোক্তা টুল তার বদলে যাওয়া-আসার সময় দেখায়। এ ফলগুলো একটির জায়গায় অন্যটি ব্যবহার করা যায় না।
ভিডিও শুরু, নিয়ন্ত্রণ, প্রমাণীকরণ ও সেগমেন্টের অনুরোধ ভিন্ন কারণে দ্রুত বা ধীর মনে হতে পারে। বেশি থ্রুপুটের ফল মানেই কম ল্যাটেন্সি নয়।
জিটার হলো পরিবর্তন, শুধু ধীরতা নয়
RFC 3393 প্যাকেটের বিলম্বের পরিবর্তনের মাপ সংজ্ঞায়িত করে। দৈনন্দিন টুলে “জিটার” ভিন্ন গণনা, দিক, সময়সীমা বা পরিসংখ্যান ব্যবহার করতে পারে। মান তুলনার আগে টুলের সংজ্ঞা পড়ুন।
সংযোগে গড় থ্রুপুট যথেষ্ট হলেও প্যাকেট অনিয়মিতভাবে পৌঁছাতে পারে, অথবা বিলম্ব স্থির হলেও ধারাবাহিক থ্রুপুট অপর্যাপ্ত হতে পারে। স্থির 80 ms যাওয়া-আসার সময় এবং 20 ও 140 ms-এর মধ্যে পালাক্রমে বদলানো সময়ের গড় একই হলেও আচরণ আলাদা হতে পারে। উদাহরণটি পরিবর্তন বোঝায়, জিটারের সূত্র বা গ্রহণযোগ্য সীমা নয়।
প্যাকেট হারানো আরেকটি মাত্রা
RFC 7680 স্পষ্ট পদ্ধতিসহ একমুখী প্যাকেট হারানোর মাপ সংজ্ঞায়িত করে। ভোক্তা টুলের ফল তার বদলে অনুপস্থিত সাড়া থেকে প্যাকেট হারানো অনুমান করতে পারে, এবং কিছু ডিভাইস সমস্যা নির্ণয়ের ট্র্যাফিককে কম অগ্রাধিকার দিতে পারে। শূন্য ফল মানে অ্যাপের প্রতিটি প্যাকেট পৌঁছেছে—এমন প্রমাণ নয়; শূন্যের বেশি ফলের ক্ষেত্রে পুনরাবৃত্তি ও পরিসর দরকার।
নোটে হারানো ও দেরিতে আসা প্যাকেট আলাদা রাখুন। প্লেব্যাকের বিরতি দৃশ্যমান লক্ষণ, প্যাকেট-স্তরের সমস্যা নির্ণয় নয়।
মৌলিক প্রমাণ: মাপের অভিধান
| মাপ | সহজ ভাষার প্রশ্ন | প্রয়োজনীয় পরিসর | একা কী প্রমাণ করতে পারে না |
|---|---|---|---|
| ব্যান্ডউইডথ/বহনক্ষমতা | সংজ্ঞা অনুযায়ী এই লিংক কত বহন করতে পারে? | লিংক, লেবেল, দিক | অ্যাপে ডেটা পৌঁছানো |
| থ্রুপুট | কী উপযোগী হার মাপা হয়েছে? | প্রান্তবিন্দু, প্রোটোকল, সময়কাল, পথ | প্রতিটি উৎসের পথ |
| ল্যাটেন্সি | পদ্ধতিতে কত বিলম্ব দেখা গেছে? | একমুখী/যাওয়া-আসা, ঘড়ি, পথ | ধারাবাহিক বহনক্ষমতা |
| জিটার | বিলম্ব কীভাবে বদলেছে? | সূত্র, নমুনা, পরিসংখ্যান | গড় থ্রুপুট |
| প্যাকেট হারানো | কোন প্রত্যাশিত প্যাকেট অনুপস্থিত ছিল? | পরীক্ষামূলক বার্তার ধরন, দিক, সময়সীমা | প্লেব্যাকের সঠিক কারণ |
প্রতিটি মানের একক দিন এবং গোপনীয়তা অনুমতি দিলে মূল ফল সংরক্ষণ করুন।
সমাধানসহ উদাহরণ: দ্রুত প্ল্যান, কিন্তু অনিয়মিত সন্ধ্যা
এগুলো শেখানোর জন্য কাল্পনিক ফল, Norva বা কোনো উৎসের পরীক্ষা নয়। একটি পরিবারের প্ল্যানের লেবেল 100 Mbps। তারা একই ল্যাপটপ একই Wi-Fi অবস্থানে রেখে একই কাছের প্রান্তবিন্দুতে পরীক্ষা করে; ডাউনলোডের সেটিং একই এবং প্রতিটি সময়পর্বে 30 সেকেন্ডের তিনটি পরীক্ষা চলে।
| পর্যবেক্ষণ | কম ব্যস্ত সময় | ব্যস্ত সময় | ব্যাখ্যা |
|---|---|---|---|
| ডাউনলোড থ্রুপুট, তিনটি পরীক্ষা | 82, 80, 84 Mbps | 28, 14, 31 Mbps | মধ্যক 82 থেকে 28 Mbps-এ নামে; ব্যস্ত সময়ের পরিসর 14–31 Mbps |
| একই লোডের অবস্থায় টুলের রিপোর্ট করা যাওয়া-আসার বিলম্বের মধ্যক | 18 ms | 65 ms | পরীক্ষার এই পথ ব্যস্ত সময়ে বেশি ধীরে সাড়া দেয় |
| টুলের প্রদর্শিত জিটার, একই সূত্র ও নমুনা নেওয়ার সেটিং | 3 ms | 24 ms | এই টুলের সংজ্ঞায় বিলম্ব বেশি বদলায়; এটি পাশ/ফেলের নম্বর নয় |
| ব্যস্ত সময়ে অনুমোদিত ভিডিও | পরীক্ষা করা হয়নি | দুটি বিরতি নথিবদ্ধ | খারাপ ফলের সঙ্গে বিরতি ঘটেছে, কিন্তু ভিডিওর প্রান্তবিন্দু মাপা হয়নি |
যুক্তিযুক্ত পরবর্তী ধাপ হলো লক্ষণের সময় আবার পরীক্ষা করা; সমর্থিত হলে চাইলে শুধু স্থানীয় সংযোগ Ethernet-এ বদলানো যায়। সঙ্গে সঙ্গে দ্রুততর প্ল্যান কেনা নয়। এমনকি 14 Mbps নমুনা দিয়েও ভিডিও চলার কথা কি না প্রমাণ করা যায় না: সংস্করণের প্রকৃত চাহিদা, ছোট পতন, উৎসের পথ ও বাফারিংয়ের আচরণ অজানা।
Mbps (মেগাবিট প্রতি সেকেন্ড) ও MB/s (মেগাবাইট প্রতি সেকেন্ড) আলাদা রাখুন: পরীক্ষায় অতিরিক্ত ডেটার সংজ্ঞার হিসাবের আগে 8 Mbps সমান 1 MB/s। মিলিসেকেন্ড সময় বোঝায়, ডেটার হার নয়। এই এককগুলো এমনভাবে তুলনা করা যায় না যেন বড় সংখ্যা মানেই ভালো সংযোগ।
ছোট একটি মাপের সেট তৈরি করুন
সমস্যা হওয়া ডিভাইসটি স্বাভাবিক স্থানে ব্যবহার করুন। কম ব্যস্ত সময়ে বিরতি দিয়ে তিনটি নমুনা এবং লক্ষণের সময় তিনটি নমুনা লিখুন। নিরাপদ ও সমর্থিত হলে প্রান্তবিন্দু বা পরীক্ষার সেটিং না বদলে একটি বিকল্প স্থানীয় লিংকে আবার পরীক্ষা করুন।
তারপর সেরা সংখ্যা বেছে না নিয়ে মধ্যক, পরিসর ও পুনরাবৃত্তি তুলনা করুন। একই সময়ের আপলোড, মেশের পরিবর্তন, ডিভাইসের বিদ্যুৎ-সংক্রান্ত অবস্থা ও আবহাওয়া সরাসরি দেখা গেলেই শুধু লিখুন; কাকতালীয় ঘটনার চারপাশে কারণের গল্প বানাবেন না।
মিলিত ফল ব্যাখ্যা করুন
কম ধারাবাহিক থ্রুপুট প্লেব্যাকের বাফার খালি করতে পারে। স্বল্পমেয়াদি গড় হার যথেষ্ট দেখালেও বিলম্বের পরিবর্তন ও প্যাকেট হারানো ডেটা সরবরাহে ব্যাঘাত ঘটাতে পারে। বেশি ল্যাটেন্সি দীর্ঘ স্থানান্তরকে বাধ্যতামূলকভাবে সীমিত না করেও অনুরোধ-সাড়ার ধারা ধীর করতে পারে। অ্যাপ, পরিবহন প্রোটোকলের আচরণ, বাফারিংয়ের নকশা ও উৎস দৃশ্যমান প্রভাব নির্ধারণ করে।
প্লেব্যাক চলতে থাকলেও ছবি খারাপ দেখালে ঝাপসাকে ধীর নেটওয়ার্কের প্রমাণ না ধরে ছবির মানের তুলনা ব্যবহার করুন। Norva সামঞ্জস্যপূর্ণ অনুমোদিত উৎস চালায়; এটি ক্যাটালগ দেয় না বা আপনার রাউটার, উৎসের পথ কিংবা তার এনকোডিং নিয়ন্ত্রণ করে না।
ব্যাখ্যার সাধারণ ভুল
বিটের সঙ্গে বাইট তুলনা করবেন না, লিংকের হারকে থ্রুপুট ভাববেন না, বিলম্বের সব পরিবর্তনকে “প্যাকেট হারানো” বলবেন না, বা একটি সার্ভারের ফলকে নিশ্চয়তা ধরবেন না। রাউটার, ডিভাইস ও উৎস একসঙ্গে বদলানোর পরেই কেবল মাপা এড়িয়ে চলুন।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
ভিডিওর জন্য কোন মাপ সবচেয়ে গুরুত্বপূর্ণ?
কোনো একক মাপ সবসময় প্রধান নয়। সংস্করণের সরবরাহের ধরন, পথ, ডিভাইস ও লক্ষণ ঠিক করে কোন মাপ প্রাসঙ্গিক।
থ্রুপুট কি প্ল্যানের লেবেল ছাড়াতে পারে?
লেবেল, সরবরাহের ব্যবস্থা, পরীক্ষার পদ্ধতি, একক ও অতিরিক্ত ডেটার সংজ্ঞা ভিন্ন হয়। পার্থক্যকে ত্রুটি বলার আগে প্রতিটি সংখ্যা কী বোঝায় যাচাই করুন।
সব টুল কি একইভাবে জিটার মাপে?
না। টুলের সূত্র, দিক, পরীক্ষামূলক বার্তার ধরন, নমুনার সময়কাল ও রিপোর্ট করা পরিসংখ্যান দেখুন।
ভিডিও স্ট্রিমিংয়ের জন্য কত জিটার গ্রহণযোগ্য?
ভিডিও প্লেব্যাক নিশ্চিত করে এমন সর্বজনীন মিলিসেকেন্ড সীমা নেই। বাফার করা অন-ডিমান্ড ভিডিও ও কথোপকথনের কল বিলম্ব ভিন্নভাবে সহ্য করে; টুলও জিটার ভিন্নভাবে হিসাব করে। একই পদ্ধতির পুনরাবৃত্ত ফল প্রকৃত লক্ষণের সঙ্গে তুলনা করুন। একটি অ্যাপ বা প্রোটোকলের জন্য প্রকাশিত সীমা Norva-র সর্বজনীন শর্ত হওয়া উচিত নয়।
ভালো স্পিড টেস্টের পরেও ভিডিও বাফার করে কেন?
পরীক্ষা ভিন্ন সার্ভার, পথ, স্থানান্তরের ধরন বা সময়পর্ব ব্যবহার করতে পারে। ছোট ব্যাঘাত বাদ পড়তে পারে, আর প্লেব্যাক উৎস ও ডিভাইসের ওপরও নির্ভর করে। পরের পরীক্ষা বেছে নেওয়ার আগে লিখুন বিলম্ব প্রথম ফ্রেমের আগে নাকি প্লেব্যাকের মধ্যে হচ্ছে।
আপনার পরবর্তী পদক্ষেপ
প্লেব্যাকের লক্ষণ মিলিয়ে পরের যাচাই বেছে নিন (ইংরেজিতে)। সহায়তার অনুরোধে ডিভাইস, সময়পর্ব, পরীক্ষার পদ্ধতি ও একটি পুনরাবৃত্তিযোগ্য লক্ষণ দিন—উৎসের লগইনের গোপন তথ্য নয়।