Дело именно в оверхедах, о которых я говорил с самого начала — на упаковку-распаковку layered-данных. На гигабайтных скоростях они внезапно оказываются заметными.
И, собственно, в IB protocol stack уже вложили кучу усилий по удалению этих оверхедов, а в etherned — еще нет. Это не считая того смешного факта, что тот же iWARP/iSER реализован для линукса в рамках инфинибендовского стека OpenFabrics (возможно, есть и другие реализации, конечно)
Если смотреть на первые 100 из supercomputers top500, то внезапно выяснится что
1) на 10GbE интерконнекте там только один №72
2) а на винде — полтора, один Linux/Windows, второй — Windows.
MS на этот рынок очень хочет, даже Win2008 Server HPC Edition выпустила.
Но быстрый сторадж — это другая история, не обязательно HPC
No. iWARP is a very complex solution for bringing RDMA capability to Ethernet. iWARP is really RDMAP over DDP over MPA over TCP, and this complexity is the reason for the higher CPU overhead and higher latency (6-10usec) when compared to InfiniBand.
Никто не спорит с тем, что информацию о топологии собрать можно. Равно, как никто не спорит с тем, что на Ethernet можно сделать low latency решение, благо хостовое оборудование вообще идентично во многих случаях (карты 40G/IB), а ether-свитчи медленнее IB-шных (port to port) всего-то раза в два.
И никто не спорит с тем, что можно сделать bypass мимо layering, получив низкие задержки в драйвере (см. выше про одинаковость оборудования).
Разница в том, что на ethernet это *можно* сделать, а на IB — *уже* сделано. Поэтому если выбирать решение для HPC сегодня, то выбор — очевиден.
Когда сделают (не «можно сделать», а реально сделают) — тогда и посмотрим.
Сценарий когда «блейды на полной скорости обмениваются данными» и упираются в bandwidth/latency интерконнекта — это типичный такой случай для высокопроизводительных вычислений.
Вот представьте, что у нас есть кластер с более чем одним свитчем (задержки на свитче — допустим 200нс) и нам надо спланировать некую расчетную задачу.
Разумно распределить ее так, чтобы те ноды, которым нужно более тесное общение между собой — сидели бы на одном свитче.
Без знаний о топологии сети этого сделать нельзя. Понятно, знание можно принести в программу вручную (как-то вбив туда топологию), но автоматически оно как-то надежнее.
Ну вот принципиальное отличие IB и заключается в том, что юзерское приложение (сервер) может узнать о топологии сети и затем это знание разумно использовать.
Например, для правильного броадкаста данных в кластере.
Они достоверные, в том смысле что воспроизводятся.
Другой вопрос, что там метрика — интересная лично мне т.к. я делал сторадж для рабочей станции, а это — один поток I/O в интерактивной программе. К энтерпрайз-стораджу она не имеет отношения.
Претензии же ваши к IPoIB непонятны — вы же сами писали выше:
«Современные ЦП тратят абсолютно мизерные ресурсы на сворачивание-разворачивание пакетов „
И, собственно, в IB protocol stack уже вложили кучу усилий по удалению этих оверхедов, а в etherned — еще нет. Это не считая того смешного факта, что тот же iWARP/iSER реализован для линукса в рамках инфинибендовского стека OpenFabrics (возможно, есть и другие реализации, конечно)
1) на 10GbE интерконнекте там только один №72
2) а на винде — полтора, один Linux/Windows, второй — Windows.
MS на этот рынок очень хочет, даже Win2008 Server HPC Edition выпустила.
Но быстрый сторадж — это другая история, не обязательно HPC
Q: Can iWARP be faster than InfiniBand?
No. iWARP is a very complex solution for bringing RDMA capability to Ethernet. iWARP is really RDMAP over DDP over MPA over TCP, and this complexity is the reason for the higher CPU overhead and higher latency (6-10usec) when compared to InfiniBand.
И никто не спорит с тем, что можно сделать bypass мимо layering, получив низкие задержки в драйвере (см. выше про одинаковость оборудования).
Разница в том, что на ethernet это *можно* сделать, а на IB — *уже* сделано. Поэтому если выбирать решение для HPC сегодня, то выбор — очевиден.
Когда сделают (не «можно сделать», а реально сделают) — тогда и посмотрим.
Разумно распределить ее так, чтобы те ноды, которым нужно более тесное общение между собой — сидели бы на одном свитче.
Без знаний о топологии сети этого сделать нельзя. Понятно, знание можно принести в программу вручную (как-то вбив туда топологию), но автоматически оно как-то надежнее.
Например, для правильного броадкаста данных в кластере.
Другой вопрос, что там метрика — интересная лично мне т.к. я делал сторадж для рабочей станции, а это — один поток I/O в интерактивной программе. К энтерпрайз-стораджу она не имеет отношения.
Претензии же ваши к IPoIB непонятны — вы же сами писали выше:
«Современные ЦП тратят абсолютно мизерные ресурсы на сворачивание-разворачивание пакетов „
А вы в том сообщении сравнивали свитчевый delay с end-to-end, что удивительно мне
Интел для своих 10G-карт похвалялся 2 микросекундами, кажется, но непонятно с каким свитчом
В свитче — пишут что 100-165 наносекунд port-to-port у мелланоксовских свитчей.
На ebay, естественно.
Не с первого раза, но рабочий комплект набрался (1 или 2 кабеля работали на 10G ether, но не работали с IB, так и работают с ether теперь)
Mellanox, когда 56G IB презентовал, клялся что end-to-end latency — в пределах 700нс через один свитч.
Полтора раза для суперкомпьютерных задач — заметная разница.
Лично тестировал: blog.lexa.ru/2012/09/02/domashnii_storadzhboks_proizvoditelnost_iscsisrp_freebsdlinux.html
Бенчмарка под мои нужды, возможно что при другом паттерне разница в скорости не такая большая.