Re[3]: пропускная способность и размер пакета - Сети, сокеты, протоколы

Здравствуйте, Аноним, Вы писали:

_>>формирую ICMP пакеты соответствующих длин след. образом: длина IP заголовка(20 байт)+длина ICMP заг.(8байт)+недостающие данные. для замера времени отправки и получения использую данные, предоставленные WinPCap.
А>IP (в т.ч. и ICMP) пакет такой длины будет фрагментирован стеком перед передачей и отправлен кусочками с max MTU. Т.е. теми самыми 1.5 кб. Но если хоть один кусочек потеряется — эффективно не дойдет весь отправленный IP пакет. Так что делайте выводы.

Пакеты я захватываю с помощью WinPCap и как я уже писал, фиксирую время отправки и приема пакета, если бы пакет не дошел, я бы его обратно не получил бы, а я получаю. Зная время прохождения пакета и его размер, нахожу пропускную способность, и что мне не понятно, так это почему у меня на пакетах макс. размера без фрагментации — это 1500 байт — пропускная способность на уровне 4.2Мбит, а на пакетах длинной 65535, которые естественно будут фрагментированы по макс. размеру MTU пропускная способность получается на уровне 11Мбит (сеть Fast Ethernet)

Здравствуйте, maxim_pv, Вы писали:

_>Здравствуйте, Аноним, Вы писали:

_>>>формирую ICMP пакеты соответствующих длин след. образом: длина IP заголовка(20 байт)+длина ICMP заг.(8байт)+недостающие данные. для замера времени отправки и получения использую данные, предоставленные WinPCap.
А>>IP (в т.ч. и ICMP) пакет такой длины будет фрагментирован стеком перед передачей и отправлен кусочками с max MTU. Т.е. теми самыми 1.5 кб. Но если хоть один кусочек потеряется — эффективно не дойдет весь отправленный IP пакет. Так что делайте выводы.

_>Пакеты я захватываю с помощью WinPCap и как я уже писал, фиксирую время отправки и приема пакета, если бы пакет не дошел, я бы его обратно не получил бы, а я получаю. Зная время прохождения пакета и его размер, нахожу пропускную способность, и что мне не понятно, так это почему у меня на пакетах макс. размера без фрагментации — это 1500 байт — пропускная способность на уровне 4.2Мбит, а на пакетах длинной 65535, которые естественно будут фрагментированы по макс. размеру MTU пропускная способность получается на уровне 11Мбит (сеть Fast Ethernet)

ау, есть тут кто

Здравствуйте, maxim_pv, Вы писали:

_>Пакеты я захватываю с помощью WinPCap и как я уже писал, фиксирую время отправки и приема пакета

А какое время пишет WinPCAP для фрагментированных Ethernet'ом пакетов — время приема первого фрейма или последнего?

Здравствуйте, Michael Chelnokov, Вы писали:

MC>Здравствуйте, maxim_pv, Вы писали:

_>>Пакеты я захватываю с помощью WinPCap и как я уже писал, фиксирую время отправки и приема пакета

MC>А какое время пишет WinPCAP для фрагментированных Ethernet'ом пакетов — время приема первого фрейма или последнего?

вот это для меня загадка, но делая как написано в документации на пикап

/* Open the device */
    if ( (adhandle= pcap_open(d->name,          // name of the device
                              65536,            // portion of the packet to capture
                                                // 65536 guarantees that the whole packet will be captured on all the link layers
                              PCAP_OPENFLAG_PROMISCUOUS,    // promiscuous mode
                              1000,             // read timeout
                              NULL,             // authentication on the remote machine
                              errbuf            // error buffer
                              ) ) == NULL)

тут сказано, что 65536 guarantees that the whole packet will be captured, но жесткой уверенности в том, что он установит время только после получения всего пакета нет, но если бы он устанавливал время прихода первого пакета, то измеренная мной производительность была бы в разы выше, чем меряю при помощи пикапа

_>Почему так? и какие могут быть задержки в железяке и драйвере?

Если Вы формируете пакеты в режиме приложения, то отсылая в ядро большой пакет Вы имеете следующие выигрыши:
1. Один раз переключается контекст в режим ядра и обратно ( вообще то, это копейки )
2. Нет риска, что после отсылки первой части пакета произойдет переключение задач и потерю кванта. Если Вы используете синхронные операции записи — риск потерять квант существенно возрастает ( потрея кванта — это минимум 10 мс окно в передаче )

Т.е мой диагноз — производительность теряется межу вашим приложеним и драйвером tcpip.sys. Сам драйвер и железо работают довольно шустро — там задержки мерятся единицами мкс.

Здравствуйте, TarasCo, Вы писали:

_>>Почему так? и какие могут быть задержки в железяке и драйвере?

TC>Если Вы формируете пакеты в режиме приложения, то отсылая в ядро большой пакет Вы имеете следующие выигрыши:
TC>1. Один раз переключается контекст в режим ядра и обратно ( вообще то, это копейки )
TC>2. Нет риска, что после отсылки первой части пакета произойдет переключение задач и потерю кванта. Если Вы используете синхронные операции записи — риск потерять квант существенно возрастает ( потрея кванта — это минимум 10 мс окно в передаче )

TC>Т.е мой диагноз — производительность теряется межу вашим приложеним и драйвером tcpip.sys. Сам драйвер и железо работают довольно шустро — там задержки мерятся единицами мкс.

Толково, но суть немного в другом. Почему по замеру времени доставки пакета оказывается гораздо выгоднее отсылать большие пакеты размером 65535 байт(при условии что нет потерь), ведь если пакет 1500 байт,то он передается без фрагментации, а большой пакет ведь еще надо разбить на фрагменты, затем передать и все их собрать, причем я посылал пакеты по одиночке и фиксировал время(переключение контекста м-ду посылками здесь исключается, ведь одиночная посылка). Я прав? если да, то для меня все еще вопрос остается открытым. Заранее спасибо за ответы.

Т.е у Вас пакет в 1500 байт ( такой кстати тоже будет фрагментирован, нужно 1500 — sizeof( ip_header ) ) передается медленнее, чем блок из 65535, фрагментированный самими ip стеком?

Здравствуйте, maxim_pv, Вы писали:

_>Толково, но суть немного в другом. Почему по замеру времени доставки пакета оказывается гораздо выгоднее отсылать большие пакеты размером 65535 байт(при условии что нет потерь), ведь если пакет 1500 байт,то он передается без фрагментации, а большой пакет ведь еще надо разбить на фрагменты, затем передать и все их собрать, причем я посылал пакеты по одиночке и фиксировал время(переключение контекста м-ду посылками здесь исключается, ведь одиночная посылка). Я прав? если да, то для меня все еще вопрос остается открытым. Заранее спасибо за ответы.

Да, вы правы. Однако если присмотреться внимательно, то вы своими словами повторили все то что сказал вам TarasCo. Именно потому что 65535 это одиночная посылка и исключено переключение контекста, поэтому здесь НЕ происходит тех самых потерь кванта, т.е времени. А в случае когда вы из usermode отправляете порциями по 1500 байт, потери этого самого времени после каждой посылки в 10мс окажутся в итоге существенными. Здесь получается что вы сами из usermode выполняете операцию фрагментации-дефрагментации, а в ядре это делает сетевой стек, но потери не из-за этого, а как уже было сказано из-за перключений контекста после отправки каждой порции

Здравствуйте, Alexey Frolov, Вы писали:

AF>Здравствуйте, maxim_pv, Вы писали:

_>>Толково, но суть немного в другом. Почему по замеру времени доставки пакета оказывается гораздо выгоднее отсылать большие пакеты размером 65535 байт(при условии что нет потерь), ведь если пакет 1500 байт,то он передается без фрагментации, а большой пакет ведь еще надо разбить на фрагменты, затем передать и все их собрать, причем я посылал пакеты по одиночке и фиксировал время(переключение контекста м-ду посылками здесь исключается, ведь одиночная посылка). Я прав? если да, то для меня все еще вопрос остается открытым. Заранее спасибо за ответы.

AF>Да, вы правы. Однако если присмотреться внимательно, то вы своими словами повторили все то что сказал вам TarasCo. Именно потому что 65535 это одиночная посылка и исключено переключение контекста, поэтому здесь НЕ происходит тех самых потерь кванта, т.е времени. А в случае когда вы из usermode отправляете порциями по 1500 байт, потери этого самого времени после каждой посылки в 10мс окажутся в итоге существенными. Здесь получается что вы сами из usermode выполняете операцию фрагментации-дефрагментации, а в ядре это делает сетевой стек, но потери не из-за этого, а как уже было сказано из-за перключений контекста после отправки каждой порции

Большое спасибо всем за ответы, кажись дошло

Здравствуйте, Alexey Frolov, Вы писали:

AF>из-за перключений контекста после отправки каждой порции

Что-то меня терзают смутные сомнения о каком-либо влиянии на современные компьютеры этих издержек. Особенно когра речь идет всего-то про единицы мегабит/сек...

Здравствуйте, Michael Chelnokov, Вы писали:

MC>Здравствуйте, Alexey Frolov, Вы писали:

AF>>из-за перключений контекста после отправки каждой порции

MC>Что-то меня терзают смутные сомнения о каком-либо влиянии на современные компьютеры этих издержек. Особенно когра речь идет всего-то про единицы мегабит/сек...

а меня тоже... для пробы (чтоб хоть как-то исключить переключение) можно поднять приоритет тестового процесса-потока,
а что там с ACK? нет-ли эффекту что посылая маленькими порциями и большими мы будем наблюдать разные эыффекты от Delayed ACK?

Здравствуйте, Аноним, Вы писали:

А>а что там с ACK?

Речь про ICMP...

Здравствуйте, maxim_pv, Вы писали:

_>Доброго всем утра!
_>Народ, у меня вопрос, который уже задавался на форуме, но вразумительного ответа на него не последовало, а очень хочется разобраться.

_>А вопрос такой: если взять 2 пакета, один размером 1500 байт, а другой 65535 байт, то пропускная способность сети возрастает и довольно ощутимо при использовании пакетов 65535 байт, по сравнению с пакетами по 1500 байт. Почему так? и какие могут быть задержки в железяке и драйвере?

Я не очень понимаю методику измерения. Вы хотите сказать, что вы измеряете пропускную способность сети, замеряя время отправки пакета t1, время прихода ответного пакете t2 и получаете пропускную способность сети как 2*S/(t2-t1), где S — размер пакета, а двойка за счет туда и обратно?
Тогда такой метод измерения в корне неправилен.
На самом деле время между посылкой пакета и приемом эха состоит из следующих времен:
t2-t1 = dt1 + T + dt2, где dt1 и dt2 — время прохождения пакета по сети в ту и другую сторону, а T — время обработки пакета на удаленном хосте. Используя ваши же данные измерения его можно оценить.
dt1 и dt2 считаем равными, пропускная способность сети 100 Мbs.
R = 2*S /(2*dt + T), где R — измеренная вами "пропускная способность".
Отсюда
T = (2*S — 2*R*dt)/R

dt получаем как dt = S/100Mbs

В первом случае S=15000 бит, dt = 0.15 мкс
Во втотром случае S=655350 бит, dt= 6.55 мкс.

T в первом случае равно (2*15000 — 2* 4200000*0.00015)/4200000 = 6.8 мкс
T во втором случае равно (2*655350 — 2 * 11000000*0.00655)/11000000 = 106 мкс
Учитывая, что размер пакетов отличается в 43 раза, увеличение времени обработки на удаленном хосте в 15 раз не кажется мне удивительным.
На самом деле этим тестом вы измеряете мощность удаленного хоста, а не пропускную способность сети.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, maxim_pv, Вы писали:

_>>Доброго всем утра!
_>>Народ, у меня вопрос, который уже задавался на форуме, но вразумительного ответа на него не последовало, а очень хочется разобраться.

_>>А вопрос такой: если взять 2 пакета, один размером 1500 байт, а другой 65535 байт, то пропускная способность сети возрастает и довольно ощутимо при использовании пакетов 65535 байт, по сравнению с пакетами по 1500 байт. Почему так? и какие могут быть задержки в железяке и драйвере?

А>Я не очень понимаю методику измерения. Вы хотите сказать, что вы измеряете пропускную способность сети, замеряя время отправки пакета t1, время прихода ответного пакете t2 и получаете пропускную способность сети как 2*S/(t2-t1), где S — размер пакета, а двойка за счет туда и обратно?
А>Тогда такой метод измерения в корне неправилен.
А>На самом деле время между посылкой пакета и приемом эха состоит из следующих времен:
А>t2-t1 = dt1 + T + dt2, где dt1 и dt2 — время прохождения пакета по сети в ту и другую сторону, а T — время обработки пакета на удаленном хосте. Используя ваши же данные измерения его можно оценить.
А>dt1 и dt2 считаем равными, пропускная способность сети 100 Мbs.
А>R = 2*S /(2*dt + T), где R — измеренная вами "пропускная способность".
А>Отсюда
А>T = (2*S — 2*R*dt)/R

А>dt получаем как dt = S/100Mbs

А>В первом случае S=15000 бит, dt = 0.15 мкс
А>Во втотром случае S=655350 бит, dt= 6.55 мкс.

А>T в первом случае равно (2*15000 — 2* 4200000*0.00015)/4200000 = 6.8 мкс
А>T во втором случае равно (2*655350 — 2 * 11000000*0.00655)/11000000 = 106 мкс
А>Учитывая, что размер пакетов отличается в 43 раза, увеличение времени обработки на удаленном хосте в 15 раз не кажется мне удивительным.
А>На самом деле этим тестом вы измеряете мощность удаленного хоста, а не пропускную способность сети.

Да, все правильно, но я бы не сказал, что эта методика в корне неправильна. Вот правильно то, что я не учитываю задержку на обработку пакетов удаленным хостом — это и есть моя самая большая погрешность. Тем не менее, при достаточно большом проведении экспериментов и с учетом простой реализации эта методика вполне годится для измерения пропускной способности, поскольку мне не известны другие, более точные. Ваша формула dt = S/100Mbs тоже не верна, т.к. мне нужна пропускная способность сети, в которой не только мой тест, а она при работе других приложений не будет 100Mbs, а будет например 20Mbs, тогда получается интересное время Т(т.е. как бы мощьность хоста будет определяться пропускной способностью канала

). Стоит сказать, что эта методика не нова, например ее использует извесная юниксовая утилита BING —

Утилита bing (bandwigth ping) основана на исходном коде ping (1), и определяет реальную (соответствующую доступной на момент измерения либо средней) пропускную способность канала. Это осуществляется путём измерения времён между отправкой и получением запросов ICMP echo различного объёма.

Еще в журнале "ЖУРНАЛ РАДИОЭЛЕКТРОНИКИ" N 3, 2003 была статья "Методы активного зондирования сетей", где было сказано, что

Пропускная способность C — равна: C = S /dt , где S – размер пакета,dt – время, затраченное на передачу пакета из источника в канал, либо из промежуточного маршрутизатора в канал. При этом S может быть, как величиной полезной информации, так и полной передаваемой информацией, включая служебную информацию. Под , можно подразумевать чистое время передачи пакета, либо время передачи вместе с техническими паузами.

и приведены методы определения номинальной пропускной способности канала — "Метод пакетной пары" и "Модель пакетной цепочки"

Здравствуйте, maxim_pv, Вы писали:

А>>На самом деле этим тестом вы измеряете мощность удаленного хоста, а не пропускную способность сети.

_>Да, все правильно, но я бы не сказал, что эта методика в корне неправильна. Вот правильно то, что я не учитываю задержку на обработку пакетов удаленным хостом — это и есть моя самая большая погрешность. Тем не менее, при достаточно большом проведении экспериментов и с учетом простой реализации эта методика вполне годится для измерения пропускной способности, поскольку мне не известны другие, более точные. Ваша формула dt = S/100Mbs тоже не верна, т.к. мне нужна пропускная способность сети, в которой не только мой тест, а она при работе других приложений не будет 100Mbs, а будет например 20Mbs, тогда получается интересное время Т(т.е. как бы мощьность хоста будет определяться пропускной способностью канала

). Стоит сказать, что эта методика не нова, например ее использует извесная юниксовая утилита BING —
_>

_>Утилита bing (bandwigth ping) основана на исходном коде ping (1), и определяет реальную (соответствующую доступной на момент измерения либо средней) пропускную способность канала. Это осуществляется путём измерения времён между отправкой и получением запросов ICMP echo различного объёма.

_>Еще в журнале "ЖУРНАЛ РАДИОЭЛЕКТРОНИКИ" N 3, 2003 была статья "Методы активного зондирования сетей", где было сказано, что
_>

_>Пропускная способность C — равна: C = S /dt , где S – размер пакета,dt – время, затраченное на передачу пакета из источника в канал, либо из промежуточного маршрутизатора в канал. При этом S может быть, как величиной полезной информации, так и полной передаваемой информацией, включая служебную информацию. Под , можно подразумевать чистое время передачи пакета, либо время передачи вместе с техническими паузами.

_>и приведены методы определения номинальной пропускной способности канала — "Метод пакетной пары" и "Модель пакетной цепочки"

Господа! Какая такая пропускная способность сети?
Пропускная способность сети — суть сумма пропускных способностей всех каналов сети или суммарная нагрузка исполняемая в единицу времени по всем направлениям связи при обеспечении заданных показателей обслуживания. Она характеризует сеть в целом.
Пропускная способность канала ( иногда пиковая, максимальная, номинальная) это "диаметр трубы" и она не является функцией от нагрузки, это максимально возможная скорость передачи данных в канале, канальная скорость.

Что Вы хотите измерить? Если пропускную способность каналов между двумя узлами сети то в принципе методы из "Методы активного зондирования сетей" подойдут с некоторыми оговорками. Так же с их помощью можно собрать статистические данные о нагрузке в этом направлении в зависимости от времени суток/месяца/года (что в целом может быть использовано для прогнозирования скорости передачи между этими узлами). Если же скорость передачи данных между этими узлами — в общем случае будет что-то где-то рядом, Аноним прав, приблизительно оценить.

В целом всё конечно зависит от конкретных условий и стоящей задачи.

Здравствуйте, maxim_pv, Вы писали:

_>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, maxim_pv, Вы писали:

_>Да, все правильно, но я бы не сказал, что эта методика в корне неправильна. Вот правильно то, что я не учитываю задержку на обработку пакетов удаленным хостом — это и есть моя самая большая погрешность. Тем не менее, при достаточно большом проведении экспериментов и с учетом простой реализации эта методика вполне годится для измерения пропускной способности, поскольку мне не известны другие, более точные. Ваша формула dt = S/100Mbs тоже не верна, т.к. мне нужна пропускная способность сети, в которой не только мой тест, а она при работе других приложений не будет 100Mbs, а будет например 20Mbs, тогда получается интересное время Т(т.е. как бы мощьность хоста будет определяться пропускной способностью канала

). Стоит сказать, что эта методика не нова, например ее использует извесная юниксовая утилита BING —
_>

_>Утилита bing (bandwigth ping) основана на исходном коде ping (1), и определяет реальную (соответствующую доступной на момент измерения либо средней) пропускную способность канала. Это осуществляется путём измерения времён между отправкой и получением запросов ICMP echo различного объёма.

_>Пропускная способность C — равна: C = S /dt , где S – размер пакета,dt – время, затраченное на передачу пакета из источника в канал, либо из промежуточного маршрутизатора в канал. При этом S может быть, как величиной полезной информации, так и полной передаваемой информацией, включая служебную информацию. Под , можно подразумевать чистое время передачи пакета, либо время передачи вместе с техническими паузами.

_>и приведены методы определения номинальной пропускной способности канала — "Метод пакетной пары" и "Модель пакетной цепочки"

Подобный способ измерения верен в предположении что время процессинга на удаленном хосте мало по сравнению с временем прохождения пакета по сети, т.е. T=0. В вашем же случае это похоже не так, именно поэтому и получается такая разница в пропускной способности для разных размеров пакетов.
Если бы вы пингали через модем, думаю что пропускная способность канала получилась бы одинаковая для любого размера, там действительно T можно пренебречь.

В вашем же случае, так как T неизвестно и не мало по сравнению с временем передачи, определить пропускную способность невозможно. Слишком большая ошибка вносится. Можно попробовать просниффить пакеты и на удаленном хосте и оценить время процессинга пакетов для разных размеров. Тогда T будет известно, и можно вычислить пропускную способность. Проблема в том, что под нагрузкой от других приложений T также может измениться на существенную величину, и вам опять нехватит данных для расчета.

PSю В моих расчетах везде мкс читать как мс. Да и проверить бы их неплохо, я на глазок считал. Да и 8 бит вместо 10-ти в байте, наверное... Не знаю, есть там бит четности или нет.

	От:	maxim_pv
	Дата:	12.08.07 06:01
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	12.08.07 06:32
Оценка:

	От:	maxim_pv
	Дата:	12.08.07 07:52
	Оценка:

	От:	Аноним
	Дата:	12.08.07 09:39
	Оценка:

	От:	maxim_pv
	Дата:	12.08.07 09:53
	Оценка:

	От:	Michael Chelnokov
	Дата:	12.08.07 12:58
	Оценка:

	От:	TarasCo
	Дата:	13.08.07 06:33
	Оценка:

	От:	TarasCo
	Дата:	13.08.07 07:42
	Оценка:

	От:	vortex
	Дата:	14.08.07 14:00
	Оценка: