Jump to content

    

Recommended Posts

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
29 minutes ago, Flood said:

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

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

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

Share this post


Link to post
Share on other sites
42 минуты назад, dmitry-tomsk сказал:

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

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

Share this post


Link to post
Share on other sites
2 hours ago, dxp said:

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

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

Share this post


Link to post
Share on other sites
20 hours ago, faa said:

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

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

Share this post


Link to post
Share on other sites
1 час назад, dmitry-tomsk сказал:

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

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

Share this post


Link to post
Share on other sites
30 minutes ago, dxp said:

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

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

Share this post


Link to post
Share on other sites
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, по ним тоже есть статистика.

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

Share this post


Link to post
Share on other sites
5 часов назад, RobFPGA сказал:

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
1 minute ago, faa said:

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

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

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

Share this post


Link to post
Share on other sites
1 час назад, dmitry-tomsk сказал:

откуда 16?

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

Share this post


Link to post
Share on other sites
8 minutes ago, dxp said:

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

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

Share this post


Link to post
Share on other sites
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 байт). Хорошо, когда есть возможность выбирать условия передачи. В прикладном проекте, к сожалению, такой возможности нет (адреса и длины произвольные).

Share this post


Link to post
Share on other sites
1 час назад, RobFPGA сказал:

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

А ПЛИС какие?

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.