The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Bandwidth - Определения и параметры (cisco bandwidth serial)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: cisco, bandwidth, serial,  (найти похожие документы)
_ RU.CISCO (2:5077/15.22) __________________________________________ RU.CISCO _ From : Yuri A. Selivanov 2:5020/400 24 Dec 99 10:51:42 Subj : Bandwidth - Определения и параметры _______________________________________________________________________________ From: "Yuri A. Selivanov" <uri@tomsknet.ru> Serge Turchin <tsv@haunt.amt.ru> wrote in message news:83tl0b$dvv$2@jumbo.demos.su... > Yuri A. Selivanov (uri@tomsknet.ru) wrote: > [...skipped] > Так я на это и не намекал, просто волшебные константы должны из чего-то > выводиться. [...skipped] > Hу к случайному процессу [доступа] нужно еще добавить модель трафика по длинам > пакетов (на самых коротких пакетах действительно в несколько раз падает > эффективная пропускная способность сети из-за межпакетного гэпа) и характеру > обмена (tcp или udp это или смесь в какой-то пропорции, а может вообще IPX), > учесть как ведут себя наиболее популярные _реализации_ стеков протоколов со > скользящим окном, в какой пропорции они имеются в сети и т.д. и т.п. Боюсь, > что это тема для докторской, при этом точность ответа будет плюс-минус > километр и зависима от того, что в эти модели будет заложено. Явно, что > никакой речи о втором, а тем более третьем знаке после запятой быть не может. Справедливо... > > Влезая в столь горячую дискуссию, я всего лишь хотел еще раз обратить > > внимание на то, что реальная пропускная способность Ethernet, со стороны > > приложений верхнего уровня, отличается от скорости передачи в физическом > > канале, и в некоторых случаях весьма значительно. > Hу я думаю это и так все прекрасно знают. Hо ведь thread не на пустом месте начался..... > А вот конкретное число бессмысленно, > потому, что оно зависит от сотен параметров и факторов. Конечно можно > поставить задачу так, что N станций пускают M пакетов/сек длиной Lср > байт, и получить точное число, но что оно будет характеризовать? В общем случае, особого физического смысла в нем не будет -- слишком уж размыт моделируемый процесс. Еще раз спасибо за комментарии, в завершение хочу все-таки объяснить происхождение "мировой константы" (aka "magic const"): Определения и параметры: ------------------------------- Пропускная способность физического канала связи -- R=10 МБит/с Битовый интервал BT -- время, необходимое для передачи одного бита информационной последовательности (для 10 Мбит 1BT=0.1мкс). Структура кадра IEEE 802.3 (Raw) --------------------------------------- Preamble 56 bits H SFD(SOF) 8 bits e --------------------------------------- a DA 48 bits d --------------------------------------- e SA 48 bits r --------------------------------------- Length 16 bits --------------------------------------- Data 46-1500 bytes --------------------------------------- FCS CRC-32 32 bits Trailer --------------------------------------- Суммарная длина кадра L с учетом преамбулы, заголовка и трейлера, бит/байт минимальная -- 576/72 максимальная -- 12208/1526 Tmin - время, необходимое для передачи кадра минимальной длины: 576BT = 57.6мкс Tmax - время, необходимое для передачи кадра минимальной длины: 12208BT = 1.22мс Простая задержка распространения (Simple Path Delay, SPD) между двумя станциями (one direction). Полное время задержки распространения (Path Delay Value, PDV) -- равное 2*SPD и характеризующее время двойного оборота (round trip) кадра между MAC-подуровнями станций. Окно коллизий (collision window) T -- PDV между наиболее удаленными станциями сегмента или PDVmax. Максимальная величина окна коллизий (или время канала -- slot time) определяется стандартами IEEE как 512ВТ, что составляет 52.1мкс, что для надежного распознавания коллизий должно быть меньше Tmin (57.6мкс) Hекоторые, почти ЭМПИРИЧЕСКИЕ вычисления (специально для ST, я не поленился их сделать -- :-))) ----------------------------------------------------------- Hормированную пропускную способность W моноканала можно оценить средним количеством кадров, передаваемых за время Tmin. Очевидно, что значение W меньше, а в лучшем случае равно 1. Это неравенство и отражает особенность метода случайного доступа к моноканалу: пропускная способность является функцией интенсивности поступления запросов, количества станций в сегменте и размера передаваемых кадров. Для упрощения рассмотрим только два граничных случая: 1) число станций - максимально возможная величина 2) взаимодействуют только две станции. 1) Упростим мат. модель, предположив, что число станций велико и работают они независимо друг от друга. В этом случае станции порождают пуассоновский поток с суммарной интенсивностью G пакетов на Tmin. Вероятность передачи без коллизии - вероятность поступления только одного кадра за период канального интервала (максимального окна коллизий), которая для данного закона распределения случайной величины равна q=exp(-2G). При суммарном потоке кадров G, только q-ая часть будет передана без коллизий, т.е. пропускная способность W будет равна: W(G)=G*exp(-2G) Определим значение G, при котором W(G) максимальна. Анализируя данную функцию на экстремум (т.Ферма), получим: dW(G)/dG = (1-2G)exp(-2G) = 0 => Gopt=0.5 запроса на t=Tmin А следовательно, W(Gopt) = 1/(2e) = 0.184 [пакета на промежуток Tmin] Т.е. пропускная способность потенциально (методически) ограничена до 18.4% (или 1.84МБит/с). Тут я еще раз оговорюсь речь идет о наихудшем случае -- число станций велико. Десятые доли процента не отражают точности оценки -- это для проформы ;-), тем более что оно в известной степени эпирическое (из-за упрощений) и дает только оценку результата. Более точно, опять же, только теоретическое значение, дадут другие законы, учитывающие количество станций (IMHO законы Эрланга или Энгсета -- точно не помню сейчас уже ;-). Btw, наверное оттуда "апологеты Token Ring" [(c) 1999 Serge Turchin -- очень уж мне сочетание терминов понравилось ;-)] и поимели цифру 30%! 2) Предположим, что станции взаимодействуют без коллизий, тогда цикл обмена между ними не будет содержать арбитражных интервалов, определяемых truncated binary exponential backoff и состоит только из передаваемых кадров, чередующихся с межкадровыми щелями (interfarame/interpacket gap, IFG/IPG = 9.6мкс). В данном случае, существует два режима: а) передача кадров минимальной длины; б) передача кадров максимальной длины. а) передача кадров минимальной длины (коллизий нет) SUPER_Frame = Frame_min + IPG = 57.6 + 9.6 = 67.2мкс При этом, 36.8 мкс (0.548 или 54.8%) -- длится полезная передача, остальное (0.452 или 45.2%) -- overhead. Rate = 1 / 67.2мкс = 14880 packets per second BWmin = 14880*46*8 = 5.48 МБит/с = 0.684 МБайт/с б) передача кадров максимальной длины (коллизий нет) SUPER_Frame = Frame_max + IPG = 1220.8 + 9.6 = 1230.4мкс При этом 1200мкс (0.975 или 97.5%) -- длится полезная передача, остальное (0.025 или 2.5%) -- overhead. Rate = 1 / 1230.4мкс = 812 packets per second BWmax = 812*1500*8 = 9.74 МБит/с = 1.22 МБайт/с Анализ полученных результатов уже не так важен -- все и так давно сказано, остается заметить, что при p2p соединении скорость, в наиболее тяжелом для станций режиме (передача кадров минимальной длины) в два раза меньше физической, а в наиболее эффективном (передача кадров максимальной длины) почти равна физической. Все.... Еще раз признаю свой первый ляп про абсолютизацию "const" (увлекся и сказал не подумав). Спасибо. С уважением к All, а в особенности к принимавшим непосредственное участие (in order of appearance ;-) -- Vladimir Litovka, Alex Bakhtin, Mazhara Ilya, Serge Turchin и John Gladkih. _________ Yuri A. Selivanov. "Tomsktelecom", DIN, Network Engineer --- ifmail v.2.14dev3 * Origin: Digital Networks of Tomsktelecom (2:5020/400)

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру