Jump to content
Калькуляторы

шейпинг на MX80 burst size, delay buffer

Товарищи,

есть конфиг

 

traffic-control-profiles {
   SHAPE-300 {
       scheduler-map SCHEDULER_1;
       shaping-rate 285m burst-size 356250;
   }
}
interfaces {
   ge-1/1/0 {
       output-traffic-control-profile SHAPE-300;
   }
}

 

который с указанным burst-size 356250 дропает примерно 0,5% пакетов. Если оставляю дефолтный burst size (рассчитывается из Tc=100мс), то дропать начинает ISP, так как у него Tc=10мс.

Есть предположение, что размер буфера (Delay Buffer) для хранения пакетов которые превышают Burst Size слишком маленький и может уменьшаться так, чтобы соответствовать Burst Size. То есть хранит только тот излишек, который может уйти в следующую итерацию.

Так ли это?

Edited by rover-lt

Share this post


Link to post
Share on other sites

на таких скоростях делайте полисер и бурст побольше... шейпинг на скоростях больше мегабита не несет существенных преимуществ перед полисером.

Share this post


Link to post
Share on other sites

на таких скоростях делайте полисер и бурст побольше... шейпинг на скоростях больше мегабита не несет существенных преимуществ перед полисером.

в моем случае шейпинг несет значительные преимущества. Зачем мне делать берст такой величины, что будет обрезан вышестоящим провайдером?

Весь цимус в том, чтобы "обрезаемую" часть берста забуферизовать. И в моем случае всплески трафика превышают установленный аплинком берст в 3-10 раз

 

И кстати а что у вас показывает show interfaces queue ge-1/1/0

показывает, что дропает примерно 0,5-3% пакетов в зависимости от микроберстов в день

Queue: 7, Forwarding classes: af41, ef
 Queued:
   Packets              :     		143261696           		656 pps
   Bytes                :   		50760870638       		2215072 bps
 Transmitted:
   Packets              :     		142870852           		656 pps
   Bytes                :   		50400474648       		2215072 bps
   Tail-dropped packets :             		0             		0 pps
   RL-dropped packets   :             		0             		0 pps
   RL-dropped bytes 	:             		0             		0 bps
   RED-dropped packets  :                390844             		0 pps
	Low         		:                390844             		0 pps
	Medium-low          :             		0             		0 pps
	Medium-high 		:             		0             		0 pps
	High                :             		0             		0 pps
   RED-dropped bytes    :     		360395990             		0 bps
	Low         		:     		360395990             		0 bps
	Medium-low          :             		0             		0 bps
	Medium-high 		:             		0             		0 bps
	High                :             		0             		0 bps

Микроберсты до гигабита высотой и длиной до 100мс

Если оставляю дефолтный burst size (рассчитывается из Tc=100мс), то дропать начинает ISP, так как у него Tc=10мс.

Вот примерный график с поминутным снятием статистики:

post-6215-095741200 1456403586_thumb.png

если посмотреть Wireshark'ом, с интервалом в 0.001 сек, то будут всплески до 600mbit.

post-6215-020137200 1456406578_thumb.png

 

что совсем не радует TCP и приложения которые его используют.

post-6215-015145400 1456406731_thumb.png

Edited by rover-lt

Share this post


Link to post
Share on other sites

решилось путем установки q-pic-large-buffer, что разрешило ставить буфер передержки более чем на 10% от bandwidth и, соответственно, увеличением его до больших значений.

В Циске тупо ставишь размер буфера практически какой хочешь - и никаких перезагрузок.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.