Господа,
как объяснить что cisco рекомендует выбирать для голоса передаваемого по FRame-relay Bc = CIR/100 (меньше чем для данных)?Допустим, для определенности, CIR=64К, тогда для голоса устройство будет передавать обрабатывать не более BC=CIR/100 = 640 бит за каждый интервал времени TC=BC/CIR =10 мс. Остальные данные будут отбрасываться или буферизоваться (и то и другое не очень хорошо в условиях real-time трафика).
То есть мы заранее достаточно жестко ограничиваем форму голосовых данных: они не должны превышать 640 бит за 10 мс.
На мой взгляд гораздо лояльнее ситуация, когда BC=CIR/1, то есть мы ограничиваем размер передаваемых данных не боолее 64Кбит за 1 сек. При этом не накладываем других ограничений на форму трафика внутри этого интервала в 1 секунду. То есть за первую если нам захотелось мы можем передать допустим 1000 бит за первые 10 мс (без всякой буферизации!)...
http://www.cisco.com/warp/public/125/traffic_shaping_6151.html
"frame relay bc
The amount of data to send per each Tc interval in bits. Ideally for data PVCs Bc = CIR/8 so that Tc = 125msec. If we are doing voice on the PVC, then Bc = CIR/100 is preferable, so that the interval Tc = 10msec (as voice packets cannot tolerate a longer delay). The value of Bc by default is the CIR in bits."
Никто действительно не знает, или настолько глупый вопрос? :)
>Никто действительно не знает, или настолько глупый вопрос? :)
По значению BC вычисляется TC для механизма шейпинга.
Чтобы понять почему TC должен быть таким маленьким, почитайте что такое jitter (вариация задержки, дрожание). Начните с основ, никакой форум вам их не заменит.
>Чтобы понять почему TC должен быть таким маленьким, почитайте что такое
>jitter (вариация задержки, дрожание). Начните с основ, никакой форум вам их не заменит.Спасибо конечно за ответ, но что такое джиттер я в принципе представляю... :)
Возможно уважаемый знаток расскажет как связать джиттер и Tc?
Понятно, что чем меньше Tc тем более равномерным становится речевой трафик, проходящий обработку алгоритмом шейпинга... Однако за счет чего?
За счет буферизации при шейпинге IMHO. А разве буферизация уменьшает джиттер?
Вообще на мой взгляд алгоритм шейпинга только ухудшает качество речи, поскольку выравнивает трафик. И мне казалось что в отношении речи надо уменьшать влияние шейпинга, то есть увеличивать Tc...
ну что... совсем никто? :(
>>Чтобы понять почему TC должен быть таким маленьким, почитайте что
>трафик. И мне казалось что в отношении речи надо уменьшать влияние
>шейпинга, то есть увеличивать Tc...Tc это по сути единица квантования для джитера. При стандартном значении Tc для FRTS равном 125 мсек, задержка голосового пакета на один такт грубо говоря приведет к скачу задержки на 125 мс, это превышает все допустимые пределы. Поэтому Тс нужно уменьшать.
Что касается шейпинга, то он на голосовые пакеты влияет безусловно в худшую сторону и хорошо бы жить без него. Но реальный физический мир состоит из сплошных ограничений. У вас есть ограниченный канал, есть потоки данных которые стремятся занять весь этот канал. Без шейпинга у вас попросту кончится bandwidth и тогда вам станет уже не до джиттера, у вас нанутся отбрасываться голосовые пакеты.
>Tc это по сути единица квантования для джитера. При стандартном значении Tc для FRTS равном 125 мсек, задержка голосового пакета на один такт
>грубо говоря приведет к скачу задержки на 125 мс, это превышает
>все допустимые пределы. Поэтому Тс нужно уменьшать.Что-же это получается... cisco каждый раз ждет время Tc преже чем отправить данные размером Bc?
А зачем циске ждать? Она спокойно засекает время Тс и считает количество байт которое передается за это время через ее интерфейс. Как только количество байт превышает Bc она начинает дискартировать (или метить) вновьпришедшие кадры пока не закончится интервал Tc. В следующем интервале Тс повторяется то же самое. Разве не так?
Я уже задавал этот вопрос, но он к сожалению остался без ответа...
http://online.comptek.ru/index.xhtml?pr=&id_note_forum=58241...
>Что касается шейпинга, то он на голосовые пакеты влияет безусловно в худшую
>сторону и хорошо бы жить без него. Но реальный физический мир
>состоит из сплошных ограничений. У вас есть ограниченный канал, есть потоки
>данных которые стремятся занять весь этот канал. Без шейпинга у вас
>попросту кончится bandwidth и тогда вам станет уже не до джиттера,
>у вас нанутся отбрасываться голосовые пакеты.К вопросу о решении данной проблемы:
как вам такая идея: мы предсказываем (более или менее точно) какой всплеск трафика будет в следующий интервал времени Tc и сооветственно регулируем (в он-лайн режиме) параметр cir или Bc, (то есть адаптивно подстраиваем канал под трафик). Если предсказывать абсолютно точно, то можно IMHO обойтись без буферизации и отбрасывания реал-тайм трафика! Остальноиу трафику (второстепенному) можно отдеть остатки полосы... Что скажете?
>Что-же это получается... cisco каждый раз ждет время Tc преже чем отправитьЕсли в предыдущий момент времени отправлено Bc байт, то лимит на передачу исчерпан, циска делает паузу в Tc и буферизирует поступающие пакеты, если через Tc интервал посылать еще нельзя, то она снова ждет Tc чтобы пересчитать скорость данных и сравнить ее с CIR. Таким образом, Tс это единица квантования при шейпинге пакетов.
>данные размером Bc?
>>Как только
>количество байт превышает Bc она начинает дискартировать (или метить) вновьпришедшие кадры
>пока не закончится интервал Tc. В следующем интервале Тс повторяется то
>же самое. Разве не так?
Что такое "дискартировать"? Если превышен Bc, то пакеты помещаются в буфер, если кончается буфер, они отбрасываются. Но в любом случае пакет из буфера будет оправлен спустя N*Tc интервалов, поскольку механизм шейпига отрабатывается дискретно.
>К вопросу о решении данной проблемы:>как вам такая идея: мы предсказываем (более или менее точно) какой всплеск
>трафика будет в следующий интервал времени Tc и сооветственно регулируем (в
>он-лайн режиме) параметр cir или Bc, (то есть адаптивно подстраиваем канал
>под трафик). Если предсказывать абсолютно точно, то можно IMHO обойтись без
>буферизации и отбрасывания реал-тайм трафика! Остальноиу трафику (второстепенному) можно отдеть остаткиОтбрасывание происходит из-за несоответствия пропускной способности канала и входящего потока данных! Никакими ухищрениями этого изменить нельзя! Я давал ссылку на принципы материального мира. Задача шейпинга в том, чтобы в такой ситуации сохранить самые нужные пакеты и отбросить самые ненужные. Если же канал у нас неограниченный, то шейпинг не нужен в принципе.
>>Что-же это получается... 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 - предлагаемая схема прогнозирования.
>Так вот, в качестве предлагаемого решения: если мы будем на шаг вперед >предсказывать полосу, требующуюся для трафика голоса и динамически >подстраивать параметры CIR и BC в голосовом PVC? А другому PVC при этом >отдадим остатки полосы?Прошу-таки откликнуться.
IMHO теоретически такая схема должна работать.
А вот практически...
Хотелось бы услышать мнение людей, которые работают непосредственно с оборудованием. PLZ...
Ну что же, если совсем никто... и на этом спасибо!Заинтересовавшихся приглашаю на форум, посвященный телетрафику и особенностям его структуры.
(требуется регистрация)