| STAB(8) | Linux | STAB(8) |
نام (NAME)
tc-stab - دستکاریهای عمومی جدول اندازه بسته
خلاصه دستور (SYNOPSIS)
tc qdisc add ... stab
[ mtu BYTES ] [ tsize SLOTS ]
[ mpu BYTES ] [ overhead BYTES ]
[ linklayer { adsl | atm | ethernet } ] ...
گزینهها (OPTIONS)
برای مشاهده توضیحات مربوط به BYTES، لطفاً به بخش UNITS در صفحه راهنمای tc(8) مراجعه کنید.
- mtu
-
حداکثر اندازه بستهای که جدول اندازه برای آن ایجاد میشود؛ در صورت عدم تعیین صریح، مقدار پیشفرض 2048 در نظر گرفته میشود. - tsize
-
اندازه الزامی جدول؛ در صورت عدم تعیین صریح، مقدار پیشفرض 512 در نظر گرفته میشود. - mpu
-
حداقل اندازه بسته که در محاسبات به کار میرود. - overhead
-
سربار اندازه به ازای هر بسته (میتواند منفی باشد) که در محاسبات به کار میرود. - linklayer
-
مشخصات الزامی لایه پیوند (linklayer).
توضیحات (DESCRIPTION)
جداول اندازه (size tables) امکان دستکاری اندازه بستهها را به همان شکلی که کل چارچوب زمانبندی (scheduler) میبیند فراهم میکنند (البته اندازه واقعی بسته دستنخورده باقی میماند). اندازه تعدیلشده بسته فقط یکبار محاسبه میشود - زمانی که یک انضباط صف (qdisc) بسته را در صف قرار میدهد (enqueue). صفبندی اولیه در ریشه (root enqueue)، اندازه را با اندازه واقعی بسته مقداردهی اولیه میکند.
هر qdisc میتواند از یک جدول اندازه متفاوت استفاده کند، اما اندازه تعدیلشده در ناحیهای ذخیره میشود که بین کل سلسلهمراتب qdisc متصل به رابط مشترک است. پیامد این امر آن است که اگر چنین ساختاری داشته باشید، آخرین qdisc دارای stab در یک زنجیره اولویت یافته و «برنده» میشود. برای مثال، HFSC را با یک pfifo ساده متصل به یکی از کلاسهای برگ آن در نظر بگیرید. اگر برای آن qdisc مربوط به pfifo گزینه stab تعریف شده باشد، مقادیر طول محاسبهشده در حین صفبندی HFSC را رونویسی (override) خواهد کرد؛ و به نوبه خود، هر زمان که HFSC بخواهد بستهای را از صف خارج کند (dequeue)، از اندازهای بالقوه نامعتبر در محاسبات خود استفاده خواهد کرد. پیکربندیهای عادی معمولاً فقط در qdisc ریشه دارای stab تعریفشده هستند، اما امکان رونویسیهای بعدی، انعطافپذیری بیشتری را برای پیکربندیهای غیرمعمول فراهم میکند.
جدول اندازه اولیه توسط ابزار tc و با استفاده از پارامترهای mtu و tsize محاسبه میشود. الگوریتم اندازه هر اسلات را برابر با کوچکترین مقدار از توانهای ۲ قرار میدهد، به طوری که کل mtu توسط جدول اندازه پوشش داده شود. نیازی نیست که tsize یا mtu مقداری از توانهای ۲ باشند، بنابراین جدول اندازه معمولاً مقداری بیش از آنچه برای mtu لازم است را پشتیبانی خواهد کرد.
برای مثال، با mtu = 1500 و tsize = 128، یک جدول با 128 اسلات ایجاد خواهد شد که در آن اسلات 0 متناظر با اندازههای 0-16، اسلات 1 متناظر با 17 - 32، ... و اسلات 127 متناظر با 2033 - 2048 خواهد بود. اندازههای اختصاصیافته به هر اسلات به پارامتر linklayer بستگی دارد.
محاسبات stab برای موارد غیرعادی نیز ایمن است؛ برای مثال زمانی که اندازه اختصاصیافته به یک اسلات بزرگتر از 2^16-1 باشد (اگرچه در این حالت دقت محاسبه کاهش مییابد).
در طول بخش مربوط به هسته برای تعدیل اندازه بسته، مقدار overhead به اندازه اصلی افزوده شده و سپس اسلات محاسبه خواهد شد. اگر اندازه منجر به سرریز شود، برای به دست آوردن اندازه نهایی بیش از ۱ اسلات استفاده خواهد شد. این موضوع مسلماً بر دقت تأثیر میگذارد، اما تنها به عنوان یک سازوکار محافظتی در برابر شرایط غیرعادی است.
در حال حاضر دو روش برای ایجاد مقادیر ذخیرهشده در جدول اندازه وجود دارد - اترنت (ethernet) و atm (adsl):
- ethernet
-
این اساساً یک نگاشت ۱ به ۱ (1-1) است؛ بنابراین بر اساس مثال فوق (با صرفنظر موقت از mpu) اسلات 0 دارای مقدار 8، اسلات 1 دارای مقدار 16 و به همین ترتیب تا اسلات 127 با مقدار 2048 خواهد بود. توجه داشته باشید که باید mpu > 0 مشخص شده باشد، و اسلاتهایی که مقداری کمتر از مقدار تعیینشده توسط mpu دریافت کنند، به جای آن مقدار mpu را دریافت خواهند کرد. اگر mpu را مشخص نکنید، جدول اندازه اصلاً ایجاد نخواهد شد (چرا که هیچ تفاوتی ایجاد نمیکرد)، هرچند هر مقدار overhead در طول محاسبات لحاظ خواهد شد. - atm, adsl
-
لایه پیوند ATM از سلولهای ۵۳ بایتی تشکیل شده است که هر یک از آنها ۴۸ بایت برای بار داده (payload) فراهم میکنند. همچنین تمامی سلولها باید به طور کامل پر شوند، بنابراین در صورت لزوم برای آخرین سلول از لایهگذاری (padding) استفاده میشود.
هنگامی که جدول اندازه محاسبه میشود، اندازه تعدیلشدهای که به درستی در کمترین تعداد سلول جای گیرد به یک اسلات اختصاص مییابد. به عنوان مثال، یک بسته ۱۰۰ بایتی نیازمند سه بار داده ۴۸ بایتی است، بنابراین اندازه نهایی نیازمند ۳ سلول ATM خواهد بود - یعنی ۱۵۹ بایت.
برای جداول اندازه ATM، اسلاتهایی با اندازه ۱۶ بایت کاملاً کافی هستند. مقادیر پیشفرض mtu و tsize اسلاتهایی با اندازه ۴ بایت ایجاد میکنند.
سربارهای متداول (TYPICAL OVERHEADS)
مقادیر زیر برای سناریوهای مختلف adsl متداول هستند (بر اساس [1] و [2]):
LLC based:
PPPoA - 14 (PPP - 2, ATM - 12) PPPoE - 40+ (PPPoE - 8, ATM - 18, ethernet 14, possibly FCS - 4+padding) Bridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding) IPoA - 16 (ATM - 16)
VC Mux based:
PPPoA - 10 (PPP - 2, ATM - 8) PPPoE - 32+ (PPPoE - 8, ATM - 10, ethernet 14, possibly FCS - 4+padding) Bridged - 24+ (ATM - 10, ethernet 14, possibly FCS - 4+padding) IPoA - 8 (ATM - 8)
چند نکته مهم در مورد سربارهای فوق وجود دارد:
- پروتکل IPoA در حالت LLC به جای LLC-NLPID نیازمند SNAP است (به rfc2684 مراجعه کنید) - این دلیل آن است که در عمل فضای بیشتری نسبت به PPPoA اشغال میکند.
- در موارد نادر، ممکن است FCS در پروتکلهایی که شامل فریمهای اترنت هستند (Bridged و PPPoE) حفظ شود. در چنین شرایطی، هرگونه لایهگذاری (padding) ویژه اترنت که اندازه فریم ۶۴ بایتی را تضمین کند نیز باید لحاظ شود (به RFC2684 مراجعه کنید). به عبارت دیگر، این امر همچنین تضمین میکند که هر بستهای که ارسال میکنید دستکم ۲ سلول atm اشغال خواهد کرد. شما باید mpu را بر همین اساس تنظیم کنید.
- هنگامی که به جدول اندازه مراجعه میشود و شما ترافیک را به خاطر یک مودم/مسیریاب دیگر شکلدهی (shape) میکنید، یک سرآیند اترنت (بدون لایهگذاری) از قبل به طول اولیه بسته اضافه شده است. در این حالت، باید با کسر ۱۴ از سربارهای بالا، این موضوع را جبران کنید. اگر شکلدهی ترافیک را مستقیماً روی مسیریاب (مثلاً با مودم speedtouch usb) و با استفاده از دیمن ppp انجام میدهید، در حال استفاده از رابط ip خام بدون لایه ۲ زیرین هستید و بنابراین چیزی اضافه نخواهد شد.
برای توضیحات جامعتر، لطفاً به [1] و [2] مراجعه فرمایید.
ملاحظات کارتهای شبکه اترنت (ETHERNET CARDS CONSIDERATIONS)
اغلب فراموش میشود که کارتهای شبکه امروزی (حتی مدلهای ارزانقیمت روی مادربوردهای دسکتاپ) یا درایورهای آنها معمولاً از سازوکارهای مختلف تخلیه بار پردازشی (offloading) پشتیبانی میکنند. در چارچوب شکلدهی ترافیک (traffic shaping)، قابلیتهای 'tso' و 'gso' ممکن است به دلیل محاسبه قطعات عظیم TCP در زمان شکلدهی ترافیک (شامل محاسبات stab)، اثرات نامطلوبی ایجاد کنند. برای رابطهای دارای نرخ ارسال (uplink) کند، مناسب است که با استفاده از ethtool قابلیتهای تخلیه بار پردازشی را غیرفعال کنید.
همچنین ببینید (SEE ALSO)
tc(8), tc-hfsc(7), tc-hfsc(8),
[1] http://ace-host.stuart.id.au/russell/files/tc/tc-atm
[2] http://www.faqs.org/rfcs/rfc2684.html
لطفاً گزارشهای اشکال و وصلهها را به آدرس زیر ارسال کنید: <netdev@vger.kernel.org>
نویسنده (AUTHOR)
صفحه راهنما توسط Michal Soltys (soltys@ziu.info) ایجاد شده است.
| 31 October 2011 | iproute2 |