stm32f7+Lwip+lan8742, Тормоза при передачи Опции

[Kot_Schrodingera]

Всем доброго дня
Нуждаюсь в помощи с Lwip
В распоряжение железка stm32f745
Передаю картинку(размер 156к)
Прочитал все статьи которые есть на форуме, я даже получилась передача картинки за 30 мс
Во первых, как я понял из многих статей, увеличение скорости передачи достигается путем настройки TCP_WND, TCP_MSS, PBUF_POOL_BUFSIZE, PBUF_POOL_SIZE
Многие писали, что последние два параметра устанавливают порядка 100 и 16 соответственно, но это противоречит тому, что описано здесь http://lwip.wikia.com/wiki/Tuning_TCP
Могли бы вы объяснить почему так или дать путь, в котором нужно искать информацию
Во вторых, при передаче картинки бывают лаги, и вместо 30мс она передается за 1-3 с(использую API Netconn), время замерял следующим образом:

static uint32_t lt1, lt2, ltd;
lt1 = xTaskGetTickCount();
netconn_write(conn, buff_img, size_rx, NETCONN_NOCOPY);
lt2 = xTaskGetTickCount();
ltd = lt2-lt1;

То есть висит на этой функции
Не могу понять, это в драйвере ethernet проблемы или lwip так устроен?и почему тогда данная проблема происходит через раз

[sadat]

Ставим на комп wireshark, смотрим лог временных меток принятия пакетов. Думаем.
У меня картинка 768кб (bmp) по http заливается за 100-120 мс.
32f429, обработка ethernet в прерывании.

[scifi]

32f429, обработка ethernet в прерывании.

Прерывание или нет - не так важно. Важно настроить правильно размеры и число буферов, коих немало. Ну и не нарушать правила использования API.

[sadat]

Прерывание или нет - не так важно. Важно настроить правильно размеры и число буферов, коих немало. Ну и не нарушать правила использования API.

Опытным путём дошел, что обработка состояния ethernet оптимальна при опросе 2мс. Чаще - нет никакого выигрыша по скорости, реже - паузы между пакетами увеличиваются.
Ну и не забывать в настройках увеличивать реально выделенную память под буфера приёма и передачи.

[kolobok0]

Опытным путём дошел,...

под форточками, есть параметр для уровня TCP - задержка перед передачей. в lwip не помню - функция есть, реализация или заглушка - давно было дело.
Оно?

(круглый)

[Kot_Schrodingera]

wireshark не вариант, потому что обмен идет между железками и нужен хаб или настраиваемый свитч

правила использования API.

- можно об этом поподробнее?

Важно настроить правильно размеры и число буферов, коих немало.

не подскажите где об этом можно найти информацию?
Еще раз повторюсь, те настройки, которые предлагает lwip.wikia не удовлетворяют меня

[Kot_Schrodingera]

Нашел еще кое-что, когда виснет передача, основное время забирает передача ровно 2 пакетов (2920 байт). Время передачи 2 пакетов равно примерно 1-2 сек

[sadat]

Нашел еще кое-что, когда виснет передача, основное время забирает передача ровно 2 пакетов (2920 байт). Время передачи 2 пакетов равно примерно 1-2 сек

Без внешнего мониторинга будете долго ходить "вокруг да около". За это время вполне можно хаб достать и поставить программу.
Вот пример файла, вполне себе работоспособного. В своё время пробовал несколько разных из разных источников, остановился на этом.
 lwipopts.txt ( 7.73 килобайт ) Кол-во скачиваний: 202

[BioWolf2000]

В такой связке тоже были проблемы. Долго изучал пакеты Wireshark и видел непонятные паузы. Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB();

Код

      heth->TxDesc = (ETH_DMADescTypeDef *)(heth->TxDesc->Buffer2NextDescAddr);
    }
  }
  
//////////////////////
   __DSB();

/////////////////////
    
  /* When Tx Buffer unavailable flag is set: clear it and resume transmission */
  if (((heth->Instance)->DMASR & ETH_DMASR_TBUS) != (uint32_t)RESET)
  {
    /* Clear TBUS ETHERNET DMA flag */
    (heth->Instance)->DMASR = ETH_DMASR_TBUS;
    /* Resume DMA transmission*/
    (heth->Instance)->DMATPDR = 0;
  }

[scifi]

В такой связке тоже были проблемы. Долго изучал пакеты Wireshark и видел непонятные паузы. Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB();

Кстати, у меня давно сложилось ощущение, что то, как они портировали lwip на STM32, - это, скорее, некая демонстрация. Как небольшая демка вроде бы как-то работает. А если хотите сделать что-то серьёзное - используйте на свой страх и риск. Если взорвётся, сожгёт ваш дом, уронит на кого-то бетонную плиту - сами виноваты.

[Kot_Schrodingera]

Без внешнего мониторинга будете долго ходить "вокруг да около".

Поставил вторую сетевуху и сделал мост
Нашел эту большую паузу, оказалось вот что

Код

5288    69.077155    172.29.21.156    172.29.21.190    TCP    1514    [TCP Previous segment not captured] 20020 → 40392 [ACK] Seq=1814255 Ack=3988 Win=1865 Len=1460
5289    69.077975    172.29.21.190    172.29.21.156    TCP    60    [TCP Dup ACK 5286#1] 40392 → 20020 [ACK] Seq=3988 Ack=1812795 Win=65535 Len=0
5311    70.366679    172.29.21.156    172.29.21.190    TCP    1514    [TCP Retransmission] 20020 → 40392 [ACK] Seq=1812795 Ack=3988 Win=1865 Len=1460

то есть я правильно понял?что процесс retransmission занимает секунду?

[BioWolf2000]

Поставил вторую сетевуху и сделал мост
Нашел эту большую паузу, оказалось вот что

Код

5288    69.077155    172.29.21.156    172.29.21.190    TCP    1514    [TCP Previous segment not captured] 20020 → 40392 [ACK] Seq=1814255 Ack=3988 Win=1865 Len=1460
5289    69.077975    172.29.21.190    172.29.21.156    TCP    60    [TCP Dup ACK 5286#1] 40392 → 20020 [ACK] Seq=3988 Ack=1812795 Win=65535 Len=0
5311    70.366679    172.29.21.156    172.29.21.190    TCP    1514    [TCP Retransmission] 20020 → 40392 [ACK] Seq=1812795 Ack=3988 Win=1865 Len=1460

то есть я правильно понял?что процесс retransmission занимает секунду?

У меня без Data Synchronization Barrier тоже около секунды было. В STM32F7 серии из-за кэшей может неккоректно DMA работать.

И вообще, мне кажется, с выходом F7 серии ST бездумно перенесла код драйверов с 4-ой серии. Очень уж сырые библиотеки

[Kot_Schrodingera]

Проблема решилась правкой в файле stm32f7xx_hal_eth.c функции HAL_ETH_TransmitFrame добавлением строки __DSB();

Данная строка присутствует, но увы...не помогло

[sadat]

Почитать ERRATу на чип?
http://www.st.com/content/ccc/resource/tec....DM00145382.pdf
Полная уверенность в работоспособности второго устройства?

[Kot_Schrodingera]

Да, уверен

[sadat]

Да, уверен

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

[kolobok0]

..скорее, некая демонстрация....

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


(круглый)

[Kot_Schrodingera]

В таких случаях выкладывают часть кода для анализа - то,

Я думаю не имеет смысла выкладывать часть, которая относится к lwip, там я ничего не менял

CODE

void netconn_thread(void const *argument)
{
HAL_GPIO_WritePin(GPIOE, USB_PWR_GPIO_Pin, GPIO_PIN_SET);
HAL_Delay(10000);
struct netconn *conn, *newconn;


err_t err;
conn = netconn_new(NETCONN_TCP);

if(conn != NULL) {
err = netconn_bind(conn, NULL, 20020);

if(err == ERR_OK) {

netconn_listen(conn);

for(;;) {
err = netconn_accept(conn, &newconn);
connNoErr = true;

//netconn_set_recvtimeout(newconn, 50);
while((!ERR_IS_FATAL(netconn_err(newconn)))&(connNoErr)) {
recv_and_resp_netconn(newconn);
}

//if(err != ERR_OK)
//continue;

netconn_close(newconn);
netconn_delete(newconn);


}
} else {
debug("Can not bind netconn");
}
} else {
debug("Can not create netconn");
}

}
static void recv_and_resp_netconn(struct netconn *conn)
{
struct netbuf *inbuf;
err_t res;
char *buf;
u16_t buflen;
uint8_t type;
uint8_t buff_img[165000];

res = netconn_recv(conn, &inbuf);
if(res == ERR_OK) {

netbuf_data(inbuf, (void**)&buf, &buflen);

if(buflen >= sizeof(packet_tx_t)) {

uint8_t buffer[buflen];
memcpy(&buffer, buf, buflen);
search_object_t *packet = (search_object_t *)&buffer[1];

if(packet->header.cmd != PB_PVS_CMD_LED) {
pb_menu_process(buff_img, IMAGE_SIZE, buffer, buflen, packet->header.cmd);
}

packet_rx_t *packet_rx = (packet_rx_t *)&buff_img[1];

if(packet->header.cmd) {

if(packet->header.cmd == CMD_GET_SCAN) {
size_t size_rx;

if(packet_rx->status) {
size_rx = 20;
} else {
size_rx = IMAGE_SIZE + 14;
};
static uint32_t lt1, lt2, ltd, lt, ltpr;
//taskENTER_CRITICAL();
lt1 = xTaskGetTickCount();
netconn_write(conn, buff_img, size_rx, NETCONN_NOCOPY);
lt2 = xTaskGetTickCount();
ltd = lt2-lt1;
//taskEXIT_CRITICAL();
debug("qwerty\t%u", ltd);

} else {

netconn_write(conn, buff_img, 80, NETCONN_NOCOPY);
}
}
memset(buff_img, 0, 20);
}
} else {
debug("Error receiver : %d", res);
connNoErr = false;

}

netbuf_delete(inbuf);
}

И еще, раз возникает retransmission, то есть мой девайс не может дождаться ответа от хоста, может можно как-то увеличить это время?

Сообщение отредактировал IgorKossak - Dec 4 2017, 08:37

Причина редактирования: [codebox] для длинного кода. [code]-для короткого!!!

[scifi]

И еще, раз возникает retransmission, то есть мой девайс не может дождаться ответа от хоста, может можно как-то увеличить это время?

Просто теряется пакет. Либо при приёме, либо при передаче. Это баг. В нормально работающей системе ничто не теряется.

[Kot_Schrodingera]

Увеличил буффер TCP_SND_BUF
И получил следующее

Код

"1213","5.672845","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=712117 Ack=1693 Win=1498 Len=1460"
"1214","5.672951","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=713577 Ack=1693 Win=1498 Len=1460"
"1215","5.673065","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=715037 Ack=1693 Win=1498 Len=1460"
"1216","5.673137","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=710657 Win=65535 Len=0"
"1217","5.673416","172.29.21.156","172.29.21.190","TCP","1514","[TCP Previous segment not captured] 20020  >  56571 [ACK] Seq=717957 Ack=1693 Win=1498 Len=1460"
"1218","5.673745","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=713577 Win=65535 Len=0"
"1219","5.673750","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1220","5.674088","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=719417 Ack=1693 Win=1498 Len=1460"
"1221","5.674191","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=720877 Ack=1693 Win=1498 Len=1460"
"1222","5.674314","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=722337 Ack=1693 Win=1498 Len=1460"
"1223","5.674366","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#1] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1224","5.675012","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#2] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1225","5.675019","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#3] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1226","5.675024","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1219#4] 56571  >  20020 [ACK] Seq=1693 Ack=716497 Win=65535 Len=0"
"1227","5.675320","172.29.21.156","172.29.21.190","TCP","1514","[TCP Fast Retransmission] 20020  >  56571 [ACK] Seq=716497 Ack=1693 Win=1498 Len=1460"
"1228","5.676263","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=723797 Win=65535 Len=0"
"1229","5.676315","172.29.21.156","172.29.21.190","TCP","1514","[TCP Previous segment not captured] 20020  >  56571 [ACK] Seq=725257 Ack=1693 Win=1498 Len=1460"
"1230","5.676904","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1228#1] 56571  >  20020 [ACK] Seq=1693 Ack=723797 Win=65535 Len=0"
"1231","5.677312","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=726717 Ack=1693 Win=1498 Len=1460"
"1232","5.678181","172.29.21.190","172.29.21.156","TCP","60","[TCP Dup ACK 1228#2] 56571  >  20020 [ACK] Seq=1693 Ack=723797 Win=65535 Len=0"
"1244","7.145808","172.29.21.156","172.29.21.190","TCP","1514","[TCP Retransmission] 20020  >  56571 [ACK] Seq=723797 Ack=1693 Win=1498 Len=1460"
"1245","7.146624","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=728177 Win=65535 Len=0"
"1246","7.146985","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=728177 Ack=1693 Win=1498 Len=1460"
"1247","7.147109","172.29.21.156","172.29.21.190","TCP","1514","20020  >  56571 [ACK] Seq=729637 Ack=1693 Win=1498 Len=1460"
"1248","7.147869","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=729637 Win=65535 Len=0"
"1249","7.147884","172.29.21.190","172.29.21.156","TCP","60","56571  >  20020 [ACK] Seq=1693 Ack=731097 Win=65535 Len=0"

Я правильно понимаю, что проблемы не у меня?

[Grape]

а какая версия lwip?

[Kot_Schrodingera]

а какая версия lwip?

2.0.0

Сообщение отредактировал Kot_Schrodingera - Dec 4 2017, 10:44

[Grape]

2.0.0

я бы попробовал 2.0.3 и включил бы статистику.
У меня были похожие затыки, в результате нашлась ошибочка в lwip.

[Kot_Schrodingera]

я бы попробовал 2.0.3 и включил бы статистику.

Сейчас займусь этим, спасибо