Скорость одиночных транзакций Опции

[aosp]

Имеется Arria 2GX и связанный с нею модуль на базе NanoETX Intel Antom под LINUX
Наблюдается скорость следования одиночных транзакций
- по записи период следования примерно 120нс
- по чтению период следования примерно 1800нс

реальная задержка ответа на запрос чтения составляет менее 50нс...
Вопрос, это нормально что по чтению так медленно или где то что то не так?
Подскажите, можно ли ускорить темп одиночных транзакций чтения?

[Andrew Su]

Имеется Arria 2GX и связанный с нею модуль на базе NanoETX Intel Antom под LINUX
Наблюдается скорость следования одиночных транзакций
- по записи период следования примерно 120нс
- по чтению период следования примерно 1800нс

реальная задержка ответа на запрос чтения составляет менее 50нс...
Вопрос, это нормально что по чтению так медленно или где то что то не так?
Подскажите, можно ли ускорить темп одиночных транзакций чтения?

Приветствую.
Не буду расспрашивать об особенностях вашей реализации, тем более, что работаю на Xilinx.
Посоветую лишь http://www.4shared.com/file/05UAB2jM/PCI_E...rchitectur.html
Очень неплохая книга. Все, что и в стандарте, но более понятно.
А по времянкам на одиночных транзакциях у меня приблизительно так-же.
Удачи вам.

[dmitry-tomsk]

Имеется Arria 2GX и связанный с нею модуль на базе NanoETX Intel Antom под LINUX
Наблюдается скорость следования одиночных транзакций
- по записи период следования примерно 120нс
- по чтению период следования примерно 1800нс

реальная задержка ответа на запрос чтения составляет менее 50нс...
Вопрос, это нормально что по чтению так медленно или где то что то не так?
Подскажите, можно ли ускорить темп одиночных транзакций чтения?

Нельзя, светлый путь - только dma.

[aosp]

Нельзя, светлый путь - только dma.

Просто очень странно что разница между циклами почти в десять раз. Dma конечно здорово но если в приложении не используются блочные пересылки смысла от него тоже нет.

[dmitry-tomsk]

Просто очень странно что разница между циклами почти в десять раз. Dma конечно здорово но если в приложении не используются блочные пересылки смысла от него тоже нет.

А что странного? Для записи цпу выполняет команды записи в память одну за другой, а для чтения - нужно ждать ответа перед выполнением следующей команды, а задержка в pcie очень большая.

[aosp]

Какая же латентность у канала? Получается примерно 800-900нс в одну сторону.

[novartis]

По работе использую плату Stratix IV GX Dev. Kit, включена в режиме х8 в ПК под Fedore. Интервалы между запросами на запись порядка 40 нс, на чтение - 400 нс.

[aosp]

если я все правильно понимаю скорость следования одиночных транзакций не зависит от количества лэйнов.
а вот с чем связана моя латентность я уже ума не приложу... всеж 400нс это не 1800нс...
хотя может много зависит от руткомплекса, надо будет поэкспериментировать еще где нить

[nicvic]

По работе использую плату Stratix IV GX Dev. Kit, включена в режиме х8 в ПК под Fedore. Интервалы между запросами на запись порядка 40 нс, на чтение - 400 нс.

Сам использую Stratix IV GX Dev. Kit, но не могу получить такие же результаты. Смотрел времена на МБ с Intel P55 (160/1800) и с Intel 5500 (180/780). Использую PCIE Core от Altera для QSys (PCI 1.0 x8). Может кто что посоветует для уменьшения задержек? Может ядро какое другое (PLDA например)?

[syoma]

Наблюдается скорость следования одиночных транзакций
- по записи период следования примерно 120нс
- по чтению период следования примерно 1800нс

Можно спросить - чем Вы меряете скорость транзакций?

[syoma]

Еще раз в тему. Мы настроили обмен между SP605 и ML605 через PCIe свич. SP605 постоянно записывает данные в память ML605. Настроили пины на платах так, что SP605 меняет состояние пина, когда пакет отправляется, а ML605 - когда пакет принимается. На пины смотрим осциллографом.
В итоге реальная задержка - 1700+-50нс. Пробовали делать двухсторонний обмен - т.е. SP605 читает данные из памяти ML605 - получили 3400нс.
Вопрос - почему у меня ваши тайминги не получаются?
Ведь хост в этих делах, вроде как, участие не принимает? Или принимает?

[gerber]

Имеется Arria 2GX и связанный с нею модуль на базе NanoETX Intel Antom под LINUX
Наблюдается скорость следования одиночных транзакций
- по записи период следования примерно 120нс
- по чтению период следования примерно 1800нс

реальная задержка ответа на запрос чтения составляет менее 50нс...
Вопрос, это нормально что по чтению так медленно или где то что то не так?
Подскажите, можно ли ускорить темп одиночных транзакций чтения?

Всё абсолютно правильно, одиночные транзакции записи на порядок быстрее транзакций чтения. Это характерно для шин PCI/PCIe и связано с механизмом кэширования записи, т. н. Posted Write (отложенная запись). Когда вы записываете данные в плату - устройство (возможно, мост) может и "не торопиться" выполнять физическую запись, поэтому только запоминает в кэше и отпускает процессор, так как на дальнейшее выполнение программы это не влияет, а вот когда происходит чтение - устройство обязано сначала отработать все предыдущие posted-транзакции записи и только потом физическое чтение, которое невозможно отложить в принципе. Пока всё это не будет выполнено - процессор висит и ждёт, так как прочитанные данные влияют на дальнейший ход программы.

[dsmv]

Всё абсолютно правильно, одиночные транзакции записи на порядок быстрее транзакций чтения. Это характерно для шин PCI/PCIe и связано с механизмом кэширования записи,

Не совсем так. Транзакция записи идёт только в одну сторону, а транзакция чтения - туда и обратно. Вот и получается в два раза больше по времени.

[gerber]

Не совсем так. Транзакция записи идёт только в одну сторону, а транзакция чтения - туда и обратно. Вот и получается в два раза больше по времени.

Смайлик забыли поставить.
Вообще-то, у топикстартера разница времён на порядок.

[novartis]

Подниму старую тему, так как уже на протяжении 3 лет меня терроризирует начальник, почему время на чтение по PCIE составляет 400нс. Сейчас собрал новый проект на Arria V, на ней получилось 700нс на одиночное чтение и опять этот вопрос всплыл. Может кто расписать на пальцах, желательно с сылками на литературу, почему такая латентность?

[krux]

возьмем примерные значения времянок:
Tx Application (min packet) = 15нс
Tx Application (max packet) = 63нс
TX Data Link + Transaction Layer = 15нс
TX Data Link + Transaction Layer = 63нс
TX SerDes + PMA + PCS + MAC = 20нс
RX SerDes + PMA + PCS + MAC = 30нс
RX Data Link + Transaction Layer (min packet) = 15нс
RX Data Link + Transaction Layer (max packet) = 63нс
RX Root-complex Action = 15нс

в случае, если пришедший в root-complex read-запрос (прошло ~ 90-110нс) не попал в открытую страницу DRAM (а там 99,95% miss rate) то сразу после этого по стандарту PCIe он обязан отправить обратно completion со значением not ready (прошло ещё ~ 110нс), и примерно через 50-70нс открывается нужная страница в DRAM. после этого отправляется следующий completion уже с данными (считайте ещё ~ от 110 до 240нс)
это примерный минимум.

больше может получаться, если например, у вас multi-lane 4х или больше.
тогда в зависимости от физического разбега по длине между лейнами (а там может оказаться даже 8 дюймов) со стороны RX потребуется ещё дополнительное время на пересборку раскиданного пакета.

вот и считайте.

если же пакет по дороге побился, то происходит ещё и перезапрос на Data Link Layer, и вы можете получить не менее фантастические 2000+ нс

Сообщение отредактировал krux - Feb 5 2014, 19:09

[novartis]

возьмем примерные значения времянок:
Tx Application (min packet) = 15нс
Tx Application (max packet) = 63нс
TX Data Link + Transaction Layer = 15нс
TX Data Link + Transaction Layer = 63нс
TX SerDes + PMA + PCS + MAC = 20нс
RX SerDes + PMA + PCS + MAC = 30нс
RX Data Link + Transaction Layer (min packet) = 15нс
RX Data Link + Transaction Layer (max packet) = 63нс
RX Root-complex Action = 15нс

в случае, если пришедший в root-complex read-запрос (прошло ~ 90-110нс) не попал в открытую страницу DRAM (а там 99,95% miss rate) то сразу после этого по стандарту PCIe он обязан отправить обратно completion со значением not ready (прошло ещё ~ 110нс), и примерно через 50-70нс открывается нужная страница в DRAM. после этого отправляется следующий completion уже с данными (считайте ещё ~ от 110 до 240нс)
это примерный минимум.

больше может получаться, если например, у вас multi-lane 4х или больше.
тогда в зависимости от физического разбега по длине между лейнами (а там может оказаться даже 8 дюймов) со стороны RX потребуется ещё дополнительное время на пересборку раскиданного пакета.

вот и считайте.

если же пакет по дороге побился, то происходит ещё и перезапрос на Data Link Layer, и вы можете получить не менее фантастические 2000+ нс

Спасибо за ответ!
Но я ничего не понял. откуда эти цифры? где про это прочитать?

И у меня не root-complex. В плисине реализован Endpoint. Вновь пришедший read-запрос в моей пользовательской логике обрабатывается сразу же с детерменированной задержкой в несколько тактов. Пусть будет 5 тактов. Моя пользовательская логика тикает на частоте 125 МГц (8нс). Таким образом, с того момента как альтера выдаст мне пакет с запросом на чтение и до того момента, как я верну ей пакет с откликом на чтение, проходит 5*8=40нс. При работе с коркой от альтеры я оперирую Transaction Layer Packet. И вот мне бы хотелось понять (и потом пересказать своему начальнику), где потом набигают 700нс. Чего такого делает pcie корка или чего она ждет, чтобы начать возвращать пакет в линию. Data Link Layer такой медленный? И все ли дело на строне плис, может существенная задержка на стороне root-комплекса с обработкой пришедшего completion?