يمكنك إستخدام أداة TCP المساعدة للاختبار (TTCP) لقياس خرج TCP من خلال مسار IP. لكي تستخدمها، ابدأ تشغيل المستقبل على جانب واحد من المسار، ثم ابدأ تشغيل جهاز الإرسال على الجانب الآخر. يرسل جانب الإرسال عددا محددا من حزم TCP إلى جانب الاستقبال. في نهاية الاختبار، يعرض الجانبان عدد وحدات البايت المرسلة والوقت المنقضي للحزم لكي تمر من نهاية إلى أخرى. يمكنك عندئذ إستخدام هذه الأشكال لحساب الخرج الفعلي على الرابط. أحلت لمعلومات عامة على TTCP، شبكة أداء إختبار مع TTCP .
يمكن أن تكون الأداة المساعدة TTCP فعالة في تحديد معدل البت الفعلي لاتصال شبكة WAN أو مودم معين. ومع ذلك، يمكنك أيضا إستخدام هذه الميزة لاختبار سرعة الاتصال بين أي جهازين باستخدام اتصال IP بينهما.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، راجع اصطلاحات تلميحات Cisco التقنية.
يجب أن يكون قراء هذا المستند على دراية بما يلي:
يتطلب بروتوكول TTCP إصدار برنامج Cisco IOS® الإصدار 11.2 أو إصدار أعلى ومجموعات الميزات IP Plus (is-images) أو مزود الخدمة (p-images).
ملاحظة: إن الأمر ttcp هو أمر وضع مخفي غير مدعوم ذو امتياز. وعلى هذا النحو، قد يختلف توافره من إصدار من برنامج Cisco IOS software إلى آخر، قد لا يكون موجودا في بعض الإصدارات. تتطلب بعض الأنظمة الأساسية، على سبيل المثال، مجموعة ميزات Cisco IOS Enterprise لتنفيذ هذا النشاط.
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
تأكد من وجود اتصال IP بين الجهازين المشمولين في الاختبار.
قم بتنزيل برنامج TTCP وتثبيته لغير عملاء IOS، إذا لزم الأمر.
في المثال المبين أدناه، نحاول تحديد سرعة اتصال مودم بين كمبيوتر يعمل بنظام التشغيل Microsoft Windows وخادم وصول AS5300. على الرغم من أن العديد من الموضوعات والتوضيحات الواردة هنا خاصة باتصالات المودم، يمكن إستخدام أداة TTCP المساعدة بين أي جهازين.
أستخدم الأمر show modem operation-status (لاتصال المودم) للتحقق من معلمات الاتصال. بالنسبة لسيناريوهات الشبكة المحلية (LAN) أو شبكة الاتصال واسعة النطاق (WAN) الأخرى، لا تكون هذه الخطوة ضرورية.
customer-dialin-sj> show modem operational-status 1/51 Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: None ... !--- Output omitted ... Parameter #8 Connected Standard: V.90 Parameter #9 TX,RX Bit Rate: 45333,24000
يوضح هذا الإخراج الذي تم تحريره أن العميل متصل في V.90 بمعدل تنزيل يبلغ 45333 بت في الثانية ومعدل وصلة يبلغ 24000 بت في الثانية. تم تعطيل ضغط البيانات على مودم العميل. نظرا لأن نمط إختبار TTCP قابل للانضغاط بدرجة كبيرة، فإن أي ضغط بيانات من شأنه أن يحرف مقياسنا لسعة إخراج إرتباط المودم الحقيقية.
بدء تشغيل برنامج TTCPW على الكمبيوتر الشخصي (في نافذة DOS)، الذي يعمل كجهاز إستقبال. ارجع إلى ملف Readme المتوفر مع برنامج Windows TTCP للصياغة المناسبة.
C:\PROGRA~1\TTCPW> ttcpw -r -s ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket
قم بتشغيل مرسل TTCP (جهاز الإرسال) على AS5300. أترك معظم الإعدادات في الافتراضي، ما عدا عدد المخازن المؤقتة التي سيتم إرسالها. يكون العدد الافتراضي للمخازن المؤقتة هو 2048، والذي سيستغرق إختبار TTCP وقتا طويلا لإكماله. ومن خلال تقليل عدد المخازن المؤقتة، يمكننا إنهاء الاختبار في إطار زمني معقول.
في المثال المبين أدناه، نحاول تحديد سرعة اتصال مودم بين كمبيوتر يعمل بنظام التشغيل Microsoft Windows وخادم وصول AS5300. على الرغم من أن العديد من الموضوعات والتوضيحات الواردة هنا خاصة باتصالات المودم، يمكن إستخدام أداة TTCP المساعدة بين أي جهازين.
ملاحظة: حاول الحصول على لقطة لحالة تشغيل المودم (المنفذ)، كما هو موضح أعلاه، قبل بدء إختبار TTCP مباشرة.
customer-dialin-sj>ttcp transmit or receive [receive]: transmit !--- The AS5300 is the ttcp transmitter Target IP address: 10.1.1.52 ! -- Remote device (the Windows PC) IP address perform tcp half close [n]: use tcp driver [n]: send buflen [8192]: send nbuf [2048]: 50 !--- Number of buffers to transmit is now set to 50 (default is 2048 buffers) bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: buffering on writes [y]: show tcp information at end [n]: ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp ->10.1.1.52 ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 4128)
وهذا يتسبب في قيام Cisco IOS TTCP بإجراء اتصال TCP ب TTCPW (على جهاز Windows).
عندما يستقبل الكمبيوتر الشخصي طلب جلسة عمل TTCP، يعرض TTCPW رسالة مفادها أن الكمبيوتر الشخصي (TTCP) قبل جلسة عمل TTCP من عنوان IP للموجه:
ttcp-r: accept from 10.1.1.1
عند انتهاء مرسل بروتوكول TTCP من إرسال جميع بياناته، سيقوم كلا الجانبين بطباعة إحصائيات سعة المعالجة والانتهاء. في هذه الحالة، يوضح مرسل IOS TTCP:
ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp -> 10.1.1.52 ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 4128) ttcp-t: 409600 bytes in 84544 ms (84.544 real seconds) (~3 kB/s) +++ ttcp-t: 50 I/O calls ttcp-t: 0 sleeps (0 ms total) (0 ms average)
وعلى الجانب الآخر، يوضح مستقبل PC TTCPW:
ttcp-r: 409600 bytes in 8 4.94 seconds = 4.71 KB/sec +++ ttcp-r: 79 I/O calls, msec/call = 1101.02, calls/sec =0.93
عند هذه النقطة، قد تحتاج إلى أخذ لقطة أخرى من المودم أو المنفذ في حالة التشغيل. يمكن أن تكون هذه المعلومات مفيدة أثناء التحليل للتحقق مما إذا كان اتصال المودم، على سبيل المثال، قد تعرض لأي عمليات إعادة توجيه أو نوبات سريعة.
ونظرا لأنه من الشائع للغاية تقييم سرعات الاتصال بمعدل كيلوبت في الثانية أو 1000 بت في الثانية) بدلا من معدل الكيلوبت في الثانية (كيلوبايت في الثانية أو 1024 بايت في الثانية)، فيجب علينا إستخدام المعلومات الواردة من بروتوكول TTCP لحساب معدل البت (بالكيلوبت في الثانية). أستخدم عدد وحدات البايت المتلقاة ووقت النقل لحساب معدل البت الفعلي للاتصال.
قم بحساب معدل البت عن طريق تحويل عدد وحدات البايت إلى وحدات بت ثم قم بقسمة هذا على وقت النقل. في هذا المثال، تلقى كمبيوتر Windows 409600 بايت في 84.94 ثانية. يمكننا حساب معدل البت ليصبح (409600 بايت * 8 بت لكل بايت) مقسوما على 84. 94 ثانية=38577 بت في الثانية أو 38. 577 كيلوبت في الثانية.
ملاحظة: نتائج جانب جهاز الاستقبال أكثر دقة بعض الشيء، لأن جهاز الإرسال قد يعتقد أنه انتهى بعد إجرائه آخر عملية كتابة - أي قبل أن تكون البيانات قد إجتازت الارتباط بالفعل.
بالنسبة لسرعة الارتباط الاسمية التي تبلغ 45333 بت في الثانية (المحددة من الأمر show modem التنفيذي-status)، فإن هذه الكفاءة تبلغ 85 بالمائة. وهذه الكفاءة عادية نظرا لإجراء الوصول إلى الارتباط الخاص بأجهزة المودم (LAPm) و PPP و IP والنفقات الإضافية لرأس بروتوكول TCP. إذا كانت النتائج تختلف بشكل ملحوظ عن النتائج التي تتوقعها، فعليك تحليل الحالة التشغيلية وسجل المودم، وإذا لزم الأمر، إحصائيات المودم من جانب العميل لمعرفة ما قد يحدث للتأثير على الأداء (مثل رسائل الإرسال من جانب EC والرحلات السريعة وإعادة التدريب وما إلى ذلك).
بعد ذلك، قم بإجراء إختبار سعة معالجة الوصلة. وهذا مطابق لاختبار الارتباط السفلي، باستثناء أن Cisco IOS TTCP يعمل كجهاز إستقبال، وأن Windows TTCPW هو جهاز الإرسال. أولا، قم بإعداد الموجه كجهاز إستقبال، باستخدام المعلمات الافتراضية:
customer-dialin-sj>ttcp transmit or receive [receive]: perform tcp half close [n]: use tcp driver [n]: receive buflen [8192]: bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: rcvwndsize [4128]: delayed ACK [y]: show tcp information at end [n]: ttcp-r: buflen=8192, align=16384/0, port=5001 rcvwndsize=4128, delayedack=yes tcp
قم بتنشيط الكمبيوتر الشخصي كجهاز إرسال TTCP وحدد عنوان IP الخاص بالموجه. ارجع إلى الملف التمهيدي المتوفر مع برنامج Windows TTCP للصياغة المناسبة:
C:\PROGRA~1\ TTCPW>ttcpw -t -s -n 50 10.1.1.1 ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp -> 10.1.1.1 ttcp-t: socket ttcp-t: connect
يقوم مستقبل IOS بالإعلام عن النتائج التالية:
ttcp-r: accept from 10.1.1.52 (mss 1460, sndwnd 4096, rcvwnd 4128) ttcp-r: 409600 bytes in 23216 ms (23.216 real seconds) (~16kb/s) +++ ttcp-r: 280 I/O calls ttcp-r: 0 sleeps (0 ms total) (0 ms average)
تعرف هذه العملية بأنها سعة توصيل تبلغ 141144 بت في الثانية - أو نسبة ضغط تصل إلى 1:6 تقريبا مقارنة بمعدل وصلات اسمي يبلغ 24 كيلوبت في الثانية. هذه نتيجة مثيرة للاهتمام نظرا لتعطيل ضغط الأجهزة (التي حددناها من حالة تشغيل المودم show modem). ومع ذلك، أستخدم أمر IOS show compress للتحقق مما إذا كان أي ضغط برنامج قيد الاستخدام.
فيما يلي بعض الإرشادات العامة لاستخدام بروتوكول TTCP لقياس سعة معالجة مسار IP:
للحصول على نتائج ذات مغزى، يجب أن تتمتع الأجهزة المضيفة التي تشغل بروتوكول TTCP بوفرة من طاقة وحدة المعالجة المركزية نسبة إلى سرعة الارتباط. ويكون ذلك صحيحا عندما يكون الارتباط 45 كيلوبت/ثانية وتكون الأجهزة المضيفة في وضع الخمول AS5300 وكمبيوتر بسرعة 700 ميجاهرتز. وهذا ليس صحيحا إذا كان الارتباط هو 100baseT وكان أحد الأجهزة المضيفة هو موجه Cisco 2600
يعامل IOS البيانات التي يتم الحصول عليها من الموجه بشكل مختلف عن البيانات التي يتم توجيهها من خلال الموجه. في المثال أعلاه، على الرغم من أنه تم التفاوض حول ضغط Microsoft من نقطة إلى نقطة (MPPC) على الارتباط قيد الاختبار، فإن البيانات التي تم إرسالها بواسطة الموجه لم تستخدم ضغط البرامج، في حين أن البيانات التي تم إرسالها بواسطة الكمبيوتر الشخصي قد أستخدمت. وهذا هو السبب في أن سعة معالجة الوصلة كانت أكبر بكثير من سعة معالجة الوصلة المعزولة. لاختبار أداء روابط النطاق الترددي العالي، يجب عليك دائما الاختبار من خلال الموجهات.
لمسارات IP ذات النطاق الترددي الكبير * تأخر المنتج، من المهم إستخدام حجم نافذة TCP الكافي لإبقاء ممر البيانات ممتلئا. في حالة إرتباطات المودم، يكون حجم النافذة الافتراضي 4 كيلوبايت كافيا عادة. يمكنك تعزيز حجم نافذة IOS TCP باستخدام الأمر i p tcp window-size. ارجع إلى الوثائق المناسبة للأنظمة غير IOS.
هناك طريقة أخرى سهلة لاختبار معدل نقل البيانات عبر إرتباط مودم، وهي إستخدام أداة المصدر المفتوح Through-Putter . قم بتثبيت هذه الأداة على خادم ويب خلف خوادم Access وجعل عملاء Windows PC يستخدمون متصفح للاتصال بأداة Java. ويمكن بعد ذلك إستخدامه لتحديد معدل البيانات بسرعة على اتصال المودم. التطبيق الصغير لسعة معالجة المودم هذا هو أداة المصدر المفتوح ولا يدعمه مركز المساعدة التقنية ل Cisco. ارجع إلى ملف القراءة المزود مع الأداة للحصول على تعليمات تثبيت وتشغيل إضافية.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
09-Sep-2005 |
الإصدار الأولي |