rover-lt Опубликовано 24 февраля, 2016 (изменено) Товарищи, есть конфиг 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. То есть хранит только тот излишек, который может уйти в следующую итерацию. Так ли это? Изменено 24 февраля, 2016 пользователем rover-lt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 25 февраля, 2016 на таких скоростях делайте полисер и бурст побольше... шейпинг на скоростях больше мегабита не несет существенных преимуществ перед полисером. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 25 февраля, 2016 При таких скоростях и таком размере берста (356250) это равносильно тому что что берста нет вообще Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 25 февраля, 2016 И кстати а что у вас показывает show interfaces queue ge-1/1/0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rover-lt Опубликовано 25 февраля, 2016 (изменено) на таких скоростях делайте полисер и бурст побольше... шейпинг на скоростях больше мегабита не несет существенных преимуществ перед полисером. в моем случае шейпинг несет значительные преимущества. Зачем мне делать берст такой величины, что будет обрезан вышестоящим провайдером? Весь цимус в том, чтобы "обрезаемую" часть берста забуферизовать. И в моем случае всплески трафика превышают установленный аплинком берст в 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мс. Вот примерный график с поминутным снятием статистики: если посмотреть Wireshark'ом, с интервалом в 0.001 сек, то будут всплески до 600mbit. что совсем не радует TCP и приложения которые его используют. Изменено 25 февраля, 2016 пользователем rover-lt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rover-lt Опубликовано 26 февраля, 2016 решилось путем установки q-pic-large-buffer, что разрешило ставить буфер передержки более чем на 10% от bandwidth и, соответственно, увеличением его до больших значений. В Циске тупо ставишь размер буфера практически какой хочешь - и никаких перезагрузок. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...