[Dimidrol 0]

EDIT: сразу не прочитал... Какой раид!!!

 

Вам человек дело говорит, а вы его и слушать не желаете. Даже я понял, что рейд там ни при чем. Ключевое слово -

непрерывный трафик 4 GByte/s распаралеленный по 4м 10G Ethernet - собирает его в памяти

[RobFPGA 27]

Приветствую!

 

Какой процессор в системе? Есть ли кэширование на стороне FPGA карты? Не возникало ли ситуаций, когда внезапно исчерпывались кредиты и поток замирал?

 

Тестировалось на 3.2 GHz core i5 c 16 GB памяти и в рабочей машине 2 х 2.8 GHz Xeona c 32 GB памяти.

В FPGA Kintex325 vfifo в 32 MB на DDR3 - был суточный прогон с доп нагрузкой на систему - сбоев не было.

 

Успехов! Rob.

[EvilWrecker 0]

Но на таком уровне задачу на коленке не решит - попытка приделает звершку к стандартному интерфейсу тянет за собой необходимость соблюдать этот стандарт начиная от электрический параметров и кончая временными и функциональными. То есть куча проблем а что взамен? - с экономим 10-30% пропускной памяти и 10 % CPU ? Думаю тут надо внимательно на системном уровне для начала подумать - прикинуть + и - той или иной реализации с конкретными цифрами.

 

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

 

из самого большого - сервер с 8-ю бордами H8QG6-F, в каждой по PCIe заходил трафик из своей TR4, буфферизовался на терабайте внутренней памяти и перенаправлялся на АМДшную сдвоенную карту, на которой и проходил основной расчет. Трафик с PCIe от TR4 почти полностью убивал способность 64 наличевствующих обычных ядер хоть что-то посчитать (получалось около 10% от пика, в то время, как без PCIe трафика все разгонялось до 60% от пика). Трафик с GPU всегда можно сделать блочно, поэтому там все было классно, а в TR4 тогда буфферизация на внутренней памяти не была задействована, так как слотов не хватало.

 

Зион + пара гпу на плате + возможно псие свич на рамдиски для длинных буферов - наружу можно выводить через что угодно, от усб 3.0 с тандерболтом заканчивая оптикой. Выйдет дешевле и "дубовее" чем покупная серверная платка + отдельные видеокарты , к тому же легко масштабировать. На всякий случай подмечу, что современные корпуса гпу и цпу спроектированы таким образом чтобы использовать как можно меньшее количество слоев- в 1U запихнуть это добро можно без существенных проблем.

[RobFPGA 27]

Приветствую!

 

из самого большого - сервер с 8-ю бордами H8QG6-F, в каждой по PCIe заходил трафик из своей TR4, буфферизовался на терабайте внутренней памяти и перенаправлялся на АМДшную сдвоенную карту, на которой и проходил основной расчет. Трафик с PCIe от TR4 почти полностью убивал способность 64 наличевствующих обычных ядер хоть что-то посчитать (получалось около 10% от пика, в то время, как без PCIe трафика все разгонялось до 60% от пика). Трафик с GPU всегда можно сделать блочно, поэтому там все было классно, а в TR4 тогда буфферизация на внутренней памяти не была задействована, так как слотов не хватало.

Вы что данные программно через CPU читали из PCIe 8-()!!! Как может PCIe Gen2 x4 жалкие 2 GB трафика забить суммарную пропускную памяти этой платы в 100 GByte/s.

 

Удачи! Rob.

[iiv 18]

Вы что данные программно через CPU читали из PCIe 8-()!!! Как может PCIe Gen2 x4 жалкие 2 GB трафика забить суммарную пропускную памяти этой платы в 100 GByte/s.

я все понимаю, что каждому чужое решение кажется очень не оптимальным.

 

Я бы не писал об это если бы этим не занимался 7 лет.

 

Я бы не писал бы об этом, если бы конкретно в этой ситуации с этой картой (H8QG6-F) не происходило бы следующее: трафик с PCIe был всего-то 1ГБайт/с, но вспомним, что на TR4 всего есть чуть меньше 2МБайт M9K и похожей памяти, реально, если работать двумя сегментами, можно писать только по пол мегабайта, то есть пол мегабайта со скоростью 2ГБайта в секунду напрочь забивают один из двух каналов в каждом процессорном блоке.

 

Память должна быть замаплена, иначе, по PCIe работать нельзя, чтобы ее притащить в общую, то есть надо копировать, то есть размаппим и копируем, итого, второй канал тоже серьезно забит, примерно на 30-40%, а в реальности серьезно больше, так как остальные процессоры к этой памяти хотят достучаться. Итого имеем напрочь забитые 16 ядер из 64, ну и примерно четверть от 100ГБайт,с трафика этой памяти тоже товось, то есть коту под хвост, а это суммарно со стоимостью TRки около 8 штук.

 

Итого, если мне в масспродакшене моя неведома зверюшка будет стоить дешевле восьми штук зелени и будет с меньшим гемором обходиться, я всеми конечностями за. Не так ли?

 

Вот по этому-то и вопрошаю, и совершенно не хочу вступать с кем-то в полемику как прикрутить очередной писиайный или уэсбешный костыль, это криво и стоит ужасных нервов, на которые я не готов.

[RobFPGA 27]

Приветствую!

 

я все понимаю, что каждому чужое решение кажется очень не оптимальным.

Я ни в коей мере не пытаюсь судить Ваши решения, я пытаюсь понять проблему чтобы самому потом на такое не нарыватся.

 

Я бы не писал бы об этом, если бы конкретно в этой ситуации с этой картой (H8QG6-F) не происходило бы следующее: трафик с PCIe был всего-то 1ГБайт/с, но вспомним, что на TR4 всего есть чуть меньше 2МБайт M9K и похожей памяти, реально, если работать двумя сегментами, можно писать только по пол мегабайта, то есть пол мегабайта со скоростью 2ГБайта в секунду напрочь забивают один из двух каналов в каждом процессорном блоке.

Вот этого я и не могу понять. К сожалению (а может и к счастью) с системами на AMD давно уже не работал.

Для систем с Intel я уже приводил примеры - буквально сегодня тестировали систему с Gen2 х8 на Kintex

Непрерывный поток с ADC - 2Gbyte/s, FPGA формируются кадры данных переменной длинны и добавляет заголовки. В худшем случае при малых размерах кадра суммарный поток увеличивается до 2.3 Gbyte/s - все это передается в память через scater/gater DMA. Поток который обслуживает DMA и дополнительно занимается выравниванием данных в памяти по заголовкам занимает %7-9 одного ядра!.

Еще один поток просматривает ВСЕ заголовки в памяти - строит хитрый индекс и пишет в отдельный файл. В худшем случае имеем как минимум чтение и обработку 1 GByte/s заголовков + запись результата ~1GByte/s. Поток который это делает занимает 40-60 % одного ядра. Полюс запись всего основного потока. Итого очень грубо как минимум 2*2.3 GB/s ввод/вывод, 2*1GB чтение/обработка ~6.4 GB/s из 25 GB/s 25% суммарной пропускной памяти одного проца. Параллельно остальные 6+8 ядер загружали различным мусором для прогрева помещения. И все работает - что я делаю не так?

 

Память должна быть замаплена, иначе, по PCIe работать нельзя, чтобы ее притащить в общую, то есть надо копировать, то есть размаппим и копируем, итого, второй канал тоже серьезно забит, примерно на 30-40%, а в реальности серьезно больше, так как остальные процессоры к этой памяти хотят достучаться. Итого имеем напрочь забитые 16 ядер из 64, ну и примерно четверть от 100ГБайт,с трафика этой памяти тоже товось, то есть коту под хвост, а это суммарно со стоимостью TRки около 8 штук.

Понятное дело - кстати данные в выше приведенной системе копируются с уровня драйвера в userspace, не знаю точно как это сделано в linux через маппинг или реально копирование.

Понятно что перемножение матриц не самый приятный алгоритм для памяти особенно DDR. Но чтобы такой малый поток так забивал пропускную памяти? Может алгоритм требовал копирование в невыгодном направление для DDR?

 

Итого, если мне в масспродакшене моя неведома зверюшка будет стоить дешевле восьми штук зелени и будет с меньшим гемором обходиться, я всеми конечностями за. Не так ли?

Не так - допустив такая приблуда есть и у вас в памяти ОДНОГО проца чудесным образом появляются новые данные. Другие процы тоже захотят поживится свежатинкой - то есть - копирование, занятие шины, ...упал, очнулся, гипс...

Ладно допустим воткнем каждому процу по собственной животинушке - упс. стомость в N раз (кстати 4 штуки 2x10G Ethernet стоят ~$4K ;) ) и доп проблемы с синхронизацией. К тому же решение с DDR3 swich выигрыша почти не даст так как swich - это РАЗДЕЛЕНИЕ полосы памяти.

Поэтому только вариант зверушки с TRUE DUAL PORT DDR3 memory поможет выиграть при 8GB/s всего до %30 на один контроллер памяти DDR3-1600. И все это надо будет разместить на одной планке - и DDR и FPGA и обеспечить синхронизацию между парами планок 8-().

 

Вот по этому-то и вопрошаю, и совершенно не хочу вступать с кем-то в полемику как прикрутить очередной писиайный или уэсбешный костыль, это криво и стоит ужасных нервов, на которые я не готов.

Ну USB я тоже за серьезный интерфейс не считаю (вернее не для таких применений). А вот PCIe это стандарт придуманный как раз раз для этого.

И кажется мне что нервов при разработке и отладке зверушки будет потрачено гораздо больше да еще и при негарантированном результате чем при работе с PCIe. При этом через пол-год новый тип памяти сделает зверушку ненужной а PCIe решение будет работать и там.

 

Естественно все это мое глубокое imho помноженное на жару от бесполезно работающих 6+8 ядер :)

 

Успехов! Rob.