Здравствуйте, 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.
Тогда останутся затраты на переключение контекстов, обработку прерывания и пробуждение потока получателя. Эти числа зависят от операционной системы и загруженности системы.
