লিনাক্স / বিএসডি-তে এইচএফএসসি শিডিউলিং কীভাবে কাজ করে তা কি কেউ সত্যই বুঝতে পারে?


35

আমি এইচএফএসসি সম্পর্কে মূল সিগকম '97 পোস্টস্ক্রিপ্ট কাগজটি পড়েছি, এটি খুব প্রযুক্তিগত, তবে আমি মূল ধারণাটি বুঝতে পারি। রৈখিক পরিষেবা বক্ররেখা দেওয়ার পরিবর্তে (প্রতিটি অন্যান্য সময়সূচী অ্যালগরিদমের মতো), আপনি একটি উত্তল বা অবতল পরিষেবা বক্ররেখাকে নির্দিষ্ট করতে পারেন এবং এভাবে ব্যান্ডউইথ এবং বিলম্বকে ডিকুয়াল করা সম্ভব। তবে, যদিও এই কাগজটিতে ধরণের সময়সূচী অ্যালগরিদমগুলি ব্যবহৃত হচ্ছে (আসল-সময় এবং লিঙ্ক-ভাগ) উল্লেখ করা হয়েছে, তবুও এটি সর্বদা কেবল নির্ধারিত বর্গের জন্য এক বক্ররেখার উল্লেখ করে (ডুউপলিংটি এই বক্ররেখা নির্দিষ্ট করেই করা হয়, তার জন্য কেবল একটি বক্ররেখা প্রয়োজন )।

এখন এইচএফএসসি বিএসডি (ওপেনবিএসডি, ফ্রিবিএসডি, ইত্যাদি) ALTQ সময়সূচী কাঠামো ব্যবহার করে প্রয়োগ করা হয়েছে এবং এটি টিসি শিডিউলিং ফ্রেমওয়ার্ক (আইপ্রউট 2 এর অংশ) ব্যবহার করে লিনাক্স প্রয়োগ করা হয়েছে । উভয় বাস্তবায়নে দুটি অতিরিক্ত পরিষেবা বক্ররেখা যুক্ত হয়েছিল, যা মূল কাগজে ছিল না ! একটি রিয়েল-টাইম পরিষেবা বক্ররেখা এবং একটি উচ্চ-সীমা পরিষেবা বক্রতা। আবার, দয়া করে নোট করুন যে মূল কাগজটিতে দুটি শিডিংয়ের অ্যালগোরিদম (রিয়েল-টাইম এবং লিঙ্ক-ভাগ) উল্লেখ করা হয় তবে সেই কাগজে উভয়ই একক পরিষেবা বক্ররেখা নিয়ে কাজ করে। আপনি বর্তমানে বিএসডি এবং লিনাক্সের হিসাবে সন্ধানের জন্য দু'জনের জন্য দুটি স্বতন্ত্র পরিষেবা বক্ররেখা কখনও হয়নি।

আরও খারাপ, ALTQ- র কিছু সংস্করণ HSFC- এ একটি অতিরিক্ত সারি অগ্রাধিকার যুক্ত করেছে বলে মনে হয় (মূল কাগজে অগ্রাধিকারের মতো কোনও বিষয় নেই)। আমি বেশ কয়েকটি বিএসডি হাওটো'র এই অগ্রাধিকার সেটিংসের উল্লেখ করে দেখতে পেলাম (যদিও সর্বশেষ ALTQ রিলিজের ম্যান পেজ এইচএসএফসি-র জন্য এই জাতীয় কোনও পরামিতি জানে না, তাই আনুষ্ঠানিকভাবে এটি উপস্থিতও নেই)।

এটি সমস্তই মূল কাগজে বর্ণিত অ্যালগরিদমের চেয়ে এইচএফএসসির সময়সূচীটিকে আরও জটিল করে তোলে এবং ইন্টারনেটে প্রচুর সংখ্যক টিউটোরিয়াল রয়েছে যা প্রায়শই একে অপরের সাথে বিরোধিতা করে, একজন অন্যটির বিপরীতে দাবি করে। এইচএফএসসি শিডিয়ুলিং কীভাবে কাজ করে তা সত্যিই কেউ বুঝতে চায়নি বলে সম্ভবত এটিই প্রধান কারণ। আমার প্রশ্ন জিজ্ঞাসা করার আগে আমাদের কোনও ধরণের নমুনা সেটআপ দরকার। নীচের চিত্রটিতে দেখা হিসাবে আমি একটি খুব সাধারণ ব্যবহার করব:

Alt পাঠ্য http://f.imagehost.org/0177/hfsc-test-setup.png

এখানে কিছু প্রশ্নের উত্তর আমি দিতে পারি না কারণ টিউটোরিয়ালগুলি একে অপরের বিরোধিতা করে:

  1. আমার আদৌ কি রিয়েল-টাইম বক্ররেখা প্রয়োজন? ধরে নিলাম এ 1, এ 2, বি 1, বি 2 সবগুলিই 128 কেবিট / সে লিংক শেয়ার (কোনও একটির জন্য রিয়েল-টাইম কার্ভ নয়), তবে এর প্রত্যেকটি 128 কেবিট / গুলি পাবে যদি মূলটি বিতরণ করার জন্য 512 কেবিট / গুলি থাকে (এবং এ এবং বি উভয়ই অবশ্যই 256 কেবিট / সেকেন্ড), ঠিক আছে? আমি কেন অতিরিক্তভাবে এ 1 এবং বি 1 কে 128 কেবিট / এস সহ একটি রিয়েল-টাইম বক্ররেখা দেব? এটি কি জন্য ভাল হবে? এই দুটি উচ্চতর অগ্রাধিকার দিতে? মূল কাগজ অনুসারে আমি তাদের বক্ররেখা ব্যবহার করে একটি উচ্চ অগ্রাধিকার দিতে পারি , এইচএফএসসি সর্বোপরি যা আছে। উভয় শ্রেণিকে একটি বক্ররেখা প্রদান করে [256kbit / s 20ms 128kbit / s] উভয়ই স্বয়ংক্রিয়ভাবে A2 এবং B2 এর চেয়ে দ্বিগুণ অগ্রাধিকার পেয়েছে (এখনও কেবলমাত্র 128 কেবিট / সেকেন্ডে প্রাপ্ত)

  2. রিয়েল-টাইম ব্যান্ডউইদথটি লিংক-শেয়ার ব্যান্ডউইথের দিকে গুনতে পারে? উদাহরণস্বরূপ, যদি এ 1 এবং বি 1 উভয়টিরই কেবলমাত্র 64kbit / s রিয়েল-টাইম এবং 64kbit / s লিংক-শেয়ার ব্যান্ডউইদথ থাকে, তার অর্থ কি একবার তারা রিয়েল-টাইমের মাধ্যমে 64kbit / s পরিবেশন করা হয়, তাদের লিঙ্ক-ভাগের প্রয়োজনীয়তাও ততই সন্তুষ্ট হয় (তারা সম্ভবত অতিরিক্ত ব্যান্ডউইথ পান, তবে এটি এক সেকেন্ডের জন্যও উপেক্ষা করতে দিন) বা এর অর্থ তারা লিংক-শেয়ারের মাধ্যমে আরও একটি 64 কেবিট / এস পাবে? তাহলে কি প্রতিটি শ্রেণীর রিয়েল-টাইম প্লাস লিংক-শেয়ারের একটি ব্যান্ডউইথ "প্রয়োজনীয়তা" রয়েছে? বা লিঙ্ক-ভাগের বক্ররেখার বাস্তব-সময়ের কার্ভের চেয়ে বেশি হলে কোনও শ্রেণীর কি কেবল রিয়েল-টাইম কার্ভের চেয়ে বেশি প্রয়োজন (বর্তমান লিঙ্ক-ভাগের প্রয়োজনীয়তা নির্দিষ্ট লিঙ্ক-ভাগের প্রয়োজনের বিয়োগের রিয়েল-টাইম ব্যান্ডউইথের জন্য ইতিমধ্যে সরবরাহ করা হয়েছে শ্রেণী)?

  3. উপরের সীমাটি বক্ররেখাগুলি কি রিয়েল-টাইম হিসাবেও প্রয়োগ করা হয়, কেবল লিংক-শেয়ারের জন্য, বা সম্ভবত উভয়ের ক্ষেত্রেই? কিছু টিউটোরিয়াল একটি উপায় বলে, কেউ কেউ অন্যভাবে বলে। কেউ কেউ দাবিও করেন যে রিয়েল-টাইম ব্যান্ডউইথ + লিংক-শেয়ার ব্যান্ডউইদথের জন্য সর্বোচ্চ-সীমা সর্বাধিক? সত্য কি?

  4. ধরে নিলাম এ 2 এবং বি 2 উভয়ই 128 কেবিট / সে, যদি এ 1 এবং বি 1 কেবল 128 কেবিট / স লিঙ্ক-শেয়ার হয় তবে বা 64 কেবিট / গুলি রিয়েল-টাইম এবং 128 কেবিট / গুলি লিঙ্ক-শেয়ার হয় এবং যদি তাই হয় , কি পার্থক্য?

  5. আমি যদি ক্লাসগুলির অগ্রাধিকার বাড়ানোর জন্য পৃথক রিয়েল-টাইম কার্ভটি ব্যবহার করি তবে আমার কেন "কার্ভস" লাগবে না? কেন রিয়েল-টাইম একটি ফ্ল্যাট মান এবং লিংক-ভাগ একটি ফ্ল্যাট মান হয় না? উভয় বক্ররেখা কেন? মূল কাগজে বক্ররেখার প্রয়োজনীয়তা স্পষ্ট, কারণ প্রতি ক্লাসে এই ধরণের একমাত্র বৈশিষ্ট্য রয়েছে। তবে এখন, তিনটি বৈশিষ্ট্য (রিয়েল-টাইম, লিংক-ভাগ এবং উচ্চ-সীমা) থাকার পরেও আমার প্রতিটিটির জন্য এখনও কার্ভ দরকার? রিয়েল-টাইম এবং লিংক-শেয়ার ট্র্যাফিকের জন্য কেন আমি বক্ররেখা আকার (গড় ব্যান্ডউইথ নয়, তবে তাদের opালু) আলাদা হতে চাই?

  6. প্রাপ্ত সামান্য ডকুমেন্টেশন অনুসারে, রিয়েল-টাইম কার্ভের মানগুলি অভ্যন্তরীণ ক্লাসগুলির জন্য (ক্লাস এ এবং বি) পুরোপুরি উপেক্ষা করা হবে, সেগুলি কেবল পাতার শ্রেণিতে প্রয়োগ হয় (এ 1, এ 2, বি 1, বি 2)। যদি এটি সত্য হয় তবে কেন ALTQ এইচএফএসসি নমুনা কনফিগারেশন ( ৩.৩ নমুনা কনফিগারেশন সন্ধান করুন ) অভ্যন্তরীণ ক্লাসগুলিতে রিয়েল-টাইম বক্ররেখাগুলি সেট করে এবং দাবি করে যে সেগুলি সেই অভ্যন্তরীণ শ্রেণীর গ্যারান্টিযুক্ত হার নির্ধারণ করে? তা কি পুরোপুরি অর্থহীন নয়? (দ্রষ্টব্য: Phare ALTQ এ লিংক-ভাগের বক্ররেখা সেট করে এবং রিয়েল-টাইম বক্ররেখাকে ক্রেস্ট করে; আপনি এটি নমুনা কনফিগারেশনের উপরের অনুচ্ছেদে দেখতে পারেন)।

  7. কিছু টিউটোরিয়াল বলেছে যে সমস্ত রিয়েল-টাইম কার্ভের যোগফল লাইন গতির 80% এর বেশি নাও হতে পারে, অন্যরা বলে যে এটি অবশ্যই রেখার গতির 70% এর বেশি হওয়া উচিত নয়। কোনটি সঠিক বা তারা উভয়ই ভুল হতে পারে?

  8. একটি টিউটোরিয়াল বলেছে যে আপনি সমস্ত তত্ত্বটি ভুলে যাবেন। বিষয়গুলি সত্যই কীভাবে কাজ করে তা নির্ধারণ করে না (তফসিলকারী এবং ব্যান্ডউইথ বিতরণ), নিম্নলিখিত "সরলিকৃত মাইন্ড মডেল" অনুসারে তিনটি বক্ররেখার কল্পনা করুন: রিয়েল-টাইম হ'ল গ্যারান্টিযুক্ত ব্যান্ডউইথ যে এই বর্গটি সর্বদা পাবে। লিঙ্ক-ভাগ হ'ল ব্যান্ডউইথ যে এই শ্রেণিটি পুরোপুরি সন্তুষ্ট হতে চায়, তবে সন্তুষ্টির গ্যারান্টি দেওয়া যায় না। অতিরিক্ত ব্যান্ডউইথ থাকলে, ক্লাসটি এমনকি সন্তুষ্ট হওয়ার জন্য প্রয়োজনের চেয়ে বেশি ব্যান্ডউইথের প্রস্তাব দেওয়া হতে পারে, তবে এটি কখনও উচ্চ-সীমাবদ্ধতার চেয়ে বেশি ব্যবহার করতে পারে না। এই সমস্ত কাজ করার জন্য, সমস্ত রিয়েল-টাইম ব্যান্ডউইথের যোগফল লাইন গতির xx% এর উপরে নাও হতে পারে (উপরের প্রশ্নটি দেখুন, শতাংশটি পরিবর্তিত হয়)। প্রশ্ন: এটি কি কম-বেশি সঠিক বা এইচএসএফসি সম্পর্কিত মোট ভুল বোঝাবুঝি?

  9. এবং যদি উপরের ধারণাটি সত্যই সঠিক হয় তবে সেই মডেলটিতে অগ্রাধিকার কোথায়? উদাহরণস্বরূপ, প্রতিটি শ্রেণীর একটি রিয়েল-টাইম ব্যান্ডউইথ (গ্যারান্টিযুক্ত), একটি লিঙ্ক-শেয়ার ব্যান্ডউইথ (গ্যারান্টিযুক্ত নয়) এবং সম্ভবত একটি উচ্চ-সীমা থাকতে পারে, তবে এখনও কিছু শ্রেণীর অন্যান্য শ্রেণীর তুলনায় উচ্চতর অগ্রাধিকারের প্রয়োজন রয়েছে। সেক্ষেত্রে সেই ক্লাসগুলির রিয়েল-টাইম ট্র্যাফিকের মধ্যেও আমাকে এখনও কোনওভাবে অগ্রাধিকার দিতে হবে। আমি কি বক্ররেখার opeাল দ্বারা অগ্রাধিকার দেব? এবং যদি তাই হয় তবে কোন বাঁক? আসল সময়ের বক্ররেখা? লিংক-শেয়ার বক্ররেখা? উপরের সীমা বাঁকা? তাদের সবাই? আমি কি তাদের সকলকে একই opeাল বা প্রতিটিকে আলাদা আলাদা করে দেব এবং কীভাবে সঠিক opeালুটি সন্ধান করব?

আমি এখনও এই আশাটি হারাইনি যে এই পৃথিবীতে কমপক্ষে এমন একটি লোকের হাত রয়েছে যা সত্যই এইচএফএসসি বুঝতে পেরেছে এবং এই সমস্ত প্রশ্নের সঠিকভাবে উত্তর দিতে সক্ষম to এবং উত্তরে একে অপরের সাথে বিতর্ক না করে এটি করা সত্যিই দুর্দান্ত হবে ;-)


পলক জ্বলন
ম্যাট সিমন্স

5
শুভকামনা। হতে পারে আপনার সফ্টওয়্যারটির লেখককে লিখে তাদের সাথে এটি সম্পর্কে কথা বলা উচিত। আমি নিশ্চিত যে তারা অন্য কারও কাছ থেকে তাদের বিষয়ে যেমন আগ্রহী তেমন আগ্রহী শুনতে শুনতে তাদের পছন্দ করবে।
ম্যাট সিমন্স

1
এই প্রশ্নটি খুব একাডেমিক এবং এখানে বাস্তবিক উত্তর পাওয়ার পক্ষে খুব উপযুক্ত নয় IM আমি ম্যাট এর সাথে একমত যে লেখক বা লেখকদের সাথে কিছু যোগাযোগ করা আপনার ক্রিয়াকলাপ।
joeqwerty

2
আপনি কি কাগজের লেখকের ইমেল পাঠাতে পারবেন? তিনি কোড মাধ্যমে ওয়েড সাহায্য করতে পারে?
ম্যাট সিমন্স

4
+1 ম্যাট মক্কি, আমি সন্দেহ করি আপনার প্রশ্নের আক্ষরিক উত্তর "না"।
রিচার্ড হলোয়ে

উত্তর:


16

এইচএফএসসি এবং এর কাজিনদের উপর কাগজপত্র পড়া এটি বোঝার ভাল উপায় নয়। এইচএফএসসি পেপারের প্রাথমিক লক্ষ্যটি তার দাবির কঠোর গাণিতিক প্রমাণ সরবরাহ করা, এটি কীভাবে কাজ করে তা ব্যাখ্যা না করে। প্রকৃতপক্ষে আপনি বুঝতে পারবেন না যে এটি কীভাবে একা এইচএফএসসি কাগজ থেকে কাজ করে, আপনাকে সেই কাগজপত্রগুলিও পড়তে হবে it আপনার যদি দাবি বা তাদের প্রমাণগুলির সাথে কিছু সমস্যা হয় তবে কাগজপত্রের লেখকদের সাথে যোগাযোগ করা ভাল ধারণা হতে পারে, অন্যথায় আমার সন্দেহ হয় তারা আপনার কাছ থেকে শ্রবণ করতে আগ্রহী হবে।

আমি এইচএফএসসির জন্য একটি টিউটোরিয়াল লিখেছি । নীচে আমার ব্যাখ্যাগুলি পরিষ্কার না হলে এটি পড়ুন।

আমার কীসের জন্য আদৌ একটি বাস্তব-সময়ের বক্ররেখা প্রয়োজন? ধরে নিলাম এ 1, এ 2, বি 1, বি 2 সবগুলিই 128 কেবিট / স লিঙ্ক-শেয়ার (কোনও একটির জন্য রিয়েল-টাইম কার্ভ নয়), তবে এর প্রত্যেকটি 128 কেবিট / গুলি পাবে যদি মূলটি বিতরণের জন্য 512 কেবিট / গুলি থাকে (এবং এ এবং বি উভয়ই অবশ্যই 256 কেবিট / সেকেন্ড), ঠিক আছে? আমি কেন অতিরিক্তভাবে এ 1 এবং বি 1 কে 128 কেবিট / এস সহ একটি রিয়েল-টাইম বক্ররেখা দেব? এটি কি জন্য ভাল হবে? এই দুটি উচ্চতর অগ্রাধিকার দিতে? মূল কাগজ অনুসারে আমি তাদের বক্ররেখা ব্যবহার করে একটি উচ্চতর অগ্রাধিকার দিতে পারি, এইচএফএসসি সবকিছুর পরে। উভয় শ্রেণিকে একটি বক্ররেখা প্রদান করে [256kbit / s 20ms 128kbit / s] উভয়ই স্বয়ংক্রিয়ভাবে A2 এবং B2 এর চেয়ে দ্বিগুণ অগ্রাধিকার পেয়েছে (এখনও কেবলমাত্র 128 কেবিট / সেকেন্ডে প্রাপ্ত)

আসল সময়ের বক্ররেখা এবং লিঙ্ক ভাগ করে নেওয়া বক্ররেখা বিভিন্নভাবে মূল্যায়ন করা হয়। রিয়েল টাইম কার্ভটি পুরো ইতিহাস জুড়ে কোনও শ্রেণি কী করেছে তা বিবেচনায় নেয়। সঠিক ব্যান্ডউইথ এবং বিলম্বিত বরাদ্দ সরবরাহ করতে এটি অবশ্যই করতে হবে। খারাপ দিকটি এটি বেশিরভাগ লোককে স্বজ্ঞাতভাবে ন্যায্য বলে মনে করে না । বাস্তব সময়ের অধীনে, যদি কোনও শ্রেণি যদি ব্যান্ডউইদথ bণ ​​নেয় তবে অন্য কেউ চায় না, এটি পরে শাস্তি দেওয়া হয় যখন অন্য কেউ এটি পরে চায়। এর অর্থ আসল সময়ের গ্যারান্টির অধীনে কোনও শ্রেণি দীর্ঘ সময়ের জন্য কোনও ব্যান্ডউইথ পাবে না কারণ এটি এটি আগে ব্যবহার করেছিল, যখন কেউ তা চায়নি।

লিঙ্কটি ভাগ করে নেওয়া ন্যায্য, এটি অতিরিক্ত ব্যান্ডউইথ ব্যবহার করার জন্য কোনও শ্রেণিকে শাস্তি দেয় না। তবে এর অর্থ এটি শক্তিশালী বিলম্বিত গ্যারান্টি সরবরাহ করতে পারে না।

প্রচ্ছন্নতা গ্যারান্টি সরবরাহ থেকে লিঙ্ক ভাগের পৃথকীকরণ হ'ল নতুন জিনিসটি এইচএফএসসি টেবিলে নিয়ে আসে এবং কাগজটি তার উদ্বোধনের বাক্যটিতে যতটুকু বলে: এই কাগজটিতে , আমরা লিঙ্ক-ভাগ করে নেওয়া এবং গ্যারান্টিযুক্ত উভয়কে সমর্থন করে এমন শ্রেণিবিন্যাসিক রিসোর্স ম্যানেজমেন্ট মডেল এবং অ্যালগরিদম অধ্যয়ন করি ডিকپلড বিলম্ব (অগ্রাধিকার) এবং ব্যান্ডউইথ বরাদ্দ সহ রিয়েল-টাইম পরিষেবাগুলি। এই বাক্যটির মূল শব্দটি decoupled হয়। অনুবাদিত, এর অর্থ হল আপনার প্রত্যাশিতভাবে বলা হবে যে কীভাবে অব্যবহৃত ব্যান্ডউইথকে এলএস এর সাথে ভাগ করা যায় এবং আরটিটির সাথে রিয়েল টাইম গ্যারান্টি (ওরফে লেটেন্সি গ্যারান্টি) কী প্রয়োজন তা নির্দিষ্ট করে। দুটো অর্থেগোনাল।

রিয়েল-টাইম ব্যান্ডউইদথটি লিংক-শেয়ার ব্যান্ডউইথের দিকে গুনতে পারে?

হ্যাঁ। এইচএফএসসি কাগজে তারা ব্যান্ডউইথকে সংজ্ঞায়িত করে ক্লাসটি যা পাঠিয়েছিল সেহেতু ক্লাসটি ব্যাকলগ হয়ে গেছে (অর্থাত প্যাকেটগুলি প্রেরণের জন্য অপেক্ষা করছে)। আরটি এবং এলএসের মধ্যে একমাত্র পার্থক্য হ'ল প্রতিটি সময় থেকে ক্লাস ব্যাকলগ হয়ে যায় এবং সেই সেট থেকে সর্বনিম্ন গ্যারান্টিযুক্ত ব্যান্ডউইথের গণনা করে, যেখানে লিঙ্ক ভাগাভাগি কেবল ক্লাসটি ব্যাকলগ হওয়ার পরে শেষ বারের থেকে দেখায়। সুতরাং আরটি ls এর চেয়ে বেশি বাইটস বিবেচনায় নেয়, তবে প্রতিটি বাইটগুলিও আরটি বিবেচনা করে।

উপরের সীমাটি বক্ররেখাগুলি কি রিয়েল-টাইম হিসাবেও প্রয়োগ করা হয়, কেবল লিংক-শেয়ারের জন্য, বা সম্ভবত উভয়ের ক্ষেত্রেই?

উপরের সীমাটি প্যাকেটগুলি বাস্তব সময়ের শর্ত পূরণ করতে প্রেরণ করা থেকে বিরত রাখে না। বাস্তব সময়ের শর্তে প্রেরিত প্যাকেটগুলি এখনও উপরের সীমাতে গণনা করা হয় এবং ভবিষ্যতে লিঙ্ক ভাগ করে নেওয়ার শর্তে একটি প্যাকেট প্রেরণে বিলম্বিত হতে পারে। এটি বাস্তব সময় এবং লিঙ্ক ভাগের মধ্যে অন্য পার্থক্য।

ধরে নিলাম এ 2 এবং বি 2 উভয়ই 128 কেবিট / সে, যদি এ 1 এবং বি 1 কেবল 128 কেবিট / স লিঙ্ক-শেয়ার হয় তবে বা 64 কেবিট / গুলি রিয়েল-টাইম এবং 128 কেবিট / গুলি লিঙ্ক-শেয়ার হয় এবং যদি তাই হয় , কি পার্থক্য?

হ্যাঁ, এটি একটি পার্থক্য করতে পারে। উপরে উল্লিখিত হিসাবে যদি আপনি বাস্তব সময় ব্যবহার করেন তবে বিলম্বগুলি নিশ্চিত হয় তবে লিঙ্কটি মোটামুটি ভাগ করা হয় না (এবং বিশেষত শ্রেণিটি ব্যান্ডউইথ অনাহারে ভুগতে পারে), এবং উপরের সীমাগুলি প্রয়োগ করা হয় না। আপনি যদি লিংক শেয়ারটি ব্যবহার করেন তবে বিলম্বের নিশ্চয়তা নেই তবে লিঙ্ক ভাগাভাগি ন্যায্য, অনাহারে কোনও ঝুঁকি নেই এবং উচ্চতর সীমা প্রয়োগ করা হয়। লিঙ্ক শেয়ারের আগে রিয়েল টাইম সর্বদা চেক করা হয় তবে এর অর্থ এই নয় যে লিঙ্ক ভাগটিকে উপেক্ষা করা হবে। কারণ প্যাকেটগুলি আলাদাভাবে গণনা করা হয়। যেহেতু ইতিহাসকে রিয়েল টাইম হিসাবে বিবেচনা করা হয় কোনও প্যাকেটের বাস্তব সময়ের গ্যারান্টিটি পূরণ করার প্রয়োজন নাও হতে পারে (কারণ ইতিহাস থেকে অন্তর্ভুক্ত হওয়া একজন হিসাবে) তবে লিঙ্ক ভাগটি সন্তুষ্ট করার প্রয়োজন কারণ এটি historicalতিহাসিক প্যাকেটটিকে উপেক্ষা করে।

আমি যদি ক্লাসগুলির অগ্রাধিকার বাড়ানোর জন্য পৃথক রিয়েল-টাইম কার্ভটি ব্যবহার করি তবে আমার কেন "কার্ভস" লাগবে না? কেন রিয়েল-টাইম একটি ফ্ল্যাট মান এবং লিংক-ভাগ একটি ফ্ল্যাট মান হয় না? উভয় বক্ররেখা কেন? মূল কাগজে বক্ররেখার প্রয়োজনীয়তা স্পষ্ট, কারণ প্রতি ক্লাসে এই ধরণের একমাত্র বৈশিষ্ট্য রয়েছে। তবে এখন, তিনটি বৈশিষ্ট্য (রিয়েল-টাইম, লিংক-ভাগ এবং উচ্চ-সীমা) থাকার পরেও আমার প্রতিটিটির জন্য এখনও কার্ভ দরকার? রিয়েল-টাইম এবং লিংক-শেয়ার ট্র্যাফিকের জন্য কেন আমি বক্ররেখা আকার (গড় ব্যান্ডউইথ নয়, তবে তাদের opালু) আলাদা হতে চাই?

রিয়েল টাইম কন্ট্রোলগুলির জন্য বক্ররেখা আপনাকে অন্য কোনও ট্র্যাফিক ক্লাসের (যেমন ইমেল) দুর্বলতার জন্য একটি নির্দিষ্ট ট্র্যাফিক ক্লাসের (উদাহরণস্বরূপ ভিওআইপি) কঠোরভাবে বিলম্বিত বাণিজ্য করতে দেয়। রিয়েল টাইম সীমাবদ্ধতার অধীনে কোন প্যাকেটটি প্রেরণ করবেন তা সিদ্ধান্ত নেওয়ার সময় এইচএফএসসি এমন একটি চয়ন করে যা প্রথমে প্রেরণ সম্পূর্ণ করবে। তবে এটি গণনা করতে লিংকের ব্যান্ডউইথ ব্যবহার করে না, এটি রিয়েল টাইম কার্ভ দ্বারা বরাদ্দ ব্যান্ডউইথ ব্যবহার করে। সুতরাং যদি আমাদের কাছে একই দৈর্ঘ্যের ভিওআইপি এবং ইমেল প্যাকেট থাকে এবং ভিওআইপি প্যাকেটে একটি উত্তল বক্র থাকে যা ইমেলের জন্য অবতল বক্ররেখাকে 10 গুণ বাড়িয়ে দেয় তবে মুষ্টি ইমেলের প্যাকেটের আগে 10 ভিওআইপি প্যাকেট প্রেরণ করা হবে। তবে এটি কেবল ফেটে যাওয়া সময়ের জন্যই ঘটে যা কয়েকটি প্যাকেট পাঠাতে বেশিরভাগ সময় হওয়া উচিত - যেমন মিলি সেকেন্ড। এরপরে ভিওআইপি বক্ররেখা সমতল হওয়া উচিত, এবং কিছু সময়ের জন্য ব্যাকআপ না নিলে ভিওআইপি কোনও ভবিষ্যতের উত্সাহ পাবে না (যা দেওয়া ভিওআইপি একটি নিম্ন ব্যান্ডউইথ অ্যাপ্লিকেশন, এটি হওয়া উচিত)। এই সমস্তের নিখুঁত ফলাফল হ'ল ভিওআইপি প্যাকেটগুলির প্রথম কয়েকটি অন্য যে কোনও তুলনায় দ্রুত প্রেরণ করা হয়েছে তা নিশ্চিত করা, যাতে ইমেল ব্যয় করে উচ্চতর বিলম্বিত হওয়াতে ভিওআইপি কম বিলম্বিত হয়।

আমি আগেই বলেছি, কারণ লিঙ্ক ভাগ ইতিহাসের দিকে তাকাচ্ছে না কারণ এটি বিলম্বের গ্যারান্টি দিতে পারে না। ভিওআইপি-র মতো রিয়েল টাইম ট্র্যাফিকের জন্য প্রয়োজনীয় রকস গ্যারান্টি। তবে, গড়ে একটি লিঙ্ক ভাগ করে নেওয়া উত্তল বক্ররেখা তার ট্র্যাফিককে এখনও একটি বিলম্ব বাড়িয়ে দেবে। এটি কেবল গ্যারান্টিযুক্ত নয়। এটি ইমেলের মাধ্যমে ওয়েব ট্র্যাফিকের মতো বেশিরভাগ জিনিসের জন্য দুর্দান্ত।

প্রাপ্ত সামান্য ডকুমেন্টেশন অনুসারে, রিয়েল-টাইম কার্ভের মানগুলি অভ্যন্তরীণ ক্লাসগুলির জন্য (ক্লাস এ এবং বি) পুরোপুরি উপেক্ষা করা হবে, সেগুলি কেবল পাতার শ্রেণিতে প্রয়োগ হয় (এ 1, এ 2, বি 1, বি 2)। যদি এটি সত্য হয় তবে কেন ALTQ এইচএফএসসি নমুনা কনফিগারেশন (৩.৩ নমুনা কনফিগারেশন সন্ধান করুন) অভ্যন্তরীণ ক্লাসগুলিতে রিয়েল-টাইম বক্ররেখাগুলি সেট করে এবং দাবি করে যে সেগুলি সেই অভ্যন্তরীণ শ্রেণীর গ্যারান্টিযুক্ত হার নির্ধারণ করে? তা কি পুরোপুরি অর্থহীন নয়? (দ্রষ্টব্য: Phare ALTQ এ লিংক-ভাগের বক্ররেখা সেট করে এবং রিয়েল-টাইম বক্ররেখাকে ক্রেস্ট করে; আপনি এটি নমুনা কনফিগারেশনের উপরের অনুচ্ছেদে দেখতে পারেন)।

ডকুমেন্টেশন সঠিক। হায়ারার্কি (এবং এইভাবে অভ্যন্তরীণ নোডগুলি) যা-ই হোক না কেন রিয়েল টাইমের গণনায় কোনও প্রভাব ফেলেনি। আমি আপনাকে বলতে পারি না কেন ALTQ স্পষ্টতই মনে করে যে এটি করে।

কিছু টিউটোরিয়াল বলেছে যে সমস্ত রিয়েল-টাইম কার্ভের যোগফল লাইন গতির 80% এর বেশি নাও হতে পারে, অন্যরা বলে যে এটি অবশ্যই রেখার গতির 70% এর বেশি হওয়া উচিত নয়। কোনটি সঠিক বা তারা উভয়ই ভুল হতে পারে?

দুটোই ভুল। যদি আপনার ট্র্যাফিকের %০% বা ৮০% এর যথাযথ প্রসারণের প্রয়োজনীয়তা থাকে যা অবশ্যই রিয়েল টাইমের সাথে নির্দিষ্ট করে দেওয়া উচিত, বাস্তবতা হ'ল আপনি যে লিঙ্কটি ব্যবহার করছেন তার সাথে আপনি অবশ্যই তাদের সন্তুষ্ট করতে পারবেন না। আপনার একটি দ্রুত লিঙ্ক প্রয়োজন।

কেউ যদি ভাবতে পারে যে 80% ট্র্যাফিকের আসল সময় হওয়া উচিত তবে যদি তারা আসল সময়টিকে অগ্রাধিকার বৃদ্ধিরূপে চালিত করে। হ্যাঁ, বিলম্বতার গ্যারান্টি সরবরাহ করার জন্য আপনি কার্যকরভাবে কিছু প্যাকেটের অগ্রাধিকার বাড়িয়ে তুলছেন। তবে এটি শুধুমাত্র মিলি সেকেন্ডের জন্য হওয়া উচিত। এই সমস্ত লিঙ্কটি সামলাতে পারে এবং এখনও বিলম্বের গ্যারান্টি সরবরাহ করে।

খুব কম ট্র্যাফিকের জন্য বিলম্বের গ্যারান্টি দরকার। ভিওআইপি একজন, এনটিপি আরেকটি another বাকিগুলি লিঙ্ক ভাগ করে নেওয়া উচিত। এটি আপনি ওয়েবটি দ্রুত হতে চান, আপনি বেশিরভাগ লিঙ্কের ক্ষমতা বরাদ্দ করে এটিকে দ্রুত করে তোলেন। যে ভাগ করা হয় দীর্ঘ সময়ের নিশ্চিত। এটি আপনি এটি কম বিলম্বিত হওয়া চান (গড়), লিঙ্ক ভাগ করে নেওয়ার ভিত্তিতে এটিকে উত্তল বাঁক দিন।

একটি টিউটোরিয়াল বলেছে যে আপনি সমস্ত তত্ত্বটি ভুলে যাবেন। বিষয়গুলি সত্যই কীভাবে কাজ করে তা নির্ধারণ করে না (তফসিলকারী এবং ব্যান্ডউইথ বিতরণ), নিম্নলিখিত "সরলিকৃত মাইন্ড মডেল" অনুসারে তিনটি বক্ররেখার কল্পনা করুন: রিয়েল-টাইম হ'ল গ্যারান্টিযুক্ত ব্যান্ডউইথ যে এই বর্গটি সর্বদা পাবে। লিঙ্ক-ভাগ হ'ল ব্যান্ডউইথ যে এই শ্রেণিটি পুরোপুরি সন্তুষ্ট হতে চায়, তবে সন্তুষ্টির গ্যারান্টি দেওয়া যায় না। অতিরিক্ত ব্যান্ডউইথ থাকলে, ক্লাসটি এমনকি সন্তুষ্ট হওয়ার জন্য প্রয়োজনের চেয়ে বেশি ব্যান্ডউইথের প্রস্তাব দেওয়া হতে পারে, তবে এটি কখনও উচ্চ-সীমাবদ্ধতার চেয়ে বেশি ব্যবহার করতে পারে না। এই সমস্ত কাজ করার জন্য, সমস্ত রিয়েল-টাইম ব্যান্ডউইথের যোগফল লাইন গতির xx% এর উপরে নাও হতে পারে (উপরের প্রশ্নটি দেখুন, শতাংশটি পরিবর্তিত হয়)। প্রশ্ন: এটি কি কম-বেশি সঠিক বা এইচএসএফসি সম্পর্কিত মোট ভুল বোঝাবুঝি?

এটি ভাল বর্ণনা উচ্চতর সীমা। লিঙ্ক ভাগের বিবরণ কঠোরভাবে সঠিক হলেও এটি বিভ্রান্তিকর। যদিও এটির সত্যিকারের লিঙ্ক শেয়ারটি সত্যিকারের মতো শক্ত লেটেন্সির গ্যারান্টি দেয় না, এটি ক্লাসটিকে তার ব্যান্ডউইদথকে তার বরাদ্দগুলি যেমন তার প্রতিযোগীদের, সিবিকিউ এবং এইচটিবি-র তুলনায় দেওয়ার চেয়ে আরও ভাল কাজ করে। সুতরাং লিংক শেয়ারটি "গ্যারান্টি সরবরাহ করে না" বলার ক্ষেত্রে এটি অন্য কোনও শিডিয়ুলার সরবরাহ করতে পারে এমন একটি উচ্চতর মানকে ধরে রাখে।

রিয়েল টাইম বর্ণনাটি উভয়ই সঠিক হতে পরিচালিত করে, তবে এত বিভ্রান্তিকর আমি এটিকে ভুল বলি। নামটি থেকে বোঝা যায় আসল সময়ের উদ্দেশ্যটি গ্যারান্টিযুক্ত ব্যান্ডউইথ না দেওয়া। এটি গ্যারান্টিযুক্ত লেটেন্সি সরবরাহ করতে হয় - অর্থাত প্যাকেটটি এখনই প্রেরণ করা হয়, লিঙ্কটি কীভাবে ব্যবহৃত হয় তার উপর নির্ভর করে পরে কিছুটা এলোমেলো পরিমাণ নয়। বেশিরভাগ ট্র্যাফিকের গ্যারান্টিযুক্ত বিলম্বের প্রয়োজন হয় না।

এটি বলেছিল, রিয়েল টাইম হয় নিখুঁত বিলম্বতার গ্যারান্টি দেয় না। এটি হতে পারে, যদি লিঙ্কটি ভাগ করেও লিংকটি পরিচালনা না করা হত তবে বেশিরভাগ ব্যবহারকারী উভয়ই থাকার অতিরিক্ত নমনীয়তা চান এবং এটি নিখরচায় আসে না। একটি এমটিইউ প্যাকেট প্রেরণের জন্য সময়টি আসল সময়টি মিস করতে পারে। (যদি এটি ঘটে থাকে তবে এটি হবে কারণ এটি একটি এমটিইউ প্যাকেট লিঙ্ক শেয়ারের তাত্ক্ষণিক ঘটনা ছিল যখন লিঙ্কটি নিষ্ক্রিয় অবস্থায় রাখার ক্ষেত্রে যদি এটি তাত্ক্ষণিকভাবে প্রেরণ করতে হত এমন একটি প্যাকেট সংক্ষিপ্ত সময়সীমার সাথে দেওয়া হত link এটি লিংক শেয়ারের মধ্যে আর একটি পার্থক্য এবং রিয়েল টাইম। এর গ্যারান্টি সরবরাহ করার জন্য রিয়েল টাইম ইচ্ছাকৃতভাবে লাইনটি অলস রাখতে পারে যদিও প্রেরণের জন্য প্যাকেট রয়েছে, সুতরাং এটি 100% এর চেয়ে কম লিঙ্কের ব্যবহার সরবরাহ করে। লিঙ্ক শেয়ারটি সর্বদা উপলব্ধ ক্ষমতার 100% ব্যবহার করে real রিয়েল টাইমের বিপরীতে ,

যে কারণে আসল সময়টি কঠোর বিলম্বের গ্যারান্টি সরবরাহ করতে বলা যায় তা হ'ল বিলম্ব সীমাবদ্ধ। সুতরাং আপনি যদি 1 এমবিট / সেকেন্ড লিঙ্কে 20 মিমি বিলম্বের গ্যারান্টি দেওয়ার চেষ্টা করছেন এবং লিঙ্ক শেয়ারটি এমটিইউ আকারের (1500 বাইট) প্যাকেট প্রেরণ করছে, আপনি জানেন যে এই প্যাকেটগুলির একটি প্রেরণে 12 মিমি লাগবে। সুতরাং আপনি যদি 8 মাইলের বিলম্ব চান এমন সময়টি যদি সত্য বলতে চান তবে আপনি এখনও 20 মিমের সময়সীমাটি পূরণ করতে পারেন - পরম গ্যারান্টি সহ।

এবং যদি উপরের ধারণাটি সত্যই সঠিক হয় তবে সেই মডেলটিতে অগ্রাধিকার কোথায়? উদাহরণস্বরূপ, প্রতিটি শ্রেণীর একটি রিয়েল-টাইম ব্যান্ডউইথ (গ্যারান্টিযুক্ত), একটি লিঙ্ক-শেয়ার ব্যান্ডউইথ (গ্যারান্টিযুক্ত নয়) এবং সম্ভবত একটি উচ্চ-সীমা থাকতে পারে, তবে এখনও কিছু শ্রেণীর অন্যান্য শ্রেণীর তুলনায় উচ্চতর অগ্রাধিকারের প্রয়োজন রয়েছে। সেক্ষেত্রে সেই ক্লাসগুলির রিয়েল-টাইম ট্র্যাফিকের মধ্যেও আমাকে এখনও কোনওভাবে অগ্রাধিকার দিতে হবে। আমি কি বক্ররেখার opeাল দ্বারা অগ্রাধিকার দেব? এবং যদি তাই হয় তবে কোন বাঁক? আসল সময়ের বক্ররেখা? লিংক-শেয়ার বক্ররেখা? উপরের সীমা বাঁকা? তাদের সবাই? আমি কি তাদের সকলকে একই opeাল বা প্রতিটিকে আলাদা আলাদা করে দেব এবং কীভাবে সঠিক opeালুটি সন্ধান করব?

কোনও অগ্রাধিকারের মডেল নেই। সিরিয়াসলি। আপনি যদি ট্র্যাফিককে নিখুঁত অগ্রাধিকার দিতে চান তবে pfifo ব্যবহার করুন। এটা যে জন্য হয়। তবে এও সাবধান হন যে আপনি যদি ইমেল ট্র্যাফিকের উপর ওয়েব ট্র্যাফিককে নিখুঁত অগ্রাধিকার দেন, তার অর্থ ওয়েব ট্র্যাফিকটিকে লিঙ্কটি পরিপূর্ণ করে দেওয়া এবং এভাবে কোনও ইমেল প্যাকেটগুলি একেবারেই পাওয়া যাচ্ছে না । আপনার সমস্ত ইমেল সংযোগগুলি তখন মারা যায়।

বাস্তবে কেউ এই ধরণের অগ্রাধিকার চায় না। তারা যা চায় তা হ'ল এইচএফএসসি প্রদান করে। আপনার যদি সত্যিকারের রিয়েল টাইম ট্র্যাফিক থাকে তবে এইচএফএসসি তা সরবরাহ করে। তবে এটি সব স্টাফ হবে। বাকীগুলির জন্য, এইচএফএসসি আপনাকে "একটি কনজিস্টেড লিঙ্কে, 90% ওয়েবে বরাদ্দ করতে এবং 10% এ ইমেলটি ট্রিকল করতে দেয় এবং ওহকে দ্রুত বিজোড় ডিএনএস প্যাকেটটি প্রেরণ করুন তবে কাউকে এটি দিয়ে আমাকে ডস করতে দেবেন না।"


5

আপনি বিভিন্ন নামের সাথে বক্ররেখাকে সংজ্ঞায়িত করতে পারেন:

  • আরটি, রিয়েল-টাইম কার্ভ, ব্যান্ডউইথ / বিলম্ব গ্যারান্টি।
  • এলএস, লিঙ্ক-শেয়ার কার্ভ, ব্যান্ডউইথ / বিলম্ব ভাগাভাগি (প্রতিবেশী পাতার কনফিগারেশনের উপর ভিত্তি করে)
  • উল, উপরের সীমা বক্ররেখা, সর্বাধিক ব্যান্ডউইথ / বিলম্ব এটি পেতে পারে।

আমার কীসের জন্য আদৌ একটি বাস্তব-সময়ের বক্ররেখা প্রয়োজন? ধরে নিলাম এ 1, এ 2, বি 1, বি 2 সবগুলিই 128 কেবিট / স লিঙ্ক-শেয়ার (কোনও একটির জন্য রিয়েল-টাইম কার্ভ নয়), তবে এর প্রত্যেকটি 128 কেবিট / গুলি পাবে যদি মূলটি বিতরণের জন্য 512 কেবিট / গুলি থাকে (এবং এ এবং বি উভয়ই অবশ্যই 256 কেবিট / সেকেন্ড), ঠিক আছে? আমি কেন অতিরিক্তভাবে এ 1 এবং বি 1 কে 128 কেবিট / এস সহ একটি রিয়েল-টাইম বক্ররেখা দেব? এটি কি জন্য ভাল হবে? এই দুটি উচ্চতর অগ্রাধিকার দিতে? মূল কাগজ অনুসারে আমি তাদের বক্ররেখা ব্যবহার করে একটি উচ্চতর অগ্রাধিকার দিতে পারি, এইচএফএসসি সবকিছুর পরে। উভয় শ্রেণিকে একটি বক্ররেখা প্রদান করে [256kbit / s 20ms 128kbit / s] উভয়ই স্বয়ংক্রিয়ভাবে A2 এবং B2 এর চেয়ে দ্বিগুণ অগ্রাধিকার পেয়েছে (এখনও কেবলমাত্র 128 কেবিট / সেকেন্ডে প্রাপ্ত)

আপনি যখন এইচএফএসসিতে কেবলমাত্র হারের সাথে একটি সংজ্ঞা করেন, এটি স্বয়ংক্রিয়ভাবে 'ড্যাম্যাক্স' 0 এ সেট করে Which একটি ভাল এইচএফএসসি কনফিগারেশনে আপনার ক্লাসের জন্য আপনি ব্যান্ডউইথ এবং বিলম্ব সীমানা উভয়ই অন্তর্ভুক্ত করা উচিত, অন্যথায় অ্যালগরিদম কোনও শ্রেণীর কতটুকু অগ্রাধিকার পাওয়া উচিত তা ঠিক বুঝতে পারে না।

আপনি যখনই প্যাকেটগুলিকে অগ্রাধিকার দেবেন তখন অন্যান্য প্যাকেটগুলিকে অগ্রাধিকার হ্রাস করতে হবে। 'ডিএমএক্স' এবং 'রেট' মানের উপর ভিত্তি করে ভার্চুয়াল টাইমার ব্যবহার করে সমস্ত ক্লাস মাল্টিপ্লেক্স হবে। আরও তথ্যের জন্য tc-hfsc (7) দেখুন।

রিয়েল-টাইম ব্যান্ডউইদথটি লিংক-শেয়ার ব্যান্ডউইথের দিকে গুনতে পারে? উদাহরণস্বরূপ, যদি এ 1 এবং বি 1 উভয়টিরই কেবলমাত্র 64kbit / s রিয়েল-টাইম এবং 64kbit / s লিংক-শেয়ার ব্যান্ডউইদথ থাকে, তার অর্থ কি একবার তারা রিয়েল-টাইমের মাধ্যমে 64kbit / s পরিবেশন করা হয়, তাদের লিঙ্ক-ভাগের প্রয়োজনীয়তাও ততই সন্তুষ্ট হয় (তারা সম্ভবত অতিরিক্ত ব্যান্ডউইথ পান, তবে এটি এক সেকেন্ডের জন্যও উপেক্ষা করতে দিন) বা এর অর্থ তারা লিংক-শেয়ারের মাধ্যমে আরও একটি 64 কেবিট / এস পাবে? তাহলে কি প্রতিটি শ্রেণীর রিয়েল-টাইম প্লাস লিংক-শেয়ারের একটি ব্যান্ডউইথ "প্রয়োজনীয়তা" রয়েছে? বা লিঙ্ক-ভাগের বক্ররেখার বাস্তব-সময়ের কার্ভের চেয়ে বেশি হলে কোনও শ্রেণীর কি কেবল রিয়েল-টাইম কার্ভের চেয়ে বেশি প্রয়োজন (বর্তমান লিঙ্ক-ভাগের প্রয়োজনীয়তা নির্দিষ্ট লিঙ্ক-ভাগের প্রয়োজনের বিয়োগের রিয়েল-টাইম ব্যান্ডউইথের জন্য ইতিমধ্যে সরবরাহ করা হয়েছে শ্রেণী)?

শ্রেণীর লিঙ্ক-শেয়ার সংজ্ঞাটির সীমানা ছাড়িয়ে যদি ফ্লোটি না চলে যায় তবে রিয়েল-টাইম কার্ভটি কখনই ব্যবহৃত হয় না। এই ক্ষেত্রে একটি রিয়েল-টাইম বক্ররেখার সংজ্ঞা দেওয়া আপনাকে উদাহরণস্বরূপ: একটি নির্দিষ্ট 'dmax' গ্যারান্টি দেয়।

যদি আপনার লিঙ্ক-ভাগ সংজ্ঞাগুলি ত্রুটিবিহীন হয়, তবে আপনার বাস্তব-সময় কার্ভগুলির প্রয়োজন হবে না। আপনি কেবল পরিষেবা কার্ভগুলি (এসসি) সংজ্ঞায়িত করতে পারেন তবে এটি আপনার কনফিগারেশনটিকে আরও শক্ত করে তুলবে।

উপরের সীমাটি বক্ররেখাগুলি কি রিয়েল-টাইম হিসাবেও প্রয়োগ করা হয়, কেবল লিংক-শেয়ারের জন্য, বা সম্ভবত উভয়ের ক্ষেত্রেই? কিছু টিউটোরিয়াল একটি উপায় বলে, কেউ কেউ অন্যভাবে বলে। কেউ কেউ দাবিও করেন যে রিয়েল-টাইম ব্যান্ডউইথ + লিংক-শেয়ার ব্যান্ডউইদথের জন্য সর্বোচ্চ-সীমা সর্বাধিক? সত্য কি?

আপনার শ্রেণির উপরের সীমাটি বক্ররেখা কেবল লিঙ্ক-ভাগের জন্য প্রয়োগ করা হয়, যখন আপনি একটি উচ্চ-সীমাবদ্ধ বক্ররেখাকে সংজ্ঞায়িত করেন তবে আপনাকে অবশ্যই একটি লিঙ্ক-ভাগের বক্ররেখাকে সংজ্ঞায়িত করতে হবে। তবে প্যারেন্ট ক্লাসের উপরের সীমাবদ্ধ বক্ররেখা এখনও প্রয়োগ করা হয়।

ধরে নিলাম এ 2 এবং বি 2 উভয়ই 128 কেবিট / সে, যদি এ 1 এবং বি 1 কেবল 128 কেবিট / স লিঙ্ক-শেয়ার হয় তবে বা 64 কেবিট / গুলি রিয়েল-টাইম এবং 128 কেবিট / গুলি লিঙ্ক-শেয়ার হয় এবং যদি তাই হয় , কি পার্থক্য?

একটি সামান্য পার্থক্য আছে, উদাহরণস্বরূপ যদি এ 2 = 0 কেবিট / সে এবং বি 2 = 256 কিবিট / সে। তারপরে এ 2 এর ভার্চুয়াল-সময়টি তার সর্বোচ্চ হবে। যখনই প্যাকেটগুলিকে এ 2 তে শ্রেণিবদ্ধ করা হয়, তত্ক্ষণাত তাদের প্রক্রিয়া করা হবে। তবে বি 2 এর রিয়েল-টাইম কার্ভটি এখনও নিশ্চিত করবে যে কমপক্ষে k৪ কেবিট / সেকেন্ড স্থানান্তর করতে সক্ষম

আমি যদি ক্লাসগুলির অগ্রাধিকার বাড়ানোর জন্য পৃথক রিয়েল-টাইম কার্ভ ব্যবহার করি তবে আমার কেন "কার্ভস" লাগবে না? কেন রিয়েল-টাইম একটি ফ্ল্যাট মান এবং লিংক-ভাগ একটি ফ্ল্যাট মান হয় না? উভয় বক্ররেখা কেন? মূল কাগজে বক্ররেখার প্রয়োজনীয়তা স্পষ্ট, কারণ প্রতি শ্রেণিতে এই ধরণের একমাত্র বৈশিষ্ট্য রয়েছে। তবে এখন, তিনটি বৈশিষ্ট্য (রিয়েল-টাইম, লিংক-ভাগ এবং উচ্চ-সীমা) থাকার পরেও আমার প্রতিটিটির জন্য এখনও কার্ভ দরকার? রিয়েল-টাইম এবং লিংক-শেয়ার ট্র্যাফিকের জন্য কেন আমি বক্ররেখা আকার (গড় ব্যান্ডউইথ নয়, তবে তাদের opালু) আলাদা হতে চাই?

রিয়েল-টাইম কার্ভগুলি প্রতিবেশী পাতার মধ্যে ট্র্যাফিক ভাগ করে না, লিঙ্ক-ভাগ বক্ররেখার করে।

প্রাপ্ত সামান্য ডকুমেন্টেশন অনুসারে, রিয়েল-টাইম কার্ভের মানগুলি অভ্যন্তরীণ ক্লাসগুলির জন্য (ক্লাস এ এবং বি) পুরোপুরি উপেক্ষা করা হবে, সেগুলি কেবল পাতার শ্রেণিতে প্রয়োগ হয় (এ 1, এ 2, বি 1, বি 2)। যদি এটি সত্য হয় তবে কেন ALTQ এইচএফএসসি নমুনা কনফিগারেশন (৩.৩ নমুনা কনফিগারেশন সন্ধান করুন) অভ্যন্তরীণ ক্লাসগুলিতে রিয়েল-টাইম বক্ররেখাগুলি সেট করে এবং দাবি করে যে সেগুলি সেই অভ্যন্তরীণ শ্রেণীর গ্যারান্টিযুক্ত হার নির্ধারণ করে? তা কি পুরোপুরি অর্থহীন নয়? (দ্রষ্টব্য: Phare ALTQ এ লিংক-ভাগের বক্ররেখা সেট করে এবং রিয়েল-টাইম বক্ররেখাকে ক্রেস্ট করে; আপনি এটি নমুনা কনফিগারেশনের উপরের অনুচ্ছেদে দেখতে পারেন)।

এটি সত্য যে রিয়েল-টাইম কার্ভগুলি অভ্যন্তরীণ ক্লাসগুলির জন্য উপেক্ষা করা হয়, সেগুলি কেবল পাতার শ্রেণিতে প্রয়োগ করা হয়। তবে সেই অভ্যন্তর শ্রেণিতে সংজ্ঞায়িত রিয়েল-টাইম কার্ভগুলি পাতা শ্রেণিতে গণনার জন্য বিবেচনায় নেওয়া হয়।

কিছু টিউটোরিয়াল বলেছে যে সমস্ত রিয়েল-টাইম কার্ভের যোগফল লাইন গতির 80% এর বেশি নাও হতে পারে, অন্যরা বলে যে এটি অবশ্যই রেখার গতির 70% এর বেশি হওয়া উচিত নয়। কোনটি সঠিক বা তারা উভয়ই ভুল হতে পারে?

এর অর্থ হ'ল: আপনি সমস্ত ট্র্যাফিককে অগ্রাধিকার দিতে পারবেন না ... আপনি যখনই প্যাকেটগুলিকে অগ্রাধিকার দেবেন তখন অন্যান্য প্যাকেটগুলিকে অগ্রাধিকার হ্রাস করতে হবে। আপনি যদি অতিরিক্ত গ্যারান্টি দিয়ে থাকেন তবে অ্যালগরিদম অর্থহীন হয়ে যায়। অগ্রাধিকার অর্জন করে এমন শ্রেণীর সংজ্ঞা দাও এবং যে শ্রেণিগুলি ভুগতে পারে তার সংজ্ঞা দেয়।

একটি টিউটোরিয়াল বলেছে যে আপনি সমস্ত তত্ত্বটি ভুলে যাবেন। বিষয়গুলি সত্যই কীভাবে কাজ করে তা নির্ধারণ করে না (তফসিলকারী এবং ব্যান্ডউইথ বিতরণ), নিম্নলিখিত "সরলিকৃত মাইন্ড মডেল" অনুসারে তিনটি বক্ররেখার কল্পনা করুন: রিয়েল-টাইম হ'ল গ্যারান্টিযুক্ত ব্যান্ডউইথ যে এই বর্গটি সর্বদা পাবে। লিঙ্ক-ভাগ হ'ল ব্যান্ডউইথ যে এই শ্রেণিটি পুরোপুরি সন্তুষ্ট হতে চায়, তবে সন্তুষ্টির গ্যারান্টি দেওয়া যায় না। অতিরিক্ত ব্যান্ডউইথ থাকলে, ক্লাসটি এমনকি সন্তুষ্ট হওয়ার জন্য প্রয়োজনের চেয়ে বেশি ব্যান্ডউইথের প্রস্তাব দেওয়া হতে পারে, তবে এটি কখনও উচ্চ-সীমাবদ্ধতার চেয়ে বেশি ব্যবহার করতে পারে না। এই সমস্ত কাজ করার জন্য, সমস্ত রিয়েল-টাইম ব্যান্ডউইথের যোগফল লাইন গতির xx% এর উপরে নাও হতে পারে (উপরের প্রশ্নটি দেখুন, শতাংশটি পরিবর্তিত হয়)। প্রশ্ন: এটি কি কম-বেশি সঠিক বা এইচএসএফসি সম্পর্কিত মোট ভুল বোঝাবুঝি?

এটা সঠিক।

এবং যদি উপরের ধারণাটি সত্যই সঠিক হয় তবে সেই মডেলটিতে অগ্রাধিকার কোথায়? উদাহরণস্বরূপ, প্রতিটি শ্রেণীর একটি রিয়েল-টাইম ব্যান্ডউইথ (গ্যারান্টিযুক্ত), একটি লিঙ্ক-শেয়ার ব্যান্ডউইথ (গ্যারান্টিযুক্ত নয়) এবং সম্ভবত একটি উচ্চ-সীমা থাকতে পারে, তবে এখনও কিছু শ্রেণীর অন্যান্য শ্রেণীর তুলনায় উচ্চতর অগ্রাধিকারের প্রয়োজন রয়েছে। সেক্ষেত্রে সেই ক্লাসগুলির রিয়েল-টাইম ট্র্যাফিকের মধ্যেও আমাকে এখনও কোনওভাবে অগ্রাধিকার দিতে হবে। আমি কি বক্ররেখার opeাল দ্বারা অগ্রাধিকার দেব? এবং যদি তাই হয় তবে কোন বাঁক? আসল সময়ের বক্ররেখা? লিংক-শেয়ার বক্ররেখা? উপরের সীমা বাঁকা? তাদের সবাই? আমি কি তাদের সকলকে একই opeাল বা প্রতিটিকে আলাদা আলাদা করে দেব এবং কীভাবে সঠিক opeালুটি সন্ধান করব?

যেমন এইচএফএসসি এবং এইচটিবির মধ্যে পার্থক্য হ'ল এইচএফএসসি আপনাকে ঠিক কতটা অগ্রাধিকার পেতে চায় তা নির্ধারণ করতে দেয়। আপনি 'dmax' মানের সাথে ন্যূনতম এবং সর্বাধিক সীমা নির্ধারণ করে এটি করেন।


2

পরিশেষে এমন একটি গাইড যা বেশিরভাগ অসঙ্গতিগুলি ব্যাখ্যা করে এবং বর্তমান বাস্তবায়ন কীভাবে মূল কাগজ থেকে পৃথক:

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

এই গাইড অনুসারে, এইচএফএসসি সম্পর্কিত আরও অনেক গাইড এবং ফোরামের পোস্টগুলি সম্পূর্ণ বোকা; এটি ঠিক দেখায় যে এইচএফএসসি কতটা জটিল, যেহেতু অনেক লোক যারা বিশেষজ্ঞ হিসাবে উপস্থিত হন এবং এইচএফএসসিকে সম্পূর্ণরূপে বোঝার ভান করেন, তাদের কেবলমাত্র আংশিক জ্ঞান থাকে এবং ধারণার ভুল বোঝাবুঝির ভিত্তিতে এবং এই সমস্ত সেটিংস কীভাবে একসাথে খেলেন তার ভিত্তিতে মিথ্যা বিবৃতি দেয়।

আমি মনে করি অবশেষে আমি এইচএফএসসি ছেড়ে দেব। যদি আপনি আপনার এইচএফএসসি সেটআপটি সঠিকভাবে পেতে পারেন তবে এটি আপনার পক্ষে পাওয়া সেরা কিউওএস হতে পারে, তবে আপনি যে সম্ভাবনাটি পুরোপুরি জগাখিচু করছেন তা আপনার সাফল্যের সম্ভাবনার চেয়ে অনেক বেশি।


1

আপনি যদি মূল লেখকদের ধরে রাখতে সক্ষম না হন তবে আমি এটি পরবর্তী চেষ্টা করব:

  1. লিনাক্স কার্নেল উত্স ট্রিতে যান এবং সি ফাইলগুলি সন্ধান করুন যা "টিসি শিডিয়ুলিং ফ্রেমওয়ার্ক" প্রয়োগ করে
  2. শিরোনামটি দেখুন এবং কোডের লেখক সন্ধান করুন।
  3. "টিসি শিডিয়ুলিং ফ্রেমওয়ার্ক" এর ইমেল প্রোগ্রামাররা তাদের প্রয়োগের জন্য তাদের সাহিত্যের জন্য জিজ্ঞাসা করছেন।

এটিকে উদ্ধৃত করা অন্যান্য আরও নতুন কাগজপত্রগুলিও পরীক্ষা করে দেখার চেষ্টা করুন। এই ক্ষেত্রে গবেষণার ধারাবাহিকতা রয়েছে এমন আরও নতুন কাগজপত্র থাকতে পারে এবং আপনি যে প্রশ্নগুলি জিজ্ঞাসা করছেন সে সম্পর্কে আরও তথ্য অন্তর্ভুক্ত থাকতে পারে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.