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

[Oleg_IT]

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

[Oleg_IT]

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

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

[kolobok0]

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

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

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

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

[scifi]

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

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

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

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

 

[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", возможно найдете что-то полезное.

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

[kolobok0]

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

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

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

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

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

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

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

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

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

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

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