Количество tcp-соединений, используемых программой MPI (MPICH2+nemesis+tcp)

Сколько tcp-соединений будет использоваться для отправки данных программой MPI, если используемым MPI является MPICH2? Если вы знаете также о соединениях pmi, посчитайте их отдельно.

Например, если у меня есть 4 процесса и дополнительно 2 коммуникатора (COMM1 для 1-го и 2-го процессов и COMM2 для 3-го и 4-го); данные пересылаются между каждой возможной парой процессов; во всех возможных коммуникаторах.

Я использую последние версии MPICH2 + гидра + pmi по умолчанию. ОС linux, сеть коммутируемая Ethernet. Каждый процесс находится на отдельном ПК.

Итак, вот пути данных (в парах процессов):

1 <-> 2 (in MPI_COMM_WORLD and COMM1)
1 <-> 3 (only in MPI_COMM_WORLD)
1 <-> 4 (only in MPI_COMM_WORLD)
2 <-> 3 (only in MPI_COMM_WORLD)
2 <-> 4 (only in MPI_COMM_WORLD)
3 <-> 4 (in MPI_COMM_WORLD and COMM2)

я думаю может быть

  • Дело 1:

Будут использоваться только 6 соединений tcp; данные, отправленные в COMM1 и MPI_COMM_WORLD, будут смешаны в одном TCP-соединении.

  • Случай 2:

8 tcp-соединений: 6 в MPI_COMM_WORLD (все ко всем = полная сетка) + 1 для 1 <-> 2 в COMM1 + 1 для 3 <-> 4 в COMM2

  • другой вариант, о котором я не подумал.

tcp parallel-processing mpi mpich
person osgx    schedule 02.12.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Используемые коммуникаторы не влияют на количество установленных TCP-соединений. Для --with-device=ch3:nemesis:tcp (конфигурация по умолчанию) вы будете использовать одно двунаправленное TCP-соединение между каждой парой процессов, которые напрямую взаимодействуют через подпрограммы MPI «точка-точка». В вашем примере это означает 6 подключений. Если вы используете коллективы, то под капотом могут быть установлены дополнительные соединения. Соединения будут устанавливаться лениво, только по мере необходимости, но однажды установленные, они будут оставаться установленными до тех пор, пока не будет вызван MPI_Finalize (а иногда также MPI_Comm_disconnect).

Навскидку я не знаю, сколько соединений используется каждым процессом для PMI, хотя я совершенно уверен, что это должно быть одно соединение на процесс MPI, подключающийся к процессам hydra_pmi_proxy, плюс некоторое другое число (вероятно, логарифмическое) соединения между процессами hydra_pmi_proxy и mpiexec.

person Dave Goodell    schedule 05.12.2011
comment
Если вы используете коллективы, то под капотом могут быть установлены дополнительные соединения. - А если у меня уже есть сокеты каждый к каждому (из точки в точку), то больше не будет подключений, если я буду использовать коллективные подпрограммы? - person osgx; 05.12.2011
comment
Правильный. Учитывая p процессов, максимально возможное количество общесистемных TCP-соединений равно p*(p-1)/2. - person Dave Goodell; 06.12.2011

arrow_upward
0
arrow_downward

Я не могу полностью ответить на ваш вопрос, но есть над чем задуматься. В MVAPICH2 для PMI мы разработали механизм соединения на основе дерева. Таким образом, каждый узел будет иметь журнал (n) TCP-соединений при макс. Поскольку при открытии сокета на большинстве операционных систем накладывается ограничение на дескриптор открытого файла, вполне вероятно, что библиотека MPI будет использовать логическую топологию рангов для ограничения количества TCP-соединений.

person jman    schedule 04.12.2011
comment
Я не понимаю, если у вас будет 100 (n=100) процессов и будет связь каждый-к-каждому (100*99 односторонних или ~100*50 двухсторонних пар), как они будут осуществляться, если каждый из n процессов имеет только log(n) ~‹ 10 подключений? - person osgx; 05.12.2011
comment
Также сначала я хочу знать не о соединениях PMI, а о соединениях данных. О вашем ответе - основан ли древовидный механизм для PMI в восходящем потоке mpich2 или нет? - person osgx; 05.12.2011
comment
Я не знаю, находится ли он в восходящем потоке MPICH2. Он находится в файле mpirun_rsh MVAPICH2. Что касается механизма log(n), сообщения маршрутизируются через другие ранги, если нет прямого соединения. - person jman; 05.12.2011
comment
Это только для PMI или для данных тоже? - person osgx; 05.12.2011
comment
В примере, который я привел, был только PMI. Я предполагаю, что библиотекам нужно сделать что-то подобное (или оптимизации, такие как использование общей памяти для локальных процессов узла), чтобы уменьшить количество открытых сокетов TCP. - person jman; 05.12.2011
comment
Спасибо, я знаю про разделяемую память для node-local, и я даже хочу отключить эту оптимизацию (отправлять все через tcp, даже если процессы не являются одним и тем же узлом) - person osgx; 05.12.2011
comment
Самый простой способ отключить это — установить переменную среды MPICH_NO_LOCAL=1. Или, если вы абсолютно уверены, что не хотите использовать разделяемую память, вы можете настроить MPICH2 с помощью --enable-nemesis-dbg-nolocal. - person Dave Goodell; 06.12.2011