2015-10-13 11 views
1

У меня есть основное понимание как JSOR, так и jVerbs.Ядровые сокеты на RDMA (JSOR) против производительности jVerbs в Infiniband

Оба ограничения ручек JNI и использование быстрого пути для уменьшения латентности. Оба они используют интерфейс пользователя Verbs RDMA для предотвращения переключения контекста и обеспечения быстрого доступа к пути. Оба варианта также имеют опции для переноса с нулевой копией.

Разница в том, что JSOR по-прежнему использует интерфейс Java Socket. jVerbs предоставляет новый интерфейс. jVerbs также имеет что-то, называемое Stateful Verbs Call, чтобы избежать повторной сериализации запросов RDMA, которые, по их словам, уменьшают задержку. jVerbs предоставляет более собственный интерфейс, и приложения могут напрямую использовать их. Я прочитал документ jVerbs SoCC 2013, где они строят jverbsRPC поверх jVerbs и показывают, что он значительно сокращает время ожидания операций zookeeper и memcache.

Документация для обоих показывает, что они работают лучше, чем обычные сокеты Java на основе TCP/IP, SDP и IPoIB.

У меня нет сравнения производительности между JSOR и jVerbs. Я думаю, что jVerbs может работать лучше, чем JSOR. Но, с JSOR, мне не нужно менять свой существующий код, потому что он по-прежнему использует тот же интерфейс сокета java. Мой вопрос заключается в том, что может быть приростом производительности при использовании jVerbs относительно JSOR. Кто-нибудь знает или имеет опыт работы с ними? Если у вас есть данные сравнения, это будет здорово. Я не мог найти.

ответ

2

Ниже приведены некоторые цифры, используя DiSNI - недавно открытый преемник IBM jVerbs - и DaRPC, библиотека RPC с низкой задержкой, использующая DiSNI.

  • DiSNI RDMA чтения латентности для 64 байт ниже 2 микросекунд
  • DaRPC RDMA отправить/Recv латентности по 64 байт (запроса и ответа) около 5 микросекунд
  • Различия betwenn Java/DiSNI и C родной RDMA незначительны для односторонних операций

Эти тесты были выполнены на двух хостах, подключенных с использованием сетевого интерфейса Mellanox ConnectX-3.

Вот команды для выполнения контрольных показателей:

(1) Читать бенчмарк

Сервер:

java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-server -a <address> -o read -s 64 -k 100000 -p 

Client:

java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-client -a <address> -o read -s 64 -k 100000 -p 

(2) Отправить/ПРИЕМ контрольный ориентир

Сервер:

java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.server.DaRPCServer -a <address> -d -l 64 -r 64 

Клиент:

java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.client.DaRPCClient -a <address> -k 1000000 -l 64 -r 64 -b 1 

enter image description here

1

Сравнивать производительность jVerbs с JSOR немного сложно. Первый - это API-интерфейс, ориентированный на сообщения, а второй скрывает RDMA за потоковым API-интерфейсом Java.

Проделайте, пожалуйста, статистику. Мой тест с использованием пары старых карт ConnectX-2 и серверов Dell PowerEdge 2970. CentOS 7.1 и Mellanox OFED версии 3.1.

Меня интересовал только латентный тест.

jVerbs

Тест является разновидностью RPing образца (можно разместить на GitHub если кто-нибудь заинтересован). Проверьте измеренную задержку 5000000 циклов следующей последовательности вызовов по надежному соединению. Размер сообщения составил 256 байтов.

PostSendMethod.execute() 
PollCQMethod.execute() 
CompletionChannel.ackCQEvents() 

Результаты (микросекунды):

  • Медиана: 10,885
  • 99,0% процентиля: 11,663
  • 99,9% процентиля: 17,471
  • 99,99% процентиля: 27,791

JSOR

Аналогичный тест на разъем JSOR. Тест был образцом клиентского/серверного сокета текстовой книги. Размер сообщения также был 256 байтов.

Результаты (микросекунды):

  • Срединные: 43
  • 99,0% процентиль: 55
  • 99.9% процентиль: 61
  • 99,99% процентиль: 217

Эти результаты очень далеки от теста латентности OFED. В том же стандартном стандарте ib_send_lat для оборудования/ОС производилось 2,77 как медиана и 23,25 микросекунды в качестве максимальной латентности.

 Смежные вопросы

  • Нет связанных вопросов^_^