Мы подошли к стадии нашего проекта, когда мы хотим вывести программное обеспечение на новый уровень, обычно время отклика составляет 20 мкс или меньше. С точки зрения программного обеспечения он настолько хорош, насколько это возможно (хотя есть место для немного большего улучшения), однако теперь мы стремимся атаковать аппаратную сторону вещей.
Мне было интересно, не могли бы вы дать предложения о том, как мы можем достичь этого подвига. Нужны ли нам какие-либо особые кабели, программные стеки, архитектуры или другие технологии?
Ультра низкие задержки? Вы можете играть с забавными игрушками. Обычной платформой для такого типа сетей с действительно малой задержкой будет InfiniBand (Некоторые из нас, хотя и не я, использовали этот материал). Используется в высокопроизводительных вычислениях и других вычислительных областях, где требуются низкие задержки, высокая пропускная способность и масштабируемость. Также часто встречается в некоторых областях научных вычислений.
Частично то, как IB получает низкие задержки, - это выравнивание сети. Подобно Fibre Channel, это сеть с коммутацией 2 уровня, которая действительно помогает снизить задержку.
Вы не найдете приспособления для этого в местном MicroCenter. Использование IB для работы в сети вполне выполнимо, хотя TCP / IP, возможно, является посредственным выбором протокола, если вам нужны минимально возможные задержки.
Из-за небольшого объема на рынке сетевые адаптеры IB очень дороги по сравнению с 1 ГБ Ethernet, хотя они выгодно отличаются от адаптеров 10GbE. Коммутаторы IB также дороги, хотя, похоже, их цена почти равна цене коммутаторов 10GbE с аналогичной плотностью портов.
Если IB вас настораживает, 10 Gigabit Ethernet может помочь вам в большинстве случаев, он очень хорошо поддерживается всем и знаком для обычных компьютерных фанатов. Если вы спроектируете свой Ethernet так, чтобы в нем был один, может быть, два коммутатора, и все порты были в одной подсети, вы можете получить аналогичные низкие задержки. В зависимости от того, сколько именно задержки вы готовы терпеть, это может быть более понятная архитектура, чем была бы IB.
Вы даже не говорите, какую сетевую технологию планируете использовать.
Если предположить, что Ethernet, и разделив минимальную длину кадра в 520 байтов на требуемое RT 20 мкс, вы получите примерно 50 МБ / с. Далее, предполагая, что вашему программному обеспечению требуется как минимум половина времени на обработку, вы используете скорость 100 МБ / с и, вероятно, в этот момент смотрите на 10GE, чтобы учесть задержки переключения и передачи.
Опять же, у вас достаточно свободного места - поэтому мне интересно, почему вы беспокоитесь о таких вещах, как типы кабелей, которые, безусловно, не повлияют на вашу задержку в той степени, в которой она станет заметной.
Редактировать: Я привык думать, что решение зависит от конкретной проблемы. Хотя время ожидания и транспортные характеристики 10GE могут быть хорошими для одного приложения, они могут представлять проблему для другого. С 10 GE у вас не будет гарантированных RTT, а будет только доставка по максимуму. Этого может быть достаточно, если ваша сеть достаточно перестроена, и ваше приложение может получать ответ в течение 20 мкс «большую часть времени». Если время отклика является жестким пределом, и из-за этого транзакция может прерваться, вы можете изучить другие сетевые технологии (в основном на основе ячеек), например Банкомат.
Что касается Infiniband, вы, вероятно, планируете серьезно переписать сетевые операции вашего приложения для использования RDMA, если вы хотите эффективности.
Еще одна вещь, которую следует учитывать, - это расстояние между компонентами - 10 мкс - это как раз достаточно времени, чтобы свет прошел 1,6 км и обратно - без каких-либо задержек компонентов и без учета битового времени. Таким образом, вам придется иметь короткие расстояния и короткие последовательности запросов / ответов, чтобы добраться туда.
В целом речь идет не об отдельных компонентах, а о выбранной технологии.