[Ar-han 0]

Учусь укладывать видео-поток в 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

И требует паузы между пакетами.

 

Что почитать?

Куда двигаться дальше?

Спасибо.

[Golikov 0]

подсчет контрольной суммы железный или софт? В лайт он точно софт, в вашем емаке включили железный?

Сам стэк LwIP здорово тормозит процесс...

Если надо только UDP, есть железные модули которые на вход данные, на выход UDP пакеты. Без стэка, и прочей муры, вот они дадут вам максимум производительности.

[ZASADA 0]

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

[Corvus 1]

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

Попробуйте готовый пример XAPP1026. Вроде, он должен быть под ML507.

Меня смущает LocalLink. Насколько я помню, он довольно медленный.

[Ar-han 0]

Да нечего в 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 чем еще можно поэкспериментировать?

Изменено 11 января, 2015 пользователем Ar-han

[Golikov 0]

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

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

 

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

 

 

[Ar-han 0]

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

 

Так и есть, сейчас UDP пакет заполняю данными из DDR, использую DDR как буфер.

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

 

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

transfer_utxperf_data()
{
    ...
    
    for (zz = 0; zz < N_packets; zz++) // читаю кадр из DDR
    {
        memcpy(pbuf_to_be_sent->payload, pData_DDR + (zz*1040),1040);

        err = udp_send(pcb, pbuf_to_be_sent);

    }
}

 

То сниффер показывает скорость 350 Mbit в сек.

(Без ожидания прерывания и копирования кадра из BRAM в DDR)

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

 

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

main.c
...
    while (1) 
    {
        if (is_ext_interrupt == 1) // Флаг внешнего прерывания
        {
            is_ext_interrupt = 0;

                memcpy(pData_DDR, pData_1, frame_size);

                    xemacif_input(netif);    // без неё нет отправки
                    transfer_utxperf_data(); // отправка UDP пакета
        }
    }

Пример отправки UDP пакетов взял из echo - сервера.

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

Без неё пакеты не отправляются.

[Koluchiy 0]

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

[Golikov 0]

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

 

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

 

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

[Ar-han 0]

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

 

 

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

 

void timer_callback()
{
    /* we need to call tcp_fasttmr & tcp_slowtmr at intervals specified by lwIP.
     * It is not important that the timing is absoluetly accurate.
     */
    static int odd = 1;
    tcp_fasttmr();

    odd = !odd;
    if (odd)
        tcp_slowtmr();

}

 

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

 

Значит выкидывать xemacif_input(netif); не стоит, упрощать на первый взгляд нечего?

Хотел выкинуть чтение порта, хотя может это и пригодиться в дальнейшем.

Еще у меня порт выбран 1024, может стоит более высокий номер взять, этот может быть занят чем-то.

Ввел нумерацию строк и кадров в пакеты, наблюдаю потерю части строк со стороны PC.

Спасибо.

[Golikov 0]

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

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

 

а вот эти функции

tcp_fasttmr();

tcp_slowtmr();

 

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

 

 

Ввел нумерацию строк и кадров в пакеты, наблюдаю потерю части строк со стороны PC.

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

 

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

[Ar-han 0]

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

 

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

Могу ошибаться, но вроде бы, вначале плата спрашивает мак PC с указанным IP и начинает пулять туда пакеты. Завтра проверю.

 

tcp_fasttmr();

tcp_slowtmr();

 

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

 

Функции дергаются по колбеку таймера.

Интервал таймера 250 ms и 500 ms, насколько я понимаю.

 

 

#define MHZ 400

#define PIT_INTERVAL (250*MHZ*1000)

 

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

 

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

 

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

 

Я пробую через Winsock, с блокирующими функциями чтения, в MFC. При создании отдельного потока для чтения сокета в статический массив,

а по выходу сохранение массива в файл, статистика потерь пакетов порядка 0.1%, если во втором отдельном потоке делать распаковку данных, АРУ, сохранение кадра в BMP формате на диск, чтение этого файла и вывод на экран, потери увеличиваются.

Реально, около 30 % кадров выкидываю из-за полученного неполного количества строк (частота 26 кадров в сек)

 

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

 

 

[Golikov 0]

Кажется, я никакого обмена не видел между UDP пакетами.

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

 

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

 

Функции дергаются по колбеку таймера.

Интервал таймера 250 ms и 500 ms, насколько я понимаю.

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

В шарке какое время между пакетами?

 

 

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

Коль у вас нагрузка на винду увеличивает потери, получается это она уже не прожевывает трафик, чудно... при современных то технологиях...

 

 

 

 

[Corvus 1]

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

[Ar-han 0]

Не надо перепиливать код и тем более менять частоту работы системных таймеров. Начните с настройки 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);

 

 

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