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