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

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



Тестировалось на 3.2 GHz core i5 c 16 GB памяти и в рабочей машине 2 х 2.8 GHz Xeona c 32 GB памяти.
В FPGA Kintex325 vfifo в 32 MB на DDR3 - был суточный прогон с доп нагрузкой на систему - сбоев не было.

Успехов! Rob.

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



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

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


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

Удачи! Rob.

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

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

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

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

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

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

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


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


Вот этого я и не могу понять. К сожалению (а может и к счастью) с системами на 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 ядер загружали различным мусором для прогрева помещения. И все работает - что я делаю не так?


Понятное дело - кстати данные в выше приведенной системе копируются с уровня драйвера в 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.