[Flood 12]

16 часов назад, faa сказал:

Под линуксом мы и пишем прямо в gpu. Только gpu д.б. quadro/tesla/ampere и т.п., где разлочена прямая запись.

У вас замирания были при записи в системную память CPU, или в GPU?

Какой была длительность замираний, если сохранилась инфа?

2 часа назад, faa сказал:

Заменили хосты на EPYC 7002 и все стало хор и ок. Замираний нет, рестартов нет, потерь нет.

Опять-таки, в какой ситуации пропали замирания? Или они просто стали намного короче?

Также сталкивался с замираниями на Intel, при прямом подключении Gen3 PCIe к процессорам Xeon E3v2, E5v3. никакой тюнинг не помог. Хорошо, поток был не очень большим (порядка 1 Гбайт/сек) и удалось обойтись внутренними буферами в ПЛИС.

[RobFPGA 27]

29 minutes ago, Flood said:

Опять-таки, в какой ситуации пропали замирания? Или они просто стали намного короче?

Также сталкивался с замираниями на Intel, при прямом подключении Gen3 PCIe к процессорам Xeon E3v2, E5v3. никакой тюнинг не помог. Хорошо, поток был не очень большим (порядка 1 Гбайт/сек) и удалось обойтись внутренними буферами в ПЛИС.

PCie  не гарантирует постоянную  пиковую  скорость. Ведь хоть она на физ. уровне точка-точка по своей структуре  это шина.  И без  буферизации в FPGA перед контроллером PCIe работать нельзя.  Да и не только дело в PCIe.  Тот же доступ в память тоже шарится. И если вы пишете в память, а параллельно идет массовый  доступ к памяти из CPU то это тоже  создает  паузы на PCie.    

[dxp 32]

42 минуты назад, dmitry-tomsk сказал:

Первый запрос выравнивающий - 4 байта, последний - неполный. Остальные по 128 байт. Раньше материнки только 128 поддерживали, да и можно payload size принудительно ограничить в самой плис. Ну или учесть.

Ну, так об этом и речь. Вы говорили, что чтение - это несложно, и что пересечения 4к границ в случае большого непрерывного массива в хостовой памяти почему-то исключены. Вот простой пример: запрос 16 байт с адреса 0xfffc. Можете послать такой MRd? В каком виде придёт ответ?

[dmitry-tomsk 0]

2 hours ago, dxp said:

Ну, так об этом и речь. Вы говорили, что чтение - это несложно, и что пересечения 4к границ в случае большого непрерывного массива в хостовой памяти почему-то исключены. Вот простой пример: запрос 16 байт с адреса 0xfffc. Можете послать такой MRd? В каком виде придёт ответ?

Пусть не 16, а 272 с адреса fffc Первый запрос 4 - байта, второй 128, третий 128, четвёртый 12. Пересечений не будет ни в одном из запросов.У меня было только требование - полная длина пакета кратна 32 бит, так как у fifo на выходе не было byte enable. Даже в случае со страницами 4к, только первая страница и первый её запрос требует выравнивания. Попростие   программиста вывести физические адреса страница посе лока, сразу видно будет.  Длина выравнивая addr1 % 128 если запросы по 128 байт

[dmitry-tomsk 0]

20 hours ago, faa said:

Под линуксом мы и пишем прямо в gpu. Только gpu д.б. quadro/tesla/ampere и т.п., где разлочена прямая запись.

А не пробовали bar сделать 1 мбайт и читать кусочками посредством DMA gpu без драйвера для плис?

[dxp 32]

1 час назад, dmitry-tomsk сказал:

Пусть не 16, а 272 с адреса fffc Первый запрос 4 - байта, второй 128,

Прекрасно. Получили 4 байта, записали в выходное слово, ширина которого 16 байт. Получили первое слово второго запроса, все 16 байт. Как с первым словом объединять?

[dmitry-tomsk 0]

30 minutes ago, dxp said:

Прекрасно. Получили 4 байта, записали в выходное слово, ширина которого 16 байт. Получили первое слово второго запроса, все 16 байт. Как с первым словом объединять?

откуда 16? Выходн 32 бит - 4 байта, tlp были 32 битные, один регистр памяти - хвостик пишем сначала (пусть 2 байта), потом от целого слова 2 старших байта в регистр памяти - два младших на выходд вместе с содержимым регистра памяти 

[faa 4]

5 часов назад, Flood сказал:

У вас замирания были при записи в системную память CPU, или в GPU?

Какой была длительность замираний, если сохранилась инфа?

Опять-таки, в какой ситуации пропали замирания? Или они просто стали намного короче?

Также сталкивался с замираниями на Intel, при прямом подключении Gen3 PCIe к процессорам Xeon E3v2, E5v3. никакой тюнинг не помог. Хорошо, поток был не очень большим (порядка 1 Гбайт/сек) и удалось обойтись внутренними буферами в ПЛИС.

Замирания при записи в системную память по dma. При этом биос был настроен с учетом всех рекомендаций mellanox и прочих HTS/HPC.

Операционка тоже настраивалась: изоляция ЦПУ, выключение irq-balance и т.п. Проблема была именно в замирании транзакций по PCIe.

 

На форуме интел я нашел, что народ жаловался на такие же замирания.

Какой-то инженегр (по нику не поймешь кто) из интела отписал, что "да, жалуются, поправить можно, какие-то биты в msr, уточню-отпишусь". И затих.

 

Замирания на интеле были на десятки миллисекунд. С чем связано - хз, возможно с архитектурой.

На ксеонах до скалябельных было очень плохо, на больших постоянных потоках не работают. В пике неплохие цифры показывают, но недолго :)

Скалябельные первые и вторые чуть лучше, но тоже замирания были. Измеряли по длительности сигналов full в буферных фифо.

Можно поискать результаты, но уже почти 4 года прошло. Проще заново промерять. ;) Если время будет.

У интела еще явная проблема - приоритет доступа к контроллеру памяти со стороны dma pcie один из самих низких.  Может это как-то настраивается, но либо это тайна, либо никто не знал, да еще и забыл.

 

Про EPYC надо писать отдельно - там много.

Замирания может и не пропали, но заработало устойчиво вот на таком железе:

MZ31-AR0-00, биос version: R06.

В конторе есть еще несколько железок под EPYC, по ним тоже есть статистика.

Местами не очень хорошая ;) Особенно по супермикро :(

[faa 4]

5 часов назад, RobFPGA сказал:

PCie  не гарантирует постоянную  пиковую  скорость. Ведь хоть она на физ. уровне точка-точка по своей структуре  это шина.  И без  буферизации в FPGA перед контроллером PCIe работать нельзя.  Да и не только дело в PCIe.  Тот же доступ в память тоже шарится. И если вы пишете в память, а параллельно идет массовый  доступ к памяти из CPU то это тоже  создает  паузы на PCie.    

А никто и не требовал постоянной пиковой. Нужна была постоянная скорость в ~0.6 от пиковой (с учетом оверхеда и размеров TLP) для Ген3х8.

Буфера были. Многоуровневые. Перед коркой PCIe фифо толстое, перед фифо буфер в ddr. Не считая буферов в конвейере.

Про архитектуру современных ЦПУ немного в курсе.

Но, ИМХО, EPYC поправильнее сделан по сравнению с интел.

Скоро еще aarch64 попробуем. Вот тогда и посмотрим "чьи лыжи не едут" ;)

[RobFPGA 27]

1 minute ago, faa said:

А никто и не требовал постоянной пиковой. Нужна была постоянная скорость в ~0.6 от пиковой для Ген3х8.

Буфера были. Многоуровневые. Перед коркой PCIe фифо толстое, перед фифо буфер в ddr. Не считая буферов в конвейере.

Тогда  странно, у меня было несколько систем  на Intel с похожими параметрами (x8 Gen3, поток 4..6 GB/s) и таких особых проблем не было.    

[dxp 32]

1 час назад, dmitry-tomsk сказал:

откуда 16?

PCIe Gen2 x4, 7 Series, это будет 64 бита на 250 МГц (это скорость, на которой едва можно 1600 МБ/с выжать, которая вам нужна). Что-то осмысленное делать на такой частоте на седьмой серии довольно тяжело, поэтому разумно перейти на формат 128@125MHz. Отсюда 16 байт. Но даже если остаться том тактовом домене, то будет 8 байт ширина шины. Приняли 4 (первая транзакция), потом приняли 8 эн раз (вторая), "склеиваем" транзакции. Возникает необходимость сдвигать байтики вдоль всего стрима, начиная со второй транзакции.

[dmitry-tomsk 0]

8 minutes ago, dxp said:

PCIe Gen2 x4, 7 Series, это будет 64 бита на 250 МГц (это скорость, на которой едва можно 1600 МБ/с выжать, которая вам нужна). Что-то осмысленное делать на такой частоте на седьмой серии довольно тяжело, поэтому разумно перейти на формат 128@125MHz. Отсюда 16 байт. Но даже если остаться том тактовом домене, то будет 8 байт ширина шины. Приняли 4 (первая транзакция), потом приняли 8 эн раз (вторая), "склеиваем" транзакции. Возникает необходимость сдвигать байтики вдоль всего стрима, начиная со второй транзакции.

Если буду переделывать, то сдвигать не буду точно. Это было потому, что сначала делал корку, а потом драйвер (готовый jungo). Достаточно выровнять буфер по границе 16 байт. Да мне приём и не нужен, достаточно процессорных 32-битных команд по слову, чтобы axi-lite мастера сделать.

[dxp 32]

3 минуты назад, dmitry-tomsk сказал:

Если буду переделывать, то сдвигать не буду точно. Это было потому, что сначала делал корку, а потом драйвер (готовый jungo). Достаточно выровнять буфер по границе 16 байт. Да мне приём и не нужен, достаточно процессорных 32-битных команд по слову, чтобы axi-lite мастера сделать.

Ну, если не нужно, то не нужно, я ж не настаиваю. :) Возражение было только на тему, что чтение (конечно, произвольных транзакций, т.е. с произвольных адресов и произвольной длины и на максимальной скорости) - это просто. Это, увы, совсем не просто. Особенно, когда при широком слове (16 байт и более) принимать CplD с RCB 64, когда они там прилетают от 1 до 64, а также 128 или 256, и это непредсказуемо. И когда нужно сдвигать 32-битные слова (при пересечении границ 4к) и байты (когда адрес не кратен 32-разрядному слову). И всё это на потоке в реальном времени на высокой скорости. Да, всё реализуемо, но потребовало прилично времени и усилий.

 

Доступ к регистрам у нас тоже ординарный 32-разрядный, сделан через самодельный мост TLP-AXI4-Lite. По чтению и по записи. Это и в самом деле достаточно тривиально. И просто запись в хостовую память по выровненным адресам и без пересечения границ страниц тоже реализуется достаточно несложно. Накладных там минимум, проводил тесты на скорость, заливал 4 МБ буфер, скорость получалась 14.5 Gbps (Gen2 x4, MPS - 256 байт). Хорошо, когда есть возможность выбирать условия передачи. В прикладном проекте, к сожалению, такой возможности нет (адреса и длины произвольные).

[faa 4]

1 час назад, RobFPGA сказал:

Тогда  странно, у меня было несколько систем  на Intel с похожими параметрами (x8 Gen3, поток 4..6 GB/s) и таких особых проблем не было.    

А ПЛИС какие?

Платы в слот вставлялись или через кабель 2м и свитч/ретаймер?

[RobFPGA 27]

1 minute ago, faa said:

А ПЛИС какие?

Kintex 7,  Kintex US,  Virtex 7,