Ключевые слова: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" <[email protected]>
Serge Turchin <[email protected]> wrote in message
news:[email protected]...
> Yuri A. Selivanov ([email protected]) 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)
