Учусь укладывать видео-поток в UDP пакеты.

Отправка пакетов:
Железо Virtex-5, ML507
Процессор PowerPC 333 Мгц
Temac, GMII + LocalLink FIFO (4096 byte)
LWIP библиотеки.
Модифицированное приложение echo-сервера.
Длина пакета 1082 байта
cache D/I Enable

ld-script:
stack size: 0xA000
heap: 0xA000
все секции памяти в DDR


Приём:
На PC - windows.
на 100 Mbit канале и на 1000 Mbit, скорость почти не меняется 75-80 Mbit/sec

Пока что пролезает 18 кадров в сек, 640х480х12bit
Можно ли вытянуть больше скорость?


P.S.
Emac-lite даёт не более 54 Mbit/sec
И требует паузы между пакетами.

Что почитать?
Куда двигаться дальше?
Спасибо.

подсчет контрольной суммы железный или софт? В лайт он точно софт, в вашем емаке включили железный?
Сам стэк LwIP здорово тормозит процесс...
Если надо только UDP, есть железные модули которые на вход данные, на выход UDP пакеты. Без стэка, и прочей муры, вот они дадут вам максимум производительности.

проблема врядли в ядре Temac. делал на нем преобразователь интерфейсов, канал 1 гбит/с забивался под завязку. копать надо в сторону формирования/обработки пакетов.

Да нечего в TEMAC гнать. По своему опыту, на Spartan-6 (Microblaze 100 MHz, AXI, LwIP) без особых ухищрений UDP в iperf получается скорость близкая к физическому пределу. На гигабите больше 900 МБит/с. На Virtex должно быть ещё быстрее.
Попробуйте готовый пример XAPP1026. Вроде, он должен быть под ML507.
Меня смущает LocalLink. Насколько я помню, он довольно медленный.

Получилось!
Вместо Fifo для Temaca подключил DMA, частоту проца поднял до 400 Mhz, а частоту шины до 100Mhz. (было 333/83)

Скорость 30000 пак в сек (длина пакета с заголовком 1082 байта), примерно 250 Mbit/sec

Enable TxCheckSum offload for Temac - галку поставил, он на той же частоте она скорости не прибавила, как и увеличение
Fifo Depth 16kB вместо 4kB

В XAPP 1041 подсмотрел, что частоту шины поднимают до 133 Mhz на этом же ките (ML507) при частоте процессора 400,
но в XPS, BSB помощник не предлагает такого варианта. Стоит ли попробовать?

Настраивается ли как-то LWIP ?
Увидел, что если в SDK -> Board Support Package setting выделить LWIP, то появятся куча настроек.
Control various settings of your Board Support Package.
Сейчас всё по умолчанию, включая RAW_API

C чем еще можно поэкспериментировать?

Сообщение отредактировал Ar-han - Jan 11 2015, 14:02

там много чего настраивается, и длина очередей, и размеры буферов и количество и так далее... но это все больше для полноценного обмена с несколькими сокетами и так далее...
Странно что контрольная сумма железная не подняла скорость, у меня она существенно тормозила обмен при софтварном обсчете. Где-то у вас еще что-то застревает...

Вообще изначально LwIP у ксалинкса с большим числом перекопирований сделан, при работе с ДДР - это тоже здорово тормозить обмен, так как его буферы обычно в нем и лежат... Попробуйте кеши процу увеличить и добавить кеш обращений в кеш.

Так и есть, сейчас UDP пакет заполняю данными из DDR, использую DDR как буфер.
У меня двупортовая BRAM - 512KByte, со стороны железа в один порт закидываю кадр, когда она полна, дергаю за ногу внешнего прерывания процессор. А через второй порт в процессоре, по флагу прерывания копирую кадр из BRAM, в DDR, с помощью memcpy(), а из DDR, по строкам передаю UDP пакетами.

Если просто в бесконечном цикле, один и тот же кадр отсылаю из DRR


То сниффер показывает скорость 350 Mbit в сек.
(Без ожидания прерывания и копирования кадра из BRAM в DDR)
Если в бесконечном цикле, без ожидания прерывания, но с копированием кадра 648*486 из BRAM в DDR, то скорость 250 Mbit в сек.

Копирование делаю, чтобы исключить одновременное чтение и запись в BRAM со стороны железа и процессора.

Пример отправки UDP пакетов взял из echo - сервера.
Не могу понять необходимость вызова функции чтения входного порта перед отправкой UDP пакета: xemacif_input(netif);
Без неё пакеты не отправляются.

Игрался как-то с ускорением TCP на NIOS. На первом же взгляде в код выяснилось, что больше всего затрат на передачу гигабайтов из буфера 1 в буфер 2, а потом из буфера 2 в буфер 3 :-).

Есть мнение что без вызова этой функции у вас стэк не прокручивается...

вы не забываете периодически дергать быстрые и медленные функции работы стэка? Так эта функция прием олапачивает и вызывает калбеки, косвенно ваш калбек может стек прокручивать, потому и такая фигня?...

Также эта функция обрабатывает входящие запросы и ответы, вроде ARP и прочее, без которых может так оказаться обмена не будет...

Вы имеете ввиду эти функции?



Не забываю, дергаю.

Значит выкидывать xemacif_input(netif); не стоит, упрощать на первый взгляд нечего?
Хотел выкинуть чтение порта, хотя может это и пригодиться в дальнейшем.
Еще у меня порт выбран 1024, может стоит более высокий номер взять, этот может быть занят чем-то.
Ввел нумерацию строк и кадров в пакеты, наблюдаю потерю части строк со стороны PC.
Спасибо.

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

а вот эти функции
tcp_fasttmr();
tcp_slowtmr();

как часто вы дергаете? Чем чаще вы их будите дергать, тем оперативнее будет прокручиваться стэк.



счастливчик, у меня чего-то на проводе и соединении компьютер - ПЛИС так и не получилось пакеты потерять. Я думаю где то ваш стэк наедается, то есть внутри каких-то буферов не хватает, вот он и решает какие-то строки выкинуть по ходу пьесы...

Попробуйте функции почаще подергать для начала...

Кажется, я никакого обмена не видел между UDP пакетами. Пробовал эту функцию вызывать единожды в начале, не проходят.
Могу ошибаться, но вроде бы, вначале плата спрашивает мак PC с указанным IP и начинает пулять туда пакеты. Завтра проверю.



Функции дергаются по колбеку таймера.
Интервал таймера 250 ms и 500 ms, насколько я понимаю.


#define MHZ 400
#define PIT_INTERVAL (250*MHZ*1000)

Завтра попробую их уменьшить.



А как у вас со стороны компьютера организован приём, под какой операционкой?

Я пробую через Winsock, с блокирующими функциями чтения, в MFC. При создании отдельного потока для чтения сокета в статический массив,
а по выходу сохранение массива в файл, статистика потерь пакетов порядка 0.1%, если во втором отдельном потоке делать распаковку данных, АРУ, сохранение кадра в BMP формате на диск, чтение этого файла и вывод на экран, потери увеличиваются.
Реально, около 30 % кадров выкидываю из-за полученного неполного количества строк (частота 26 кадров в сек)

Не могу понять в чём дело.

почему только UDP? эта функция обрабатывает весь обмен по всем пакетам, ARP, PING, DHCP и бла бла бла... кажется...

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


ну да, так ксалинкс рекомендует изначально, но это виляет на скорость прокручивания стека, как минимум быстрый таймер сильно чаще дергайте, пакеты начнут ходить чаще. Сейчас как я понимаю они в буферах накапливаются а потом одним куском идут...
В шарке какое время между пакетами?


Со стороны компутера у меня был C# на винде. Но обмен у меня не такой плотный и односторонний, там были тесты памяти фактически. То есть я память заливал каким-то массивом через езернет, потом читал обратно. При этом потери пакетов я не отслеживал, но вроде тесты сходились... Правда пакеты были небольшие сильно меньше килобайта.
Коль у вас нагрузка на винду увеличивает потери, получается это она уже не прожевывает трафик, чудно... при современных то технологиях...

Не надо перепиливать код и тем более менять частоту работы системных таймеров. Начните с настройки LwIP. Число дескрипторов temac до 256, оффлоад чексумм. pbuf_pool_bufsize хотя бы до 1024, memp_n_buf до 1024. Хотя бы так для начала. Будет ли прирост?

Начал слать пакеты на другой компьютер с сетевухой интегрированной в материнскую плату, при тех же параметрах ошибок в 15 раз меньше.


Статистика:
Num_ALL_line= 258304
Num_Ok_line= 258286
Num_ERR_line= 18
Lines_all/err_relations= 0.0070

num_all_frames= 531
num_ok_frames= 513
num_err_frames= 18
frames__all/err_relation= 3.3898


Ошибки:
1 число - номер кадра, второе число - разница в номерах принятых строк отличная от 1 и от числа строк в кадре (486 - 1).


37251 79
37265 2
37282 3
37295 3
37316 3
37343 -457
37374 -446
37407 3
37471 3
37480 2
37512 2
37513 5
37519 3
37559 79
37670 3
37688 2
37697 2
37706 2


Максимальной скорости отправки не прибавилось.
Заменил кабель на более короткий и 6-ой категории, не помогло.

Число дескрипторов n_tx_descriptors - 256 вместо 64 не заметил разницы.
tcp_tx_checksum - offload - почему-то никаких изменений в максимальной скорости не заметно.
tcp_tx_ip_tx_checksum - offload => куча ошибок при компиляции, пока не разбирался с ними (перестал находить какие-то файлы)
memp_n_buf - 1024 вместо 16 => не заметил изменений.
pbuf_pool_bufsize - у меня 1700 стоит.

С выделением памяти еще не совсем разобрался, сейчас выделяю тут и так:
pbuf_to_be_sent = pbuf_alloc( PBUF_RAW, 1048, PBUF_RAM);


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