Всем привет!

Казалось бы, глупый вопрос.... Поэтому конкретизирую задачу.
Есть два компа, которые простаивают, есть 100мбитная сетка, которая тоже простаивает.
Есть буфер на обеих компах по 1кбайту. Нужно передать по сетке 1килобайт из буфера первого компа на второй. То-есть, все происходит без участия жесткого диска.

Если прикинуть, что по стамегабитной сетке передается 10Мбайт в минуту, то логично предположить, что 1кбайт передастся за 100 микросекунд. Что то я сильно в этом сомневаюсь, ведь за это время буфер должен обработаться всеми уровнями OSI, и физически передаться по кабелю!

Поэтому вопрос, сколько реально понадобится времени для передачи килобайта?
Ответьте плиз, очень нужно для теории в дипломе.

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

VB>Всем привет!

VB>Казалось бы, глупый вопрос.... Поэтому конкретизирую задачу.
VB>Есть два компа, которые простаивают, есть 100мбитная сетка, которая тоже простаивает.
VB>Есть буфер на обеих компах по 1кбайту. Нужно передать по сетке 1килобайт из буфера первого компа на второй. То-есть, все происходит без участия жесткого диска.

VB>Если прикинуть, что по стамегабитной сетке передается 10Мбайт в минуту, то логично предположить, что 1кбайт передастся за 100 микросекунд. Что то я сильно в этом сомневаюсь, ведь за это время буфер должен обработаться всеми уровнями OSI, и физически передаться по кабелю!

VB>Поэтому вопрос, сколько реально понадобится времени для передачи килобайта?
VB>Ответьте плиз, очень нужно для теории в дипломе

Ответ зависит от способа передачи. Во первых, к реальности модель OSI имеет отдалённое отношение, так как в реальности люди пользуются TCP/IP для передачи данных (преимущественно), а так же рядом других протокольных стеков. При передаче данных с компьютера на компютер из одного приложения в другое типовыми средствами сетевых протоколов получается такие затраты

0. В некоторых операционных системах (Windows, например) отправка данных обслуживается вспомогательной библиотекой (Winsock) (это не считая таких возможностей как RPC, FTP, ssh, где ещё большие накладные расходы)
1. Переключение в ядерный контекст (так как реализации протоколов обычно располагаются в ядре)
2. Проход по протокольному стеку. Здесь масса возможных путей
3. Отображение адреса сетевого уровня в адрес канального уровня (например, IPv4 адрес в MAC адрес)
4. Формирование кадра -- так как максимальный размер данных в кадре Ethernet 1500 октетов, то для пересылки одного килобайта достаточно одного кадра
5. Передача кадра в канал
6. Получение кадра на оконечном пункте (на карточке)
7. Скорее всего, карточка инициирует прерывание, поэтому добавим время на обработку прерывания
8. Разбор кадра и обработка пакета сетевого уровня
9. Постановка полученных данных в очередь для получения процессом
10. Пробуждение процесса/нити получателя, чтение из очереди
11. Если пользуемся Виндой, то надо добавить накладные операции по работе с сокетами

Видно, что накладные расходы на пересылку кадра по сто мегабитной сетке в этом списке занимают очень скромное положение.

Можно значительно ускорить работу, если выкинуть протокольный стек. Отправлять непосредственно в канал, и читать непосредственно из канала. Иными словами, написать свой микропротокол и сделать для него реализации с минимальным числом действий (не считать контрольную сумму, пользоваться MAC адресами, не использовать никаких таймеров) -- просто завернуть данные в кадр на конце отправителя и развернуть на стороне получателя.
Не пользоваться сокетами, взаимодействовать с ядерной реализацией через IOCTL.

Тогда останутся затраты на переключение контекстов, обработку прерывания и пробуждение потока получателя. Эти числа зависят от операционной системы и загруженности системы.

Такой ответ подходит? Или вопрос был о другом?

Но тут нужно учесть, что как правило аппаратура освобождает процессор от приема/передачи (я о DMA). Поэтому в то время, как принимается очередной пакет, процессор может обрабатывать предыдущий. Я не скажу "за всю Одессу", но в Windows потратит на обработку принятого пакета не больше 5 мкс (при свободном процессоре не > 1ГГц, цифру с потолка взял ), Так что если пакеты идут потоком — скорость будет определяться полосой сетки — полоса ОС раз в 100 больше.

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

N>Такой ответ подходит? Или вопрос был о другом?

Класс!!! Я даже не надеялся получить настолько подробного описания, что же происходит помимо собственно передачи данных по сети! Сейчас вставлю эту теорию в диплом... Вы ж не возражаете?

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

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

TC>Windows потратит на обработку принятого пакета не больше 5 мкс

Хм... Тогда, как я уже говорил:
VB>логично предположить, что 1кбайт передастся за 100 микросекунд
Получается, если на обработку всего остального, кроме передачи по сети уходит 5 мкс, то можно сказать, что 1кбайт передается за 105 мкс? Честно говоря, мне кажется что на обработку всех операций для передачи 1 килобайта по сети потребуется значительно больше, чем 5 мкс... Интерестно, хотя бы приблизительно на среднестатистической машине, сколько?

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

N>>Такой ответ подходит? Или вопрос был о другом?

VB>Класс!!! Я даже не надеялся получить настолько подробного описания, что же происходит помимо собственно передачи данных по сети! Сейчас вставлю эту теорию в диплом... Вы ж не возражаете?

N>>Видно, что накладные расходы на пересылку кадра по сто мегабитной сетке в этом списке занимают очень скромное положение.
VB>Если не сложно, оцените пожалуйста время на вот эти вот накладные расходы для передачи одного килобайта... Хотя бы приблизительно.

А эксперимент поставить слабо?

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

А>А эксперимент поставить слабо?

Каким образом?

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

А>>А эксперимент поставить слабо?

VB>Каким образом?

Дык. Взять и замерить. Ё-моё.

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

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

А>>>А эксперимент поставить слабо?

VB>>Каким образом?

А>Дык. Взять и замерить. Ё-моё.

Чем? Линейкой? Или стать с секундомером в руке? Я не знаю как. Если знаете как, подскажите пож.

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

А>>>>А эксперимент поставить слабо?

VB>>>Каким образом?

А>>Дык. Взять и замерить. Ё-моё.

VB>Чем? Линейкой? Или стать с секундомером в руке? Я не знаю как. Если знаете как, подскажите пож.

Ну и дипломники пошли! А ещё будущий научный работник.

Возьми два компа. Напиши прожку. Посылай пакеты по килобайту, и пиши какой-нить QueryPerformanceCounter() в лог. Только много пакетов, на разных компах и в разных условиях.

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

А>Возьми два компа. Напиши прожку. Посылай пакеты по килобайту, и пиши какой-нить QueryPerformanceCounter() в лог. Только много пакетов, на разных компах и в разных условиях.
Тема моего дипломного совсем другая, это просто возникла необходимость в анализе написать данные, сколько будут передавать по сети малые объемы данных (типа килобайта). Просто написать предложение в дипломе по этому поводу. А работы по теме диплома еще валом, времени мало, а писать прожку — это разбираться, как работают сокеты, счетчики производительности и т.д., вобщем кучу времени нада. Вот я и спрашиваю может кто приблизительно знает?

Здравствуйте, VetalB.

Вы писали 1 июня 2004 г., 0:22:26:

VB>>логично предположить, что 1кбайт передастся за 100 микросекунд
V> Получается, если на обработку всего остального, кроме передачи
V> по сети уходит 5 мкс, то можно сказать, что 1кбайт передается за
V> 105 мкс? Честно говоря, мне кажется что на обработку всех операций
V> для передачи 1 килобайта по сети потребуется значительно больше,
V> чем 5 мкс... Интерестно, хотя бы приблизительно на
V> среднестатистической машине, сколько?
Если вы собрались "вставлять" эти данные в диплом, то я сомненваюсь,
что вашему рецензенту понравятся фраза "цифру с потолка взял". Это всё
расчитывается теоретически и сколько времени требуется такой-то версии
виндовс чтобы передать 100 К данных здесь не важно. Есть конкретные
временные задержки и издержки при передаче. Почитайте теорию, вроде в
Олифере даже есть..
--
С уважением, butcher

Не сказано самое главное — это TCP или UDP? и речь идет об обмене мелкими пакетами — или о bandwidth при качании длинного файла через сокет? А TCP_NODELAY у нас включена или нет?

Обычно интерес представляют два показателя. Bandwidth — которую, конечно, всегда удастся поддержать на уровне "сырая bandwidth канала минус заголовки", и слабость машины тут повлияет только на нагрузку процессора на подсчет контрольных сумм — и еще round-trip time, время пути мелкого пакета туда и обратно.

Время просто передачи пакета неинтересно. Толку с нее? На практике через сеть или транзакции вопрос-ответ гоняют, или bulk traffic.

VB>Хм... Тогда, как я уже говорил:
VB>>логично предположить, что 1кбайт передастся за 100 микросекунд
VB>Получается, если на обработку всего остального, кроме передачи по сети уходит 5 мкс, то можно сказать, что 1кбайт передается за 105 мкс? Честно говоря, мне кажется что на обработку всех операций для передачи 1 килобайта по сети потребуется значительно больше, чем 5 мкс... Интерестно, хотя бы приблизительно на среднестатистической машине, сколько?

Можно примерно посчитать......
Расходы времени на открытие сокета не считаем
Вызываем send и понеслась:
Вызов DeviceIoControl к драйверу afd.sys. Большие расходы при переходе в режим ядра. Это порядка 1000 инстр процессора, т.е в районе 1мкс. Я кстати не считал эту цифру, поскольку никто не запрещает использовать tcpip.sys напрямую из ядра через TDI. Поэтому сразу переходим к этому делу.

Начнем все сначала
Процессор на DPL = 0, буфер заполнен, находится в невыгружаемой памяти (и соотвественно отображен на системную память). У нас есть уже открытый файл — соединение на устройстве /Device/tcp. Отправляем драйверу запрос TDI_SEND.
— на формирование и отправку запроса — порядка 200 инстр
tcpip.sys обрабатывает запрос. При этом — выделяются из пула три буфера (обычно) — для заголовка TCP, IP, Ethernet. Выделение из пула — быстрая операция — порядка 100 инстр.
Заполняются заголовки, подсчитываются контрольные суммы 400 — 600 инстр.
Формируется пакет и отправляется через интерфейс NDIS сетевой карте — 100 инстр.
Прохождение через NDIS ~50инстр
Обработка пакета минипортом карты ~ 200 — 400 инстр
Передача пакета бас мастеру PCI, в данном случае можно вообще не учитывать. К тому же процессор уже свободен и может заняться другим пакетом.

Итого на отправку ушло порядка 1500 операций процессора (умножте эту цифру на коэф. доверия моим словам ). Это в районе 2 — 3 мкс. ТО же самое на приемной стороне. Так примерно появилась цифра 5 мкс.

Кроме того, прошу обратить внимание на мои слова о потоковой передаче. За время передачи 1 фрейма, процессор сможет подготовить и поставить в очередь минипорту на обслуживание десяток другой пакетов. Поэтому реальная средняя скорость передачи будет караз 1пакет/100мкс

Очень хорошее описание. Замечания по ходу текста

TC> tcpip.sys обрабатывает запрос. При этом — выделяются из пула три буфера (обычно) —
>для заголовка TCP, IP, Ethernet.

Два. TCP и IP идут подряд одним куском.

TC> подсчитываются контрольные суммы 400 — 600 инстр.

Ой ли? Тут реально будут тысячи команд, и это будет основное, где жрется процессор. Все прочие расходы — даже ring transition — гроши по сравнению с этим.

TC>> tcpip.sys обрабатывает запрос. При этом — выделяются из пула три буфера (обычно) —
>>для заголовка TCP, IP, Ethernet.

MSS>Два. TCP и IP идут подряд одним куском.

Не всегда. Видел варианты..... Забавно выглядит ICMP — в одном буфере заголовок IP и ICMP, тело ICMP пакета — в другом (посему — в принципе понятно)

TC>> подсчитываются контрольные суммы 400 — 600 инстр.

MSS>Ой ли? Тут реально будут тысячи команд, и это будет основное, где жрется процессор. Все прочие расходы — даже ring transition — гроши по сравнению с этим.

Ну не так все плохо. Подсчет CRC IP заголовка — оставим в покое — эта малая величина по сравнению с CRC TCP пакета.
Для 1000 байт надо 500 раз выполнить целочисленное сложение. Я конечно маханаул 500 инстр тут маловато — не сигнальный процессор чай . Реально в несколько раз больше. Но автор вроде не настаивал на TCP? Используйте UDP — никаих расчетов CRC, так что стою на своем — накладные расходы реализации стека протоколов в десятки раз меньше временных затрат на передачу (для 100Мб сетки, для гигабитной картина естественно более грустная , использование TCP на локальном волокне конечно кучерявое занятие)

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

TC> Итого на отправку ушло порядка 1500 операций процессора (умножте эту цифру на коэф. доверия моим словам ). Это в районе 2 — 3 мкс. ТО же самое на приемной стороне. Так примерно появилась цифра 5 мкс.

То-есть, можно утверждать, что на пересылку 1 килобайта по 100мегабитной сети уйдет как правило не более 100мкс + максимум 10 мкс? Это естессно при простое сети и процов...

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

TC>> Итого на отправку ушло порядка 1500 операций процессора (умножте эту цифру на коэф. доверия моим словам ). Это в районе 2 — 3 мкс. ТО же самое на приемной стороне. Так примерно появилась цифра 5 мкс.

То-есть, можно утверждать, что на пересылку 1 килобайта по 100мегабитной сети уйдет как правило не более 100мкс + максимум 10 мкс? Это естессно при простое сети и процов...

ЗЫ: Сорри что продублировал свой пост, первый раз чото не зашло в форум под моим именем.

TC>Не всегда. Видел варианты..... Забавно выглядит ICMP — в одном буфере заголовок IP и
>ICMP, тело ICMP пакета — в другом (посему — в принципе понятно)

Ага. Потому как тело ICMP пакета — это огрызок от первоначального пакета.

TC>Для 1000 байт надо 500 раз выполнить целочисленное сложение. Я конечно маханаул 500
>инстр тут маловато — не сигнальный процессор чай . Реально в несколько раз больше.

Да. Вот только там 32битные команды используются, чтобы сразу по 2 слова. Есть хитрые способы посчитать Internet checksum таким образом.

>Но автор вроде не настаивал на TCP? Используйте UDP — никаих расчетов CRC,

Точнее — их отключить можно. В эзернете это прокатит, в мировом Интернете — нет.

>так что стою на своем — накладные расходы реализации стека протоколов в десятки раз
>меньше временных затрат на передачу (для 100Мб сетки, для гигабитной картина

Ну это само собой.

>естественно более грустная , использование TCP на локальном волокне конечно кучерявое

На гигабите без checksum offload не проживешь.

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

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

TC>>> Итого на отправку ушло порядка 1500 операций процессора (умножте эту цифру на коэф. доверия моим словам ). Это в районе 2 — 3 мкс. ТО же самое на приемной стороне. Так примерно появилась цифра 5 мкс.

VB>То-есть, можно утверждать, что на пересылку 1 килобайта по 100мегабитной сети уйдет как правило не более 100мкс + максимум 10 мкс? Это естессно при простое сети и процов...

можно. На самом деле 10 мкс это за глаза, за уши и за что еще угодно для отправки пакета 1000 байт даже через ресурсоемкий протокол типа TCP (почему ресурсоемкий — см. рассуждения по поводу CRC). (а ведь можно пользоваться не TCP или UDP, а прямо rawip, кстати даже из приложения — tcpip драйвер через TDI предоставляет такую возможность, в этом случае затраты будет практически только на вход в режим ядра).

Но дожен заметить, за счет реализации функции ввода вывода из режима приложений есть возможность прилично "загробить" производительность. Т.е с производительностью будет ве нормально, но за счет переключения задач и ожидания окончания операциий ввода/вывода на каком-нибудь объекте синхронизации, возможно, приложение будет "узнавать" об окончании операции спустя скажем 10мс, в то время как сама операция заняла несколько мкс.