Comments 20
Помимо инструментов, которые предоставляет PLX, использовали ли какое-либо еще оборудование для оценки качества сигнала?
0
А какие задачи решает на плате LATTICE?
И чем-то обоснован выбор именно LATTICE?
И чем-то обоснован выбор именно LATTICE?
0
В данный момент — никаких.
На этапе разработки — мы предполагали (и до сих про предполагаем), что в ряде применений будет необходимость изменять стартовую конфигурацию коммутатора либо изменять какие-то его параметры на лету. Конечно, большинство из этих потребностей может реализовать хост система инбэндно — но для этого потребуется специальный драйвер для этого адаптера.
В частности мы предполагали, что нам нужно будет определять тип внешнего кабеля и модифицировать под него параметры приемников/передатчиков.
Для этого мы внедрили CPLD и небольшой DIP-переключатель для задания режимов.
В данный момент CPLD ничего не делает.
Почему именно Lattice?
Просто этот производитель мне нравится. У него очень вкусные и недорогие CPLD, удобная система разработки и хорошая информационная поддержка.
На этапе разработки — мы предполагали (и до сих про предполагаем), что в ряде применений будет необходимость изменять стартовую конфигурацию коммутатора либо изменять какие-то его параметры на лету. Конечно, большинство из этих потребностей может реализовать хост система инбэндно — но для этого потребуется специальный драйвер для этого адаптера.
В частности мы предполагали, что нам нужно будет определять тип внешнего кабеля и модифицировать под него параметры приемников/передатчиков.
Для этого мы внедрили CPLD и небольшой DIP-переключатель для задания режимов.
В данный момент CPLD ничего не делает.
Почему именно Lattice?
Просто этот производитель мне нравится. У него очень вкусные и недорогие CPLD, удобная система разработки и хорошая информационная поддержка.
0
Урааа, новая рубликация и много буКОВок! Почитаем!
0
«Работа на системном клоке в результате тестирования нам не понравилась» — чем именно не понравилось?
0
Системный клок в используемых нами рабочих станциях — не очень хорош в плане джитттера.
Error Rate при работе от системного клока при тех же настройках коммутатора — значительно выше.
Ну и в целом не хочется зависеть от материнской платы на таких рисковых длинах. Мы же никак не можем на нее повлиять.
В итоге канал хост-адаптер работает на системном клоке, как любая стандартная PCIe карта расширения, а внешние интерфейсы адаптера — на собственном.
Экономия на паре корпусов клоковой подсистемы в данном случае не покрывает возможные риски.
Error Rate при работе от системного клока при тех же настройках коммутатора — значительно выше.
Ну и в целом не хочется зависеть от материнской платы на таких рисковых длинах. Мы же никак не можем на нее повлиять.
В итоге канал хост-адаптер работает на системном клоке, как любая стандартная PCIe карта расширения, а внешние интерфейсы адаптера — на собственном.
Экономия на паре корпусов клоковой подсистемы в данном случае не покрывает возможные риски.
0
работа с производительностью 32 ГБ/с представляется мне весьма сомнительной.
A если на шине висят 100-180 PCIe устройств, которые «отгрызают» 2-3.5 ГБ на I/O?
0
Простите, я не понял Ваш вопрос.
В цитируемой Вами фразе я всего лишь имел в виду, что некорректно просто брать физический предел интерфейса, умножать его на 2 и обещать такой troughput. А именно это обычно и делается производителями в буклетах. Те же упомянутые мной Dolphin так и пишут — up to 32GB/s.
В цитируемой Вами фразе я всего лишь имел в виду, что некорректно просто брать физический предел интерфейса, умножать его на 2 и обещать такой troughput. А именно это обычно и делается производителями в буклетах. Те же упомянутые мной Dolphin так и пишут — up to 32GB/s.
+1
некорректно просто брать физический предел
даже если мы тупо гоним из одного PCIe устройства в другое(или из списка одних в другие/соседние),
при максимальной памяти и процессорах?
умножать его на 2 и обещать такой troughput
а умножать на 1.2 или 1.5 уже чеснее, или тоже попахивает маркетингом?
ПС не будте излишне строги к моим вопросам
0
Смотрите — если Ваш хост — это FPGA с чем-то рукописным и один абонент. То в принципе Вы можете приблизиться к заветным 16ГБ/с в одну сторону. И даже к суммарному 32 ГБ/с при независимых потоках в обе стороны. Для этого нужно слать максимально большие пакеты. То есть теоретически физика интерфейса и достаточно низкая latency коммутатора (150нс) — позволяют это сделать.
Если перейти к более реальным вещам. То мы видели производительность порядка 60% от физически возможного при соединении x86 системы с PLX PEX9797 — этот коммутатор имеет внутри DMA и виртуальный NIC. Собственно в данном эксперименте мы работали с PEX9797 как обычным сетевым адаптером и проверяли скорость iperf'ом. На сколько этот показатель можно увеличить — гадать не берусь.
Одновременная работа большого количества устройств на одном root комплексе — это предмет исследований. Но на мой взгляд узким горлом тут будет не коммутатор.
Если перейти к более реальным вещам. То мы видели производительность порядка 60% от физически возможного при соединении x86 системы с PLX PEX9797 — этот коммутатор имеет внутри DMA и виртуальный NIC. Собственно в данном эксперименте мы работали с PEX9797 как обычным сетевым адаптером и проверяли скорость iperf'ом. На сколько этот показатель можно увеличить — гадать не берусь.
Одновременная работа большого количества устройств на одном root комплексе — это предмет исследований. Но на мой взгляд узким горлом тут будет не коммутатор.
0
даже если мы тупо гоним из одного PCIe устройства в другое
И еще нужно сказать следующее. Указанный Вами сценарий в реальной жизни — это достаточно редкое явление. Обычно PCIe устройства не имеют собственной памяти, и гнать в него ничего нельзя. Как правило работа с PCIe устройством заключается в том, что Вы сообщаете ему где в Вашей системной памяти находится его (PCIe устройства) буфер и далее это PCIe устройство работает с Вашей системной памятью посредством механизма DMA.
0
Указанный Вами сценарий в реальной жизни — это достаточно редкое явление
однозначно,
но (как выше я писал) и наличие 100-180 PCIe устройств ОДНОВРЕМЕННО на одном root комплексе это тоже редко, а именно это(дерево) и нужно было инициализировать.
Вот мне и было интересно, а нах… зачем такого монстра лепить? Не ради ли того, чтобы выжать до последней капли маркетинговую производительность?
0
Я начинаю думать, что сценарий 100-180 PCIe устройств — это что-то из обсуждения в наших предыдущих публикациях?
Ежели так, то в наших сценариях не предполагается одновременный доступ ко всем устройствам в отдельно взятый момент времени. Нам важно просто иметь к ним доступ в рамках одного PCIe дерева. Но это не значит что мы будем делить полосу пропускания между ними.
Ежели так, то в наших сценариях не предполагается одновременный доступ ко всем устройствам в отдельно взятый момент времени. Нам важно просто иметь к ним доступ в рамках одного PCIe дерева. Но это не значит что мы будем делить полосу пропускания между ними.
0
PCIe Slave устройство отсылает PCIe Completion Response не на каждую полученную транзакцию, а только на Non-Posted transactions (транзакции чтения). Для Posted транзакции (записи) на уровне TLP траффик идет в одну сторону.
Эти преусловутые 16 ГБ в одну- конечно, даже теоретически недостижимая скорость даже для posted transactions. В первую очередь это связано с тем, что пакет помимо полезных данных для передачи (payload, размером до 256 байт) имеет еще служебный заголовок около 20 байт. Плюс надо учесть DLLP транзакции.
Эти преусловутые 16 ГБ в одну- конечно, даже теоретически недостижимая скорость даже для posted transactions. В первую очередь это связано с тем, что пакет помимо полезных данных для передачи (payload, размером до 256 байт) имеет еще служебный заголовок около 20 байт. Плюс надо учесть DLLP транзакции.
0
Да, Вы правы.
За одним исключением.
Размер Payload определяется содержимым конфигурационных регистров и может быть намного больше чем 256 байт. В частности в используемом нами коммутаторе — это 2048.
Ну и немного конкретизирую Ваш пост. Posted транзакции — это не все транзакции записи в целом, а только транзакции Memory Write и сообщения.
За одним исключением.
Размер Payload определяется содержимым конфигурационных регистров и может быть намного больше чем 256 байт. В частности в используемом нами коммутаторе — это 2048.
Ну и немного конкретизирую Ваш пост. Posted транзакции — это не все транзакции записи в целом, а только транзакции Memory Write и сообщения.
0
Не я в курсе, что MAX_PAYLOAD_SIZE может быть до 4096 байт, но на практике никогда не видел, чтобы было больше 256. По спецификации ведь этот параметр должен быть одинаковым для всех устройств в дереве и равен минимальному из поддерживаемых. Вы используете передачи с payload 2048 получается между окончеными устройствами, а не с хостом?
Тоже, кстати, не совсем понятно зачем такой большой payload. Аргументы против
1) Сильно страдает latency. Ведь пакет надо сначала принять, а затем передать дальше. Или у вас cut through pcie switch?
2) Пропускная способность сильно не увеличиться. Ведь уже с payload 256 байт она около 90% от этих 16 ГБ.
Тоже, кстати, не совсем понятно зачем такой большой payload. Аргументы против
1) Сильно страдает latency. Ведь пакет надо сначала принять, а затем передать дальше. Или у вас cut through pcie switch?
2) Пропускная способность сильно не увеличиться. Ведь уже с payload 256 байт она около 90% от этих 16 ГБ.
0
Sign up to leave a comment.
Как подружить PCIe с 10-метровыми медными кабелями и 100-метровой оптикой