فهم قوائم الانتظار العادلة والمقدرة المعتمدة على الفئة على ATM

خيارات التنزيل

  • PDF     (358.7 KB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
  • ePub     (93.3 KB)
    العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
  • Mobi (Kindle)     (112.9 KB)
    عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:١٥ نوفمبر ٢٠٠٧
معرّف المستند:10406

لغة خالية من التحيز

تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

المقدمة

يقدم هذا المستند مقدمة إلى قوائم انتظار حركة المرور باستخدام تقنية قوائم الانتظار العادلة والمقدرة المعتمدة على الفئة (CBWFQ).

تمكن قوائم الانتظار العادلة المرجحة (WFQ) الارتباطات البطيئة السرعة، مثل الارتباطات التسلسلية، من توفير معاملة عادلة لجميع أنواع حركة المرور. وهو يصنف حركة المرور إلى تدفقات مختلفة (المعروفة أيضا باسم المحادثات) استنادا إلى معلومات الطبقة الثالثة والطبقة الرابعة، مثل عناوين IP ومنافذ TCP. وهو يقوم بذلك دون مطالبتك بتحديد قوائم الوصول. وهذا يعني أن حركة المرور ذات النطاق الترددي المنخفض لها الأولوية بشكل فعال على حركة المرور ذات النطاق الترددي العريض العالي لأن حركة المرور ذات النطاق الترددي العريض الفائق تشارك وسائط الإرسال بالتناسب مع وزنها المعين. ومع ذلك، فإن WFQ له بعض القيود:

  • لا يمكن تحجيمه إذا زاد مقدار التدفق بشكل كبير.

  • لا يتوفر WFQ الأصلي على الواجهات عالية السرعة مثل واجهات ATM.

يوفر CBWFQ حلا لهذه القيود. بخلاف WFQ القياسي، يسمح CBWFQ لك بتعريف فئات حركة مرور البيانات وتطبيق المعلمات، مثل حدود النطاق الترددي وقائمة الانتظار، على هذه الفئات. يتم إستخدام النطاق الترددي الذي تقوم بتعيينه لفئة ما لحساب "وزن" هذه الفئة. يتم أيضا حساب وزن كل حزمة تطابق معايير الفئة من هذا الأمر. يتم تطبيق WFQ على الفئات (والتي يمكن أن تتضمن العديد من التدفقات) بدلا من التدفقات نفسها.

للحصول على مزيد من المعلومات حول تكوين CBWFQ، انقر فوق الارتباطات التالية:

قوائم الانتظار العادلة والمقدرة (لكل VC CBWFQ) المستندة إلى الفئة VC في موجهات Cisco 7200 و 3600 و 2600.

قوائم الانتظار العادلة والمقدرة المعتمدة على الفئة لكل VC على الأنظمة الأساسية المستندة إلى RSP.

قبل البدء

الاصطلاحات

للحصول على مزيد من المعلومات حول اصطلاحات المستندات، راجع اصطلاحات تلميحات Cisco التقنية.

المتطلبات الأساسية

لا توجد متطلبات أساسية خاصة لهذا المستند.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات المُقدمة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كنت تعمل في شبكة مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر قبل استخدامه.

الرسم التخطيطي للشبكة

لتوضيح كيفية عمل WFQ، لنستخدم الإعداد التالي:

wfq_illustrated.gif

في الإعداد الذي نستخدمه هنا، يمكن تخزين الحزم في إحدى قوائم الانتظار التالية:

  • قائمة انتظار الجهاز الأول في الإخراج الأول (FIFO) على مهايئ المنفذ ووحدة الشبكة النمطية.

  • قائمة الانتظار في برنامج Cisco IOS® (على ذاكرة إدخال/إخراج الموجه [I/O]) حيث يمكن تطبيق جودة الخدمة (QoS) بميزات مثل CBWFQ.

تخزن قائمة انتظار FIFO على مهايئ المنفذ الحزم قبل تجزئتها إلى خلايا للإرسال. عندما تكون قائمة الانتظار هذه ممتلئة، يشير مهايئ المنفذ أو وحدة الشبكة النمطية إلى برنامج IOS إلى أن قائمة الانتظار مزدحمة. تسمى هذه الآلية الضغط العكسي. عند إستلام هذه الإشارة، يتوقف الموجه عن إرسال الحزم إلى قائمة انتظار FIFO الخاصة بالواجهة ويخزن الحزم في برنامج IOS حتى يتم إلغاء إزدحام قائمة الانتظار مرة أخرى. عند تخزين الحزم في IOS، يمكن للنظام تطبيق ميزات جودة الخدمة مثل CBWFQ.

إعداد حد حلقة الإرسال

هناك مشكلة واحدة في آلية قوائم الانتظار هذه وهي أنه كلما زاد عدد قائمة انتظار FIFO على الواجهة كلما زاد التأخير قبل أن يتم إرسال الحزم في نهاية قائمة الانتظار هذه. قد يؤدي ذلك إلى مشاكل خطيرة في الأداء لحركة المرور الحساسة للتأخير مثل حركة المرور الصوتية.

يتيح لك أمر الدائرة الافتراضية الدائمة (PVC) tx-ring-limit إمكانية تقليل حجم قائمة انتظار FIFO.

interface ATMx/y.z point-to-point
      ip address a.b.c.d M.M.M.M
      PVC A/B 
       TX-ring-limit 
       service-policy output test

الحد (x) الذي يمكنك تحديده هنا إما عدد من الحزم (لموجهات Cisco 2600 و 3600) أو كمية الجسيمات (لموجهات Cisco 7200 و 7500).

تقليل حجم حلقة الإرسال له فائدتان:

  • يقلل مقدار انتظار الحزم الزمنية في قائمة انتظار FIFO قبل تجزئتها.

  • إنه يسرع إستخدام جودة الخدمة في برنامج IOS.

تأثير حد حلقة الإرسال

دعنا نلقي نظرة على تأثير حد حلقة الإرسال باستخدام الإعداد الموضح في الرسم التخطيطي للشبكة أعلاه. يمكن أن نفترض ما يلي:

  • يقوم مولد حركة المرور بإرسال حركة مرور البيانات (حزم سعة 1500 بايت) إلى جهاز التخزين، وهذه حركة المرور تزيد من تحميل PVC 0/102 بين الموجه 1 والموجه 2.

  • يحاول الموجه 3 إختبار الاتصال بالموجه 1.

  • يتم تمكين CBWFQ على الموجه 2.

الآن دعونا نلقي نظرة على تكوينين باستخدام حدود حلقة إرسال مختلفة لرؤية التأثير الذي يحتوي عليه.

مثال أ

في هذا المثال، قمنا بضبط حلقة الإرسال على ثلاثة (TX-ring-limit=3). هذا ما نراه عند إختبار اتصال الموجه1 من الموجه 3.

POUND#ping ip
     Target IP address: 6.6.6.6
     Repeat count [5]: 100000
     Datagram size [100]: 
     Timeout in seconds [2]: 
     Extended commands [n]: 
     Sweep range of sizes [n]: 
     Type escape sequence to abort.
     Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]
     Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

مثال ب

في هذا المثال، قمنا بضبط حلقة الإرسال على 40 (TX-ring-limit=40). هذا ما نراه عند إستخدام نفس إختبار الاتصال كما في المثال أ:

POUND#ping ip
     Target IP address: 6.6.6.6
     Repeat count [5]: 10000
     Datagram size [100]: 36
     Timeout in seconds [2]: 10
     Extended commands [n]: 
     Sweep range of sizes [n]: 
     Type escape sequence to abort.
     Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:
     !!!!!!!!!!!!.
     Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488

كما ترون هنا، كلما كان حد حلقة الإرسال أكبر، كلما كان وقت إختبار الاتصال والعودة أكبر (RTT). ويمكننا أن نستنتج من ذلك أن وجود حد كبير لحلقة الإرسال يمكن أن يؤدي إلى تأخيرات كبيرة في الإرسال.

كيفية عمل CBWFQ

الآن وقد رأينا تأثير حجم قائمة انتظار الأجهزة FIFO، دعونا نرى بالضبط كيفية عمل CBWFQ.

يقوم WFQ الأصلي بتعيين وزن لكل محادثة، ثم جدولة وقت الإرسال لكل حزمة من التدفقات المختلفة. الوزن هو دالة من أسبقية IP لكل تدفق، ووقت الجدولة يعتمد على حجم الحزمة. انقر هنا للحصول على مزيد من التفاصيل حول WFQ.

يقوم CBWFQ بتعيين وزن لكل فئة تم تكوينها بدلا من كل تدفق. يتناسب هذا الوزن مع النطاق الترددي المهيأ لكل فئة. وبشكل أكثر دقة، يعتمد الوزن على عرض النطاق الترددي للواجهة مقسوما على النطاق الترددي للفئة. وبالتالي، كلما كانت معلمة النطاق الترددي أكبر، كان الوزن أقل.

يمكننا حساب وقت جدولة الحزمة باستخدام الصيغة التالية: 

scheduling tail_time= queue_tail_time + pktsize * weight

إجمالي تقسيم النطاق الترددي للواجهة

دعنا نلقي نظرة على كيفية قيام الموجه بتقسيم النطاق الترددي الإجمالي للواجهة بين الفئات المختلفة. لخدمة الفئات، يستخدم الموجه قوائم انتظار التقويم. تقوم كل من قوائم انتظار التقويم هذه بتخزين الحزم التي يجب إرسالها في نفس SCHEDULE_TAIL_TIME. يقوم الموجه بعد ذلك بخدمة قوائم انتظار التقويم هذه واحدة في كل مرة. لننظر إلى هذه العملية:

  1. إذا حدث إزدحام على مهايئ المنفذ عند وصول حزمة إلى واجهة الإخراج، فهذا يؤدي إلى قوائم الانتظار في IOS (CBWFQ في هذه الحالة).

  2. يقوم الموجه بحساب وقت جدولة للحزمة القادمة هذه وتخزينها في قائمة انتظار التقويم المطابقة لوقت الجدولة هذا. يمكن تخزين حزمة واحدة فقط لكل فئة في قائمة انتظار تقويم معينة.

  3. عندما يحين وقت خدمة قائمة انتظار التقويم التي تم تخزين الحزمة فيها، يقوم IOS بإخلاء قائمة الانتظار هذه وإرسال الحزم إلى قائمة انتظار FIFO على محول المنفذ نفسه. يتم تحديد حجم قائمة انتظار FIFO هذه بواسطة حد حلقة الإرسال الموضح أعلاه.

  4. إذا كانت قائمة انتظار FIFO صغيرة جدا بحيث لا تكفي لملائمة كافة الحزم التي يتم الاحتفاظ بها في قائمة انتظار التقويم التي تمت صيانتها، يقوم الموجه بإعادة جدولة الحزم التي لا يمكن تخزينها لوقت الجدولة التالي (المقابل لوزن الحزم) ووضعها في قائمة انتظار التقويم الموضح.

  5. عندما يتم كل ذلك، يقوم مهايئ المنفذ بمعالجة الحزم في قائمة انتظار FIFO الخاصة به ويرسل الخلايا على السلك وينقل IOS إلى قائمة انتظار التقويم التالية.

    بفضل هذه الآلية، تستلم كل فئة إحصائيا جزءا من عرض نطاق الواجهة المطابق للمعلمات التي تم تكوينها لها.

آلية قائمة انتظار التقويم مقابل حجم حلقة الإرسال

دعنا نلقي نظرة على العلاقة بين آلية قائمة انتظار التقويم وحجم حلقة الإرسال. تتيح حلقة الإرسال الصغيرة بدء تشغيل جودة الخدمة بسرعة أكبر وتقليل زمن الوصول للحزم التي تنتظر أن يتم إرسالها (وهو أمر مهم لحركة المرور الحساسة للتأخير مثل الصوت). أما إذا كان صغير جدا، فقد يتسبب في معدل إخراج أقل لبعض الفئات. وذلك نظرا لأنه قد يلزم إعادة جدولة الكثير من الحزم إذا لم تتمكن حلقة الإرسال من إستيعابها.

للأسف، لا توجد قيمة مثالية لحجم حلقة الإرسال والطريقة الوحيدة للعثور على أفضل قيمة هي عن طريق التجربة.

مشاركة النطاق الترددي

يمكننا النظر إلى مفهوم مشاركة عرض النطاق باستخدام الإعداد المبين في الرسم التخطيطي للشبكة، أعلاه. ينتج مولد الحزمة تدفقات مختلفة ويرسلها إلى جهاز المغسلة. المبلغ الإجمالي لحركة المرور الممثلة بهذه التدفقات كاف للتحميل الزائد على PVC. لقد قمنا بتطبيق CBWFQ على الموجه 2. فيما يلي الشكل الذي ستبدو عليه هيئتنا: 

access-list 101 permit ip host 7.0.0.200 any 
   access-list 101 permit ip host 7.0.0.201 any 
   access-list 102 permit ip host 7.0.0.1 any 
   ! 
   class-map small 
     match access-group 101 
   class-map big 
     match access-group 102
   !
   policy-map test
   policy-map test 
     small class 
      bandwidth <x>
     big class 
      bandwidth <y>
    interface atm 4/0.102 
     pvc 0/102 
       TX-ring-limit 3 
       service-policy output test 
       vbr-nrt 64000 64000

في المثال الذي ذكرناه، فإن الموجه2 هو موجه Cisco 7200. وهذا مهم لأن حد حلقة الإرسال يتم التعبير عنه في الجسيمات، وليس الحزم. يتم وضع الحزم في قائمة انتظار FIFO لمهايئ المنفذ بمجرد توفر جسيم حر، حتى إذا كان هناك حاجة إلى أكثر من جسيم واحد لتخزين الحزمة.

ما هو الجسيم؟

وبدلا من تخصيص قطعة واحدة من الذاكرة المتجاورة للمخزن المؤقت، فإن التخزين المؤقت للجسيمات يعمل على تخصيص أجزاء الذاكرة غير المتجاورة (المبعثرة)، والتي يطلق عليها اسم الجسيمات، ثم يربطها معا لتكوين مصد منطقي واحد للحزم. ويسمى هذا مخزن جسيمات مؤقت. في مثل هذا المخطط، يمكن أن تنتشر الحزمة عبر جسيمات متعددة.

في الموجه 7200 الذي نستخدمه هنا، حجم الجسيمات هو 512 بايت.

يمكننا التحقق مما إذا كانت موجهات Cisco 7200 تستخدم جسيمات باستخدام الأمر show buffers: 

router2#show buffers
     [snip]
     Private particle pools: 
     FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):
          0 in free list (0 min, 400 max allowed)
          400 hits, 0 fallbacks
          400 max cache size, 271 in cache
     ATM4/0 buffers, 512 bytes (total 400, permanent 400): 
          0 in free list (0 min, 400 max allowed)
          400 hits, 0 fallbacks
          400 max cache size, 0 in cache

الاختبار A

يتم ملء الصفوف "الصغيرة" و"الكبيرة" التي نستخدمها في هذا الاختبار بالطريقة التالية:

  • فئة صغيرة - لقد قمنا بتهيئة معلمات النطاق الترددي إلى 32 كيلوبت/ثانية. تقوم هذه الفئة بتخزين عشر حزم بحجم 1500 بايت من 7.0.0.200، تليها عشر حزم بحجم 1500 بايت من 7.0.0.201

  • فئة كبيرة - لقد قمنا بتهيئة معلمة النطاق الترددي بسرعة 16 كيلوبت في الثانية. تقوم هذه الفئة بتخزين تدفق واحد من عشر حزم سعة 1500 بايت من 7.0.0.1.

يرسل مولد حركة المرور مجموعة من الحركة المرورية الموجهة إلى جهاز المغسلة بسرعة 100 ميجابت في الثانية إلى الموجه 2 بالترتيب التالي:

  1. عشر حزم من 7. 0. 0.1.

  2. عشر حزم من 7. 0. 0.200.

  3. عشر حزم من 7. 0. 0.201.

التحقق من وزن التدفق

دعونا ننظر إلى الوزن المطبق على التدفقات المختلفة. للقيام بذلك، يمكننا إستخدام الأمر show queue atm x/y.z.

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated) 

  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

عند وضع جميع الحزم من 7.0.0.200 في قائمة الانتظار خارج الموجه، يمكننا أن نرى ما يلي:

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)
 
  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255
  
  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

كما ترى هنا، فإن التدفقات من 7.0.0.200 و 7.0.0.201 لها نفس الوزن (128). هذا الوزن هو نصف حجم الوزن المخصص للتدفق من 7.0.0.1 (256). وهذا يماثل حقيقة أن النطاق الترددي للفئة الصغيرة لدينا هو ضعف حجم الفئة الكبيرة لدينا.

التحقق من توزيع النطاق الترددي

إذا كيف يمكننا التحقق من توزيع عرض النطاق بين التدفقات المختلفة ؟ يتم إستخدام أسلوب قوائم انتظار FIFO في كل فئة. يتم ملء صفنا الصغير بعشر حزم من التدفق الأول وعشر حزم من التدفق الثاني. تتم إزالة التدفق الأول من الفئة الصغيرة بسرعة 32 كيلوبت في الثانية. وبمجرد إرسالها، يتم إرسال الحزم العشر من التدفق الآخر أيضا. في هذه الأثناء، تتم إزالة الحزم من فئتنا الكبيرة بسرعة 16 كيلوبت في الثانية.

يمكننا أن نرى أنه، بما أن مولد حركة المرور يرسل قوة دفع بسرعة 100 ميجابت في الثانية، PVC سيتم تحميله أكثر من اللازم. مهما، بما أن هناك ما من حركة مرور على ال PVC عندما يبدأ الاختبار، وبما أن الربط من 7.0.0.1 هي الأولى التي تصل إلى المسحاج تخديد، بعض ربط من 7.0.0.1 سيتم إرسالها قبل أن يبدأ CBWFQ بسبب الازدحام (بمعنى آخر، قبل أن تكون حلقة الإرسال ممتلئة).

بما أن حجم الجسيم هو 512 بايت وحجم حلقة الإرسال هو ثلاثة جسيمات، يمكننا أن نرى أن هناك حزمتين من 7.0.0.1 يتم إرسالهما قبل حدوث الازدحام. يرسل أحدها على الفور على السلك، بينما يخزن الآخر في الجسيمات الثلاثة التي تشكل قائمة انتظار FIFO لمهايئ المنفذ.

يمكننا رؤية تصحيح الأخطاء أدناه على جهاز المغسلة (والذي هو ببساطة موجه): 

Nov 13 12:19:34.216: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 1482, rcvd 4 
   Nov 13 12:19:34.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- congestion occurs here.


   Nov 13 12:19:34.640: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:34.856: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.280: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.496: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.920: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.136: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.560: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.988: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.200: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.416: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.628: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.840: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.056: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.268: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.480: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.696: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.908: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.136: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.348: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.776: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.988: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.200: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.416: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

بما أن أحجام الحزمة لكل من التدفقات هي نفسها، بناء على صيغة وقت الجدولة، يجب أن نرى حزمتين من فئتنا الصغيرة يتم إرسالهما لكل حزمة من فئتنا الكبيرة. هذا هو بالضبط ما نراه في التصحيح أعلاه.

الاختبار B

للاختبار الثاني، دعونا نوزع الفصول بالطريقة التالية:

  • فئة صغيرة - لقد قمنا بتهيئة معلمة النطاق الترددي إلى 32 كيلوبت/ثانية. يتم إنشاء عشر حزم بحجم 500 بايت من 7.0.0.200، متبوعة بعشر حزم بحجم 1500 بايت من 7.0.0.201.

  • فئة كبيرة - لقد قمنا بتهيئة معلمة النطاق الترددي بسرعة 16 كيلوبت في الثانية. تقوم الفئة بتخزين تدفق واحد يبلغ 1500 بايت للحزم القادمة من 7.0.0.1.

يرسل مولد حركة المرور مجموعة من البيانات بسرعة 100 ميجابت في الثانية إلى الموجه 2 بالترتيب التالي:

  1. عشر حزم سعة 1500 بايت من 7. 0.0.1.

  2. عشر حزم سعة 500 بايت من 7. 0. 0.200.

  3. عشر حزم سعة 1500 بايت من 7. 0. 0.201.

يتم تكوين FIFO في كل فئة.

التحقق من وزن التدفق

تتمثل الخطوة التالية في التحقق من الوزن المطبق على التدفقات المصنفة:

alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 23/512/64/0 (size/max total/threshold/drops) 
      Conversations  2/3/16 (active/max active/max total)  
      Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 15/128/0/0/0    
     Conversation 25, linktype: ip, length: 494 
     source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 

   alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 13/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 5/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63,

كما يمكنك أن ترى في المخرجات أعلاه، تلقى التدفقات من 7.0.0.200 و 7.0.0.201 الوزن نفسه (128). هذا الوزن هو نصف حجم الوزن المعين للتدفق من 7.0.0.1. هذا يماثل حقيقة أن للصف الصغير عرض نطاق ضعف حجم فئتنا الكبيرة.

التحقق من توزيع النطاق الترددي

يمكننا إنتاج التصحيح التالي من جهاز البالوعة: 

Nov 14 06:52:01.761: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:01.973: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- Congestion occurs here.
 

   Nov 14 06:52:02.049: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.121: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.193: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.269: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.341: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.413: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.629: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:02.701: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.773: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.849: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.921: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:03.149: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.361: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.572: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.788: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.000: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.212: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.640: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.852: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.280: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.492: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.920: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.132: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

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

أوقات الجدولة

دعنا نلقي نظرة أكثر قربا على أوقات الجدولة لكل حزمة. يتم حساب وقت جدولة الحزم باستخدام الصيغة التالية: 

scheduling tail_time= sub_queue_tail_time + pktsize *
     weight

لأحجام حزم مختلفة، يستخدم وقت الجدولة الصيغة التالية: 

500 bytes (small class): scheduling tail_time = x + 494 * 128
     = x + 63232 
     1500 bytes (small class): scheduling tail_time = x + 1494 *
     128 = x + 191232 
     1500 bytes (big class): scheduling tail_time = x + 1494 *
     256 = x + 382464

من هذه الصيغ، يمكننا أن نرى أن ست حزم بحجم 500 بايت من فئتنا الصغيرة يتم إرسالها لكل حزمة بحجم 1500 بايت من فئتنا الكبيرة (كما هو موضح في إخراج تصحيح الأخطاء أعلاه).

كما يمكننا أن نرى أنه يتم إرسال حزمتين بحجم 1500 بايت من فئتنا الصغيرة للحصول على حزمة واحدة بحجم 1500 بايت من فئتنا الكبيرة (كما هو موضح في إخراج تصحيح الأخطاء أعلاه).

من إختباراتنا اعلاه، يمكننا ان نستنتج ما يلي:

  • يحدد حجم حلقة الإرسال (TX-ring-limit) مدى سرعة بدء آلية قوائم الانتظار في العمل. يمكننا رؤية التأثير مع زيادة Ping RTT عند زيادة حد حلقة الإرسال. وبالتالي، إذا قمت بتنفيذ CBWFQ أو قوائم انتظار المهلة المنخفضة [LLQ]، فعليك مراعاة تقليل حد حلقة الإرسال.

  • يسمح CBWFQ بالتقاسم العادل للنطاق الترددي للواجهة بين الفئات المختلفة.

معلومات ذات صلة

محفوظات المراجعة

المراجعة تاريخ النشر التعليقات
1.0
15-Nov-2007
الإصدار الأولي

هل كان هذا المستند مفيدًا؟

Feedbackالتعليقات

اتصل بنا