STM32F4+lwip медленно работает. Опции

[Oleg_IT]

Проект сгенерил в STM32Cube. Работает нормально. Возникла необходимо увеличить скорость передачи, данные 512 байт, очередную порцию передаю по приходу ответа с принимающей стороны. Скорость получается всего 4 Гц да ещё с периодическим замиранием секунды на две, три. Если игнорировать сообщение о получении данных и слать чаще, то возникает ошибка памяти и пакеты теряются. Как ускорить передачу?
Приемная сторона или 100 Мбит или 1Гбит (пробую на двух компах), ARM автоматом определяет 10 Мб, если при генерации проекта ставлю 100 Мбит картина не меняется.

[Сергей Борщ]

данные 512 байт, очередную порцию передаю по приходу ответа с принимающей стороны.

TCP? UDP? Если TCP - погуглите по ключевым словами "LwIP delayed ack" и "LwIP nagle algorithm", возможно найдете что-то полезное.

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

Может стоит выделить больше буферов?

ARM автоматом определяет 10 Мб, если при генерации проекта ставлю 100 Мбит картина не меняется.

Я не знаю, что там генерит куб, но если есть прерывание от PHY, то нужно в его обработчике читать из физики получившиеся параметры канала (реальную скорость и дуплекс/полудуплекс) и прописывать их в ETH->MACCR, а также вызывать netif_set_link_up()/netif_set_link_down(). Если прерывания физики нет - периодически читать физику и ловить состояние Auto Negotiation Complete и Link Down и по ним проделывать вышеописанные действия. Физика, разумеется, должна быть настроена на Auto Negotiation со всеми возможными для вашей реализации параметрами (10/100, Full/Halfduplex).

[Oleg_IT]

Да, не уточнил у меня TCP.

По буферам посмотрю, но со временем и они забьются.

Auto Negotiation возвращает 10 Мбит.

[kolobok0]

[quote name='Oleg_IT' date='Oct 31 2016, 11:44' post='1458636']
...у меня TCP.[quote]

из моего города - отсюда не видно что у там в 25 строчке кода, посему для начала приведите свой кусок кода на приёме.
ну и встречный вопрос -
Вы в курсе чем отличается протокол TCP от UDP?

боюсь именно тут собака порылась..

(круглый)

[Oleg_IT]

Чем TCP от UDP отличается я знаю, это так к сведению Для уточнений можно, например сюда обратится https://electronix.ru/forum/index.php?showtopic=115578 , там и на стандарты ссылки есть.
На приемной стороне, т.е. на РС стоит Qt-шная программа с кодом приёма передачи из её, Qt родного примера, обработка полученного массива данных и генерация передаваемых данных естественно свои, с начало передача ответа, потом обработка.

[Sanya_kv]

Проект сгенерил в STM32Cube. Работает нормально. Возникла необходимо увеличить скорость передачи, данные 512 байт, очередную порцию передаю по приходу ответа с принимающей стороны. Скорость получается всего 4 Гц да ещё с периодическим замиранием секунды на две, три. Если игнорировать сообщение о получении данных и слать чаще, то возникает ошибка памяти и пакеты теряются. Как ускорить передачу?
Приемная сторона или 100 Мбит или 1Гбит (пробую на двух компах), ARM автоматом определяет 10 Мб, если при генерации проекта ставлю 100 Мбит картина не меняется.

Возможно проблема в задержке (200 млСек) получения подтверждения. Проблему задержки можно решить 2-я способами:
1) Нужно отправлять по 2 пакета.
2) Правка реестра https://support.microsoft.com/ru-ru/kb/321098

Более подробно о проблеме здесь: https://support.microsoft.com/ru-ru/kb/214397

[kolobok0]

Чем TCP от UDP отличается я знаю, это так к сведению ...

меня насторожило Ваше это высказывание:

...данные 512 байт, очередную порцию передаю ...

TCP поток. посему меня и заинтересовало как Вы квантуете 512 байт...
для более предметного разговора - нужен код вашего приёмника.

удачи вам
(круглый)
ЗЫ
По указанной Вами ссылке нет Вашего кода приёмника...

Сообщение отредактировал kolobok0 - Nov 5 2016, 07:47

[Oleg_IT]

По моей ссылки кода нет, там теория TCP для новичков.
Проект на PC достаточно большой, приёмная часть это класс QTcpSocket и его окружение из примера. Обработка пока вообще ни какая, просто беру и вывожу номер пакета, а пвкет это те самые 512 байт.

По поводу двух пакетов, заметил, что lwip собирает два павкета, не всегда, но часто и передаёт их в двух пакетах, но с другими длиними, 588 и 436 байт. Увеличивал и уменьшал объём передаваемых данных в два раза, результат тотже.

[sadat]

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

[kolobok0]

....Обработка пока вообще ни какая, просто беру и вывожу номер пакета, а пвкет это те самые 512 байт....

ну тогда давайте от печки...

в TCP нет пакетов(!!!!) прочувствуйте фразу = от слова СОВСЕМ НЕТ!

(круглый)
ЗЫ
Практика приёма на работу программистов показывает, что мало кто действительно понимает эту фразу

[scifi]

в TCP нет пакетов(!!!!) прочувствуйте фразу = от слова СОВСЕМ НЕТ!

Не надо изображать из себя злого преподавателя на экзамене. Сегменты ведь есть? И вообще, лучше по делу. Хотя бы просто "RTFM" и ссылка на материал.

[Сергей Борщ]

И вообще, лучше по делу. Хотя бы просто "RTFM"

Не помогает...

погуглите по ключевым словами "LwIP delayed ack" и "LwIP nagle algorithm"

[Oleg_IT]

Wireshark показывает Test1.JPG из приложения. IP …18 это модуль на ARM, …150 это PC с Windows XP.
Получается, что тормоза идут от модуля. И откуда такие залипания, на 4 секунды, строки 36-37? Как в модуле проверить, что данные ушли в контроллёр изернет?
Реестр поменял по рекомендации Sanya_kv Реестр.JPG из приложения. Результата не видно.

Фрагмент кода приёмника

Код

void MainWindow::slotReadyRead()
{
    if (m_pTcpSocket == NULL || m_pTcpSocket->isOpen() == false)
        return;

    slotSendToServer();

    QByteArray dAll;
    dAll.clear();
    dAll = m_pTcpSocket->readAll();
    SizeAll = dAll.count();
    if (AddData(dAll.data(),SizeAll,(uint8_t*)m_Data.Data) == true)
        WidgetMain->DrawGr();
}

void MainWindow::slotSendToServer()
{
    if (m_pTcpSocket == NULL || m_pTcpSocket->isOpen() == false)
        return;
    GetControlToModul(m_ControlToModul);
    m_pTcpSocket->write((const char*)&m_ControlToModul,sizeof(ControlToModul));
}

GetControlToModul(…) заполняет передаваемую структуру.
AddData(...) обработка принятых данных, сейчас только извлечения номера посылки, который приходит из модуля.

Эскизы прикрепленных изображений

 

[scifi]

Как в модуле проверить, что данные ушли в контроллёр изернет?

Если данные для отправки идут маленькими кусочками, lwip старается отложить отправку, пока не наберётся сегмент, приближающийся по размеру к MSS. Это чтобы не было кучи мелких сегментов. Если считаете, что вам виднее, можете просто вызывать tcp_output(), тогда всё, что накопилось к этому моменту, будет отправлено немедленно.

[Oleg_IT]

Если данные для отправки идут маленькими кусочками, lwip старается отложить отправку, пока не наберётся сегмент, приближающийся по размеру к MSS. Это чтобы не было кучи мелких сегментов. Если считаете, что вам виднее, можете просто вызывать tcp_output(), тогда всё, что накопилось к этому моменту, будет отправлено немедленно.

Еслиб это было так, lwip, у меня, ни чего не копит, в начале я говорил, что если посылать чаще, то пакеты теряются, подпрограмма tcp_write выдаёт ошибку памяти.

[scifi]

Еслиб это было так, lwip, у меня, ни чего не копит

Интересно, на основании чего вы сделали этот вывод.

если посылать чаще, то пакеты теряются, подпрограмма tcp_write выдаёт ошибку памяти.

Если посылать 100500 раз в секунду, точно будут ошибки - буферы не резиновые.

Короче, что там у вас в коде творится - только вам ведомо. Кода мы не видели. Телепаты в отпуске

очередную порцию передаю по приходу ответа с принимающей стороны

А вот это зачем? Есть же у TCP механизм подтверждений, никакие "ответы" не требуются.

[kolobok0]

...
Фрагмент кода приёмника

Код

void MainWindow::slotReadyRead()
{
    if (m_pTcpSocket == NULL || m_pTcpSocket->isOpen() == false)
        return;

    slotSendToServer();

    QByteArray dAll;
    dAll.clear();
    dAll = m_pTcpSocket->readAll();
    SizeAll = dAll.count();
    if (AddData(dAll.data(),SizeAll,(uint8_t*)m_Data.Data) == true)
        WidgetMain->DrawGr();
}

...

Подкорректируйте меня если я обшибаюсь...
Вы очищаете массив(закос под кути или порт кутишный).
Считываете всё что пришло в ку-байт-эррэй.
получаете кол-во принятых байт.
и далее передаёте на обработку....


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

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

Обратите внимание на реализацию приёмников в грамотных кодах серваков - там кол-во байт которое необходимо принять передаётся в подпрограмму приёма. И подпрограмма действует по
принципу либо всё либо ошибка.
Длины данных обычно передают в хедере фиксированной длины. т.е.
Ваш приёмник (как один из вариантов) должен быть реализован как приём фиксированной длины хедера, далее взятие из этого хедера длины данных, подготовка приёмного буффера,
и собственно приём данных пришедшей из хидера.

удачи вам
(круглый)

ЗЫ
Есть ещё настройки TCP уровня по задержке перед передачей, но там задержки(по дефолту - не более нескольких мс). Т.е. если у Вас глюкало на секунды-минуты - это явно хромает консерватория...

ЗЫ ЗЫ
Ваш код приёмника (я сначала подумал что под армом пишете, но от этого рояль не меняется) может быть типа такого

Код

void CTcpClient::_slotAnswera()
{
    if (m_baHeader.size() == 0)
    {
        if (m_pTcpSocket->bytesAvailable() < sizeof(HRBusinessLogic::Tools::SDataHeader))
            return;
        //
        m_baHeader = m_pTcpSocket->read(sizeof(HRBusinessLogic::Tools::SDataHeader));
    }
    //
    const HRBusinessLogic::Tools::SDataHeader* pReceiveData = reinterpret_cast<const HRBusinessLogic::Tools::SDataHeader*>(m_baHeader.constData());
    //
    if (m_pTcpSocket->bytesAvailable() < pReceiveData->m_unSize)
        return;
    //
    QByteArray data = m_pTcpSocket->read(pReceiveData->m_unSize);
    data.push_front(m_baHeader);
    m_baHeader.clear();
    emit eventProcessingData(data);
}

Сообщение отредактировал kolobok0 - Nov 8 2016, 19:50

[Oleg_IT]

Буфер конечно не резиновый, но и о скорости 100500 я не говорю, первый же вызов tcp_write не дождавшись ответа, вызывает ошибку памяти и этот посланный пакет теряется. Из этого и сделал вывод, что «lwip, у меня, ни чего не копит» и на приёмной стороне номеров этих пакетов не получаю.

По Qt.

Вы очищаете массив(закос под кути или порт кутишный).
Считываете всё что пришло в ку-байт-эррэй.
получаете кол-во принятых байт.
и далее передаёте на обработку....

Можно и не очищать. Да всё так. В обработчике AddData у меня стоит сборщик кусков, в пакете синхронизатор включён, а сам пакет постоянной длины, сделал этот код сам, проверено, работает. Пришлось сделать этот код, кода начал получать два пакета одинаковой длины в двух пакетах разной длины, я это уже отмечал.
Сделал на PC имитатор стороны ARM, скорости держит несколько килогерц, специально вводил разбиение пакетов, связка работает стабильно.

погуглите по ключевым словами "LwIP delayed ack" и "LwIP nagle algorithm", возможно найдете что-то полезное.

Смотрел, информации по этим темам не много, пока чего-то туплю

[HardEgor]

Буфер конечно не резиновый, но и о скорости 100500 я не говорю, первый же вызов tcp_write не дождавшись ответа, вызывает ошибку памяти и этот посланный пакет теряется. Из этого и сделал вывод, что «lwip, у меня, ни чего не копит» и на приёмной стороне номеров этих пакетов не получаю.

Копит-копит, куда же он денется, после tcp_output он должен дождаться подтверждения от принимающей стороны и только тогда очистит свой буфер. А если не получит, то попытается еще раз отправить, потому что TCP гарантирует доставку.
Например у меня прибор в режиме ожидания вообще 2 байта посылает в каждом пакете раз в секунду, и я отлично вижу эти пакеты по 2 байта.

[Oleg_IT]

Я свои байты вижу четыре раза в секунду.

Может и копит, этот момент я пока не понимаю. Не понимаю тогда куда мне девать ошибку памяти? Если я два раза подряд отправляю пакеты, то второй раз выдаёт ошибку памяти. Не пойму пока куда смотреть чего проверять. Размерв буферов максимальные из рекомендации поставил.

[scifi]

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

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

Размерв буферов максимальные из рекомендации поставил.

Там в настройках побольше степеней свободы, чем просто "размеры буферов максимальные". Буферы бывают разные, у них есть размер и кол-во. Также есть куча. Короче, без поллитры не разберёшься. Включайте статистику.

[HardEgor]

Может и копит, этот момент я пока не понимаю. Не понимаю тогда куда мне девать ошибку памяти? Если я два раза подряд отправляю пакеты, то второй раз выдаёт ошибку памяти. Не пойму пока куда смотреть чего проверять. Размерв буферов максимальные из рекомендации поставил.

Выкладывайте свой код и настройки LwIP. Так бесполезно объяснять что у вас не работает.

[kolobok0]

..В обработчике AddData у меня стоит сборщик кусков,...Пришлось сделать этот код, кода начал получать...

если Вы уверены в сборке - это конечно же хорошо.
то что Вы дублируете два-раза-два-раза кэшширование и сборку полезных данных - ну значит Вам так проще осязать.

осталось обратиться к барабашке

постарайтесь выкинуть всю обработку на приёме и сделать тупую отправку в сеть. если есть сетевой анализатор - то по любому адресу кроме 127.0.0.1

после этого посмотрите скорость и задержки. если их нет = проблемы в консерватории.

ведь судя по трафику арм выдаёт запрос штатно, писюк выдаёт тайм-аут. собственно два вектора
1) почему писюк завис(не выдал подтверждения)
2) почему арм не пытается пропихнуть далее ситуацию(ретрансмит)

обратите внимание на временной лаг ответа со стороны писюка и со стороны арма.
со стороны арма - около 250 мс (что собственно слишком медленно, но не смертельно)
со стороны писюка в 1000 раз быстрее. т.е. на писюке имеем запас по скорострельности более чем в 1000 раз.

посему зависон со стороны арма(нет ретрансмишена) - это фигня по сравнению с зависоном со стороны писюка (он уже мог сотню раз принять решение). значит не может.

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

удачи вам
(круглый)

Сообщение отредактировал kolobok0 - Nov 9 2016, 19:03

[arhiv6]

Не надо делать так:

Код

slotSendToServer();

QByteArray dAll;
dAll.clear();
dAll = m_pTcpSocket->readAll();

Необходимо дождаться данных, прежде чем читать:

Код

slotSendToServer();

if (!m_pTcpSocket->waitForReadyRead())
{
    qDebug() << "Не дождались ответа";
    return;
}

QByteArray dAll = m_pTcpSocket->readAll();

[Oleg_IT]

Слот slotReadyRead() срабатывает только тогда, когда данные уже готовы, так что ждать тут не чего.

kolobok0 спасибо, учту Ваши рекомендации

Сообщение отредактировал IgorKossak - Nov 10 2016, 11:23

Причина редактирования: бездумное цитирование

[arhiv6]

Но Вы запись в сокет делаете из этой же функции, когда вызываете функцию slotSendToServer(). И после этого сразу же читаете из сокета данные, не проверяя их готовность. Вот если бы запись проходила в другом месте - вопросов не возникло бы. А так - данные могут теряться.

[Oleg_IT]

Но Вы запись в сокет делаете из этой же функции, когда вызываете функцию slotSendToServer(). И после этого сразу же читаете из сокета данные, не проверяя их готовность. Вот если бы запись проходила в другом месте - вопросов не возникло бы. А так - данные могут теряться.

Там же буфера разные на чтение и запись, у меня ни чего не теряется.

Всё лишнее с обеих сторон повыкидывал, остался только номер пакета. Кстати, сейчас передаю по 1024 байта, один пакет передал, один пакет принял, так что в сборщике пакетов потребности сейчас нет. Ситуация та же.

[Oleg_IT]

Пытаюсь вывести дубужную информацию, подключил терминал, включил LWIP_DEBUG, лог идёт, в приложение включил, а ARP запроса нет. Раньше как то такое было, но я так и не понял как победил, сейчас победить не получается, совместно изернет и дебаг не работает.

Прикрепленные файлы

 Log.txt ( 1015 байт ) Кол-во скачиваний: 15

 

[Oleg_IT]

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

Код

tcp_nagle_disable(pcb);
tcp_write(pcb, Ptr, Size, 0);
tcp_output(pcb);

Спасибо "Сергей Борщ" и "scifi".