скорость
От: Pavel Dvorkin Россия  
Дата: 08.01.08 10:20
Оценка:
Такой вопрос к здешним гуру.

Задача — переслать с одной машины на другую примерно 50 Кб. И сделать это максимально быстро.

Может кто-то привети данные, что в этом случае лучше ? Сокеты, пайпы...

Ссылки на данные по замеру производительности приветствуются.

Windows XP.
With best regards
Pavel Dvorkin
Re: скорость
От: Michael Chelnokov Украина  
Дата: 08.01.08 11:56
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Задача — переслать с одной машины на другую примерно 50 Кб. И сделать это максимально быстро.


50 Кб поместится в один пакет UDP. Быстрее вряд ли получится.

PD>Может кто-то привети данные, что в этом случае лучше ? Сокеты, пайпы...


Подозреваю что пайпы не дадут никакого выигрыша, т.к. в современных системах они реализованы через тот же TCP (если передача идет не в пределах одного узла).
Re[2]: скорость
От: dimavs  
Дата: 08.01.08 20:59
Оценка:
Здравствуйте, Michael Chelnokov, Вы писали:

MC>50 Кб поместится в один пакет UDP. Быстрее вряд ли получится.


Да? А я-то всегда думал, что там порядка 1400-1500 байт в одном пакете. И не только думал, но и на практике ощущал, у меня RTP пакеты при всем моем желании больше размером не отправлялись
Re[3]: скорость
От: wellwell Австралия https://www.softperfect.com
Дата: 09.01.08 02:01
Оценка:
"dimavs" <11682@users.rsdn.ru> wrote in message news:2789142@news.rsdn.ru...
> Да? А я-то всегда думал, что там порядка 1400-1500 байт в одном пакете. И не только думал, но и на практике ощущал, у меня RTP пакеты при всем моем желании больше размером не отправлялись

Этот параметер называется MTU. Кстати он может быть больше
Posted via RSDN NNTP Server 2.1 beta
Re: скорость
От: DOOM Россия  
Дата: 09.01.08 05:45
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Такой вопрос к здешним гуру.


PD>Задача — переслать с одной машины на другую примерно 50 Кб. И сделать это максимально быстро.


PD>Может кто-то привети данные, что в этом случае лучше ? Сокеты, пайпы...


Pipe'ы, mailslot'ы и тому подобная лабуда это максимально медленный способ, потому что это:
1. Установка TCP соединения
2. Установка SMB соединения (с аутентификацией).
3. Подключение некоторых SMB ресурсов.
4. Какое-то число вызовов MS RPC
5. Ну вот тут где-то идет передача.
Re[4]: скорость
От: Pavel Dvorkin Россия  
Дата: 09.01.08 06:17
Оценка:
Здравствуйте, wellwell, Вы писали:

W>"dimavs" <11682@users.rsdn.ru> wrote in message news:2789142@news.rsdn.ru...

>> Да? А я-то всегда думал, что там порядка 1400-1500 байт в одном пакете. И не только думал, но и на практике ощущал, у меня RTP пакеты при всем моем желании больше размером не отправлялись

W>Этот параметер называется MTU. Кстати он может быть больше


Прочитал, спасибо. Но , видимо, все же в один пакет не уложить...

Most Gigabit Ethernet hardware is able to send and receive frames as large as 8192 or 9000 octets.

Да еще с таким примечанием

Use of non-standard frame sizes can cause hard-to-debug interoperability problems, for example when network switches silently discard large frames. This is why the IEEE does not standardise any form of jumbo frames for Ethernet networks.
With best regards
Pavel Dvorkin
Re[2]: скорость
От: Pavel Dvorkin Россия  
Дата: 09.01.08 06:18
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Pipe'ы, mailslot'ы и тому подобная лабуда это максимально медленный способ, потому что это:

DOO>1. Установка TCP соединения
DOO>2. Установка SMB соединения (с аутентификацией).
DOO>3. Подключение некоторых SMB ресурсов.
DOO>4. Какое-то число вызовов MS RPC
DOO>5. Ну вот тут где-то идет передача.

В общем, я и сам так думал. Получается, что ничего быстрее сокетов нет ?
With best regards
Pavel Dvorkin
Re[2]: скорость
От: Pavel Dvorkin Россия  
Дата: 09.01.08 06:21
Оценка:
Здравствуйте, Michael Chelnokov, Вы писали:

MC>Подозреваю что пайпы не дадут никакого выигрыша, т.к. в современных системах они реализованы через тот же TCP (если передача идет не в пределах одного узла).


А что ты имеешь в виду, говоря об одном узле ?
With best regards
Pavel Dvorkin
Re[3]: скорость
От: DOOM Россия  
Дата: 09.01.08 06:23
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>В общем, я и сам так думал. Получается, что ничего быстрее сокетов нет ?


Ну почему... Драйвер быстрее будет Но неправильнее.
Re[5]: скорость
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 09.01.08 12:49
Оценка: 10 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

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


W>>"dimavs" <11682@users.rsdn.ru> wrote in message news:2789142@news.rsdn.ru...

>>> Да? А я-то всегда думал, что там порядка 1400-1500 байт в одном пакете. И не только думал, но и на практике ощущал, у меня RTP пакеты при всем моем желании больше размером не отправлялись

Что-то тут не то.

W>>Этот параметер называется MTU. Кстати он может быть больше


PD>Прочитал, спасибо. Но , видимо, все же в один пакет не уложить...


Глупости. Пакет передаётся любого размера вплоть до 64K. Но он будет фрагментироваться. 50KB одним пакетом разрежется на ~34 фрагмента. На IPv4 это будет работать практически гарантированно (DF на UDP почти никто не ставит, если явно не попросить). На IPv6 — будут проблемы, если транзитный MTU меньше ближайшего исходящего — пакет может потеряться.

При сочетании условий: 1) IPv4, 2) надо именно что послать порцию данных как можно быстрее и не особо заботиться о качестве доставки, считая, что сеть надёжная — один UDP-пакет размером 50KB — оптимальное решение.

Ситуация усложняется, если сеть не настолько надёжна, или IPv6, или есть транзитные проблемы (фактически это та же ненадёжность), или могут быть порции более 64K (точнее — 65507 байт). Вот тут уже надо вводить более серьёзные меры. Как правило, при этом стремятся сделать какую-то систему гарантированной доставки одновременно с устранением зависимости от транзитного MTU, а это уже ведёт или к TCP, или к SCTP, или к своим специфическим протоколам поверх UDP (обычно повторяющих нижний уровень логики TCP).

PD>Most Gigabit Ethernet hardware is able to send and receive frames as large as 8192 or 9000 octets.


Повторяю: даже если ограничение на стандартные 1500 — это ограничивает размер _фрагмента_ IP пакета, а не полного пакета. А далее уже начинаются пляски вокруг MTU, DF и версии IP.
The God is real, unless declared integer.
Re[3]: скорость
От: Michael Chelnokov Украина  
Дата: 09.01.08 14:32
Оценка:
Здравствуйте, dimavs, Вы писали:

MC>>50 Кб поместится в один пакет UDP. Быстрее вряд ли получится.

D>Да? А я-то всегда думал, что там порядка 1400-1500 байт в одном пакете.

Не путай фреймы Ethernet и датаграммы UDP. В-прочем, Нечаев уже все разжевал
Re[3]: скорость
От: Michael Chelnokov Украина  
Дата: 09.01.08 14:37
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

MC>>Подозреваю что пайпы не дадут никакого выигрыша, т.к. в современных системах они реализованы через тот же TCP (если передача идет не в пределах одного узла).

PD>А что ты имеешь в виду, говоря об одном узле ?

Когда и клиент и сервер именованного канала находятся на одной машине. В этом случае TCP не используется.
Я это упомянул, потому что тут всегда найдутся любители сказать "не всегда" на утверждение "именованные каналы реализованы через TCP"
Re[6]: скорость
От: Michael Chelnokov Украина  
Дата: 09.01.08 14:43
Оценка:
Здравствуйте, netch80, Вы писали:

N>а это уже ведёт или к TCP, или к SCTP, или к своим специфическим протоколам поверх UDP


В Windows XP нет SCTP, но зато есть PGM. Может поможет.
Re[7]: скорость
От: Michael Chelnokov Украина  
Дата: 09.01.08 14:53
Оценка:
Здравствуйте, Michael Chelnokov, Вы писали:

MC>В Windows XP нет SCTP, но зато есть PGM. Может поможет.


Два неочевидных момента:
1. Чтобы PGM появился в Windows XP, надо установить компонент Windows "Message Queuing".
2. Чтобы PGM не ограничивал скорость передачи (по каким-то непонятным соображениям он это делает по-умолчанию), надо установить корректные значения через опцию IPPROTO_RM/RM_RATE_WINDOW_SIZE на передатчике. Возможно, потребуется еще установить опцию IPPROTO_RM/RM_HIGH_SPEED_INTRANET_OPT на приемнике (влияет ли это на что-то, я не знаю).
Re[4]: скорость
От: TarasCo  
Дата: 09.01.08 14:59
Оценка: 6 (1)
DOO>Ну почему... Драйвер быстрее будет Но неправильнее.

Есть еще SAN ( system area network ). С точки зрения ОС — это технология прямого доступа приложения к аппаратной памяти сетевой платы ( чем то похоже на DirectDraw ). Но для этого нужна поддержка со стороны железки и водится это вроде на всяких оптоволоконных устройствах и применяется в кластерных приложениях. Зато гарантируется минимальная задержка отправления данных. Для обычных железок с драйвером с NDIS интерфейсом задержка при отправлении может быть довольно значительной и по велечене сравнимой с длительностью кванта задачи.
Да пребудет с тобою сила
Re[5]: скорость
От: DOOM Россия  
Дата: 10.01.08 05:18
Оценка:
Здравствуйте, TarasCo, Вы писали:

DOO>>Ну почему... Драйвер быстрее будет Но неправильнее.


TC>Есть еще SAN ( system area network ). С точки зрения ОС — это технология прямого доступа приложения к аппаратной памяти сетевой платы ( чем то похоже на DirectDraw ). Но для этого нужна поддержка со стороны железки и водится это вроде на всяких оптоволоконных устройствах и применяется в кластерных приложениях. Зато гарантируется минимальная задержка отправления данных. Для обычных железок с драйвером с NDIS интерфейсом задержка при отправлении может быть довольно значительной и по велечене сравнимой с длительностью кванта задачи.


Хм... Понятно, что ничего не мешает объединить SAN сетью два компьютера, но все-таки как-то привычнее видеть связку сервер — система хранения.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.