>>Что-же это получается... cisco каждый раз ждет время Tc преже чем отправить данные размером Bc?
>
>Если в предыдущий момент времени отправлено Bc байт, то лимит на >передачу исчерпан, циска делает паузу в Tc
наверно не в Tc, а на время, оставшееся от Tc после передачи Bc
>и буферизирует поступающие пакеты, если через Tc интервал посылать еще нельзя,
не понял... почему нельзя?
>то она снова ждет Tc чтобы пересчитать скорость данных и сравнить ее с >CIR. Таким образом, Tс это единица квантования при шейпинге пакетов.
>Если превышен Bc, то пакеты помещаются в буфер, если
>кончается буфер, они отбрасываются. Но в любом случае пакет из буфера
>будет оправлен спустя N*Tc интервалов, поскольку механизм шейпига отрабатывается дискретно.
А что такое N? Разве содержимое буфера нельзя отправить сразу в следующем интервале Tc? Ну или за несколько следующих Tc, если данные, содержащиеся в буфере превышают Bc
Вообще кажется до меня начало доходить :)
Чем меньше Тс, тем чаще "очищается" буфер и, следовательно, тем меньше задержки, однако мне кажется здесь возникает другая проблема - чем меньше Tc, тем чаще наполняется этот буфер, что само по себе приводит к задержкам... Возможно здесь имеет смысл поискать оптимальное значение TC для конкретного трафика? Наверно Cisco и дает это "оптимальное"
значение ~10 мс?
>>К вопросу о решении данной проблемы:
>
>>как вам такая идея: мы предсказываем (более или менее точно) какой всплеск
>>трафика будет в следующий интервал времени Tc и сооветственно регулируем (в
>>он-лайн режиме) параметр cir или Bc, (то есть адаптивно подстраиваем канал
>>под трафик). Если предсказывать абсолютно точно, то можно IMHO обойтись без
>>буферизации и отбрасывания реал-тайм трафика! Остальноиу трафику (второстепенному) можно отдеть остатки
>
>Отбрасывание происходит из-за несоответствия пропускной способности канала и входящего потока данных! Никакими
>ухищрениями этого изменить нельзя! Я давал ссылку на принципы материального мира.
>Задача шейпинга в том, чтобы в такой ситуации сохранить самые нужные
>пакеты и отбросить самые ненужные.
Это все понятно... шейпинг корректирует, подстраивает трафик под канал. Я же говорю о том, что можно попробовать подстраивать канал под критичный трафик...
Представьте себе ситуацию: в одном магистральном физическом канале созданы два виртуальных PVC: один для реал-тайм трафика (голоса), другой - для http. В настоящее время для обеспечения QoS рекомендуется задать параметры шейпинга ( соотвтетсвующим образом выбранные параметры cir и bc для обоих PVC), можно попробовать как-нибудь даже дать приоритет PVC, в котором передается голос... и все...
В результате мы вынуждены будем мириться с неизбежным джиттером, буферизацией голосовых данных, что является результатом влияния шейпинга.
Так вот, в качестве предлагаемого решения: если мы будем на шаг вперед предсказывать полосу, требующуюся для трафика голоса и динамически подстраивать параметры CIR и BC в голосовом PVC? А другому PVC при этом отдадим остатки полосы?
Как это выглядит можно посмотреть и сравнить здесь:
http://vpetroff.nm.ru/Attach/Forecasting_2003_Petroff.pdf
На рис. 1а показан результат работы шейпинга
1б-полисинга
на рис. 2 - предлагаемая схема прогнозирования.
Вариант для распечатки
Маршрутизаторы CISCO и др. оборудование. (Public)
on
19-Фев-04, 10:54 (MSK)
