LWIP TCP RAW API server

@DmitryDDDD · Регистрация: 12.11.2018

Author24 — интернет-сервис помощи студентам

Решил настроить на stm32f746 discovery LWIP TCP RAW сервер, но никак не могу это реализовать. Есть настроенный TCP netconn на FreeRTOS, но хочу сделать без ОС, посмотреть как будет работать в отличае от netconn. Может у кого-нибудь есть пример или код LWIP RAW? Буду благодарен, не могу никак запустить из документации, куча ошибок.
Еще есть такой вопрос: как можно получить скорость передачи десятки Мбит/сек на stm32? Мой TCP сервер выдает 3-4 Мбит, HTTP на его базе вроде гораздо шустрее передает, но нужен именно TCP. UDP не пробовал, но судя по тому, что там возможна потеря данных, такой вариант не подходит.
Плата stm32f746 discovery, PHY - LAN8742a, Использую CubeMX и HAL. На CMSIS уже задумываюсь попробовать, если будут подходящие примеры, но это видимо очень не просто

@shepard127 · 10.12.2020, 14:14

Сообщение от DmitryDDDD

На CMSIS уже задумываюсь попробовать

Могу посоветовать для начала собрать и запустить готовый пример с CubeMX + HAL + FreeRTOS, затем попробовать откинуть FreeRTOS. Ну а когда и без FreeRTOS у вас будет всё работать - тогда на CMSIS писать, думаю к тому времени у вас уже опыта будет достаточно, чтоб во всём разобраться.

Сообщение от DmitryDDDD

Еще есть такой вопрос: как можно получить скорость передачи десятки Мбит/сек на stm32?

На STM32 или на любом другом микроконтроллере, компютере, телефоне... Скорость определяется одинаково, нужно взять определнный объем информации и начать передавать. К примеру если у вас файл размером 50 Мбайт, передался за 16 секунд. То вы делаете следующее:
50 / 16 = 3,1875 (узнаете сколько было передано МБ за 1 секунду), затем:
3,1875 * 8 = 22,5 Mbit/s (узнаете какая скорость необходима, для того чтоб передать этот объем информации за 1 сек.)

В данном случае: 22,5 Mbit/s. Это ваша скорость

@DmitryDDDD · 10.12.2020, 15:32 **[ТС]**

shepard127,

Сообщение от shepard127

Могу посоветовать для начала собрать и запустить готовый пример с CubeMX + HAL + FreeRTOS, затем попробовать откинуть FreeRTOS. Ну а когда и без FreeRTOS у вас будет всё работать - тогда на CMSIS писать, думаю к тому времени у вас уже опыта будет достаточно, чтоб во всём разобраться.

На FreeRTOS у меня код есть, он уже отлажен, правда скорость передачи данных не высокая. Там я использовал LWIP netconn.
Сейчас хотел переделать на LWIP RAW. Там уже другой подход и другие функции, пока не разобрался.

Сообщение от shepard127

Скорость определяется одинаково, нужно взять определенный объем информации

У меня просто тестовый массив отправляется множество раз:

C

                HAL_TIM_OC_Start_IT(&htim4, TIM_CHANNEL_4);
                for (i = 0; i < 12800; i++)
                {
                    netconn_write(conn, TcpSendBuffer, sizeof(TcpSendBuffer), NETCONN_NOCOPY);
                }
                HAL_TIM_OC_Stop_IT(&htim4, TIM_CHANNEL_4);

Там массив в 1кБайт данных отправляется 12800 раз, итого получаю 100 МБит передающихся данных (не учитываю служебную информацию, не максимальный размер пакета и тд), я получаю , что весь этот поток передается за примерно 25 секунд. Т.е. 3-4 Мбит/сек.
Основная задача увеличить скорость передачи. С ОС или без ОС, особо не имеет значения, главное получить нормально работающий ethernet.
Сейчас наткнулся на ряд тем на форуме st com. Там, насколько я понял, два человека "перелопатили" LWIP, библиотеки HAL и т.д., учли ошибки ST и получили неплохой TCP стек.
https://community.st.com/s/que... g-on-stm32
Но применить их знания и оптимизировать код так, чтобы получить больше 90 Мбит/сек (по их данным), я пока не достаточно разбираюсь

@Voland_ · 12.12.2020, 14:17

Сообщение от DmitryDDDD

Но применить их знания и оптимизировать код так, чтобы получить больше 90 Мбит/сек (по их данным)

[аналогично наталкивался на это обсуждение, просто подпишусь, чтобы отслеживать Ваши успехи].

Не думаю, что non-RTOS решение будет существенно быстрее (если оно самодельное). Воспользуйтесь wireshark, чтобы отследить как именно стек бьет ваши пакеты по 1к при отправке (кстати, зачем вы бьете данные?). Так же можно много чего диагностировать.И да netconn концептуально написан хоть и с прицелом на оптимальность, но мог бы быть гораздо лучше организован. Не далее как вчера изучал подробности реализации WEB-сервера [lwIP] на его базе.

@DmitryDDDD · 13.12.2020, 07:36 **[ТС]**

Voland_, Сейчас Ваше сообщение натолкнуло на мысль: а есть разница отправлять например 100 МБит одной командой, ну и там уже TCP сам отошлет по пакетам, или же каждый раз вызывая функцию отправки на отдельный пакет в 1кБайт (как раз та самая разбивка данных)?
Объясню, что имею ввиду: у меня есть TCP сервер и есть HTTP.
Вот в TCP я отправляю пакет в 1 кБайт каждый раз вызывая netconn_write

C

                for (i = 0; i < 12800; i++)
                {
                    netconn_write(conn, TcpSendBuffer, sizeof(TcpSendBuffer), NETCONN_NOCOPY);
                }

Т.е. условный массив данных я бью на пакеты по 1кБ. Получаю скорость 3-4 МБит/сек.
В HTTP я получаю GET запрос и на него отвечаю отправкой fsdata файла.
Т.е. здесь сервер уже сам занимается фрагментацией всего файла на пакеты.

C

                        if ((strncmp((char const *)buf,"GET / ",6)==0)||(strncmp((char const *)buf,"GET /index.html",15)==0))
                        {
                            fs_open(&file, "/index.html");
                            netconn_write(newconn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
                            fs_close(&file);
                        }
                        else if (strncmp((char const *)buf,"GET /IMG/Test1.png",18)==0)
                        {
                            fs_open(&file, "/IMG/Test1.png");
                            netconn_write(newconn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
                            fs_close(&file);
                        }

И если я правильно все посчитал, то скорость получается порядка 20 МБит/сек (передаваемая страница состоит из нескольких картинок, просто сложил их вес и поделил полученные Биты на время, за которое вся сраница передается сервером).
Т.е. скорость передачи гораздо выше.
Получается отправлять на передачу 100 МБит одним файлом (массивом) по скорости гораздо выгоднее чем отпралять тот же объем фрагментируя вручную по 1 кБайту?

Сообщение от Voland_

Воспользуйтесь wireshark

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

Сообщение от Voland_

аналогично наталкивался на это обсуждение

Я там полистал темы, думал может кто выложит исправленные файлы, но насколько я понял они их не планируют выкладывать, просто указали на ошибки, над которыми работали

Сообщение от Voland_

Не думаю, что non-RTOS решение будет существенно быстрее (если оно самодельное)

Да думал не самодельное, TCP RAW, но пока не знаю есть ли смысл белать без ОС

@Voland_ · 13.12.2020, 15:52

Сообщение от DmitryDDDD

Т.е. здесь сервер уже сам занимается фрагментацией всего файла на пакеты.

да, и в сервере есть механизмы подбора размера пакета, если при передаче возникают ошибки. Но объединять пакеты для того, чтобы ваши 12кб передать допустим, большим пакетом - он этого конечно не делает ).

Сообщение от DmitryDDDD

передаваемая страница состоит из нескольких картинок, просто сложил их вес и поделил полученные Биты на время, за которое вся сраница передается сервером

возьмите файлы по-больше. Ну, или просто скопируйте в данные содержимое FLASH - хотя бы пару мегабайт будет представительно для передачи (до 100Мбит все еще не дотягиваем).

PS: к сожалению, кстати, я пока что не нашел опции в HTTP не отправлять размер пакета в начале. Это сильно мешает, потому что в ряде случаев это просто невозможно сделать без формирования хотя бы части посылки в памяти (что отнимает ее, непосредственно).

Добавлено через 6 минут

Сообщение от DmitryDDDD

есть разница отправлять например 100 МБит одной командой, ну и там уже TCP сам отошлет по пакетам, или же каждый раз вызывая функцию отправки на отдельный пакет в 1кБайт (как раз та самая разбивка данных)?

вот это самый интересный вопрос с lwIP (еще не вникал). В нем есть COPY/NOCOPY режимы, которые наверняка в случае COPY выделяют для отправки сообщения память, и соответственно, позволяют не заботиться об отправленном буфере пользователю. Это удобно, пока хватает оперативки, и что еще важно - это может быть мультипоточно, хотя бы в теории. В случае с NOCOPY передавать большие файлы тоже непонятно как. Может ли сервер, грузить данные из stream'а или нет - я еще не понял.

@DmitryDDDD · 13.12.2020, 17:12 **[ТС]**

Voland_,

Сообщение от Voland_

В нем есть COPY/NOCOPY режимы

Насколько я знаю, COPY копирует данные для отправки, NOCOPY просто использует указатель на эти данные, различие в том, что если передаются какие-то статические данные (страница сервера, что-то редко изменяющееся и т.д.), то можно использовать NOCOPY не заботясь о том, что данные будут изменены до осуществления их передачи. Если же например передавать быстроизменяющиеся данные (опрос датчиков, АЦП и т.д.), то при использовании NOCOPY до осуществления передачи данных они могут быть изменены и передадутся не те данные, какие планировалось, а обновленные.
Вот тут есть описание:
https://doc.ecoscentric.com/re... write.html
Насколько использование COPY или NOCOPY влияет на быстродействие я не замерял, но по-моему, при использовании того и другого я получал примерно одинаковые результаты.

Сообщение от Voland_

скопируйте в данные содержимое FLASH - хотя бы пару мегабайт будет представительно для передачи

У меня Flash памяти у МК 1 МБайт, плюс там FReeRTOS настроена с добольно большими стеком, кучей, поэтому места на пару МБайт не хватит. Если Вы о внешнем носителе, то там наверно будет тратится дополнительно время на копирование (чтение) данных из памяти носителя в память МК?

@DmitryDDDD · 15.12.2020, 06:52 **[ТС]**

Voland_, Я проанализировал трафик сети, получилось, что много случаев, когда заканчивается место окна клиента (ПК), на стороне ПК я использую терминал PuTTY. Можете посоветовать какой-нибудь годный терминал для TCP?
Ну там еще ряд проблем есть, но пока хочу разобраться с размером окна, т.к., насколько я понимаю, в данном случае это сдерживает скорость, ну и есть косяки при открытии и закрытии соединения

@DmitryDDDD · 15.12.2020, 10:21 **[ТС]**

Voland_, В общем взял запустил соединение через Telnet Windows, различия с запуском при помощи PuTTY значительные. Тут уже нет переполнения окна. Поэтому скорость получилась примерно в 10 раз выше, порядка 30 МБит/сек

@Voland_ · 15.12.2020, 10:50

Сообщение от DmitryDDDD

соединение через Telnet Windows, различия с запуском при помощи PuTTY значительные

прикольно, интересное замечание (я на линуксе, возможно, просто не сталкивался).

Сообщение от DmitryDDDD

скорость получилась примерно в 10 раз выше, порядка 30 МБит/сек

звучит нормально ).
Думаю, выжать вот прям 100мбит на системе без FSMC и внешней памяти просто не удастся.

Добавлено через 3 минуты

Сообщение от DmitryDDDD

Если Вы о внешнем носителе, то там наверно будет тратится дополнительно время на копирование (чтение) данных из памяти носителя в память МК?

зависит от построения данные. В STM'ках есть QSPI и FSMC - они адресуются обычным буфером, что позволяет прямой доступ к памяти, а это значит что RAM не нужна, и задержки чтения если не в один такт, то все равно очень быстро читается.

@DmitryDDDD · 15.12.2020, 11:12 **[ТС]**

Voland_,

Сообщение от Voland_

прикольно, интересное замечание

Вот в wireshark прям видно как размер окна понемногу уменьшается до 0, а потом происходит его обновление, которое занимает порядка 100 мсек, и таких моментов во всем потоке передачи 100 МБит данных около 230, т.е. более чем 23 секунды МК просто ждал пока PuTTY разгребет принятую порцию данных.

Сообщение от Voland_

Думаю, выжать вот прям 100мбит на системе без FSMC и внешней памяти просто не удастся

Хотелось бы, конечно, под 50 МБит получить, но пока не знаю, будет ли нужна такая скорость передачи. Возможно придется искать что можно оптимизировать для более быстрой работы.

Сообщение от Voland_

В STM'ках есть QSPI и FSMC - они адресуются обычным буфером, что позволяет прямой доступ к памяти

Почитаю про это, но пока не совсем разобрался с прямым доступом к памяти, только DMA использую, и то о принципе работы знаю только в общих чертах.
А так еще мне в связке LWIP + FreeRTOS надо копаться и пробовать оптимизировать

@Voland_ · 15.12.2020, 14:29

Сообщение от DmitryDDDD

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

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

@DmitryDDDD · 16.12.2020, 10:20 **[ТС]**

Voland_, Можете подсказать по ошибкам? А то никак не могу найти причину. При установлении соединения и перед его закрытием постоянно появляются ошибки с потерей и повторной передачей пакетов.
Как только инициирую соединение клиента (ПК) с сервером (МК):
1) Ответ от МК идет долго - 235 пакет - 2.7 сек, за ним 236 пакет повторный
2) 239 пакет - это сообщение от МК, отправляемое автоматически при установлении соединения длиной 5 байт, там retransmission
3) 248 пакет - это команда с ПК для начала передачи данных, тоже retransmission
4) 261 - первый пакет данных от МК, он тоже почему-то постоянно отправляется повторно
Дальше все нормально, до окончания передачи
5) В конце отправки две повторные передачи тоже постоянно возникают
Вот с этим пока борюсь, но пока не решил это

@DmitryDDDD · 16.12.2020, 10:41 **[ТС]**

Voland_, На первой передаче массива данных (261 пакет) еще постоянно теряется 1.26 сек, что составляет огромную часть времени от передачи всех данных

Добавлено через 9 минут
Voland_,
И последний пакет 13176 тоже идет с потерей времени в 1.5 сек, да еще и по размеру не 1460 Байт как остальные.
Что-то у меня правка сообщений на форуме не работает совсем

@Voland_ · 16.12.2020, 11:16

Сообщение от DmitryDDDD

постоянно теряется 1.26 сек

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

PS: есть подозрение что проблема повторов компенсируется мультипоточностью передачи, но... система должна это учитывать и быть к этому готовой.

@DmitryDDDD · 16.12.2020, 11:30 **[ТС]**

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

@Voland_ · 16.12.2020, 14:18

Сообщение от DmitryDDDD

видите в чем дело

да, действительно ). Надо будет поизучать в чем причина. Может бага в lwIP а может со стороны клиента что-то. Попробуйте принять чем-то еще, понадежней. [попробую у себя запустить подобный тест].

@DmitryDDDD · 16.12.2020, 14:37 **[ТС]**

Voland_, Пытаюсь найти причины повторов, вычитал про SACK, хотел в кубе его включить, но тогда МК вообще перестал отвечать на соединение.
Мне кажется проблема в МК, как минимум первый повтор возникает из-за того, что клиент не может "достучаться" до сервера, соответственно МК не отвечает на SYS. Теряться пакетам тут негде, сеть локальная напрямую МК - ПК.
По-моему мне как-то удавалось делать сервер без ошибок на базе кода из этого урока https://narodstream.ru/stm-uro... cp-server/
Но потом было некоторое количество изменений.

Сообщение от Voland_

Попробуйте принять чем-то еще, понадежней

Я тут уже даже не знаю, что еще взять. PuTTY, telnet, сейчас этим пользуюсь.

Сообщение от Voland_

попробую у себя запустить подобный тест

Ожидаю Ваших результатов, пока буду пробовать искать причину

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
		1
	LWIP TCP RAW API server 07.12.2020, 14:23. Показов 5217. Ответов 17 Метки ethernet, lwip, raw, raw api, stm32, tcp server (Все метки) Решил настроить на stm32f746 discovery LWIP TCP RAW сервер, но никак не могу это реализовать. Есть настроенный TCP netconn на FreeRTOS, но хочу сделать без ОС, посмотреть как будет работать в отличае от netconn. Может у кого-нибудь есть пример или код LWIP RAW? Буду благодарен, не могу никак запустить из документации, куча ошибок. Еще есть такой вопрос: как можно получить скорость передачи десятки Мбит/сек на stm32? Мой TCP сервер выдает 3-4 Мбит, HTTP на его базе вроде гораздо шустрее передает, но нужен именно TCP. UDP не пробовал, но судя по тому, что там возможна потеря данных, такой вариант не подходит. Плата stm32f746 discovery, PHY - LAN8742a, Использую CubeMX и HAL. На CMSIS уже задумываюсь попробовать, если будут подходящие примеры, но это видимо очень не просто 0

@shepard127 16 / 16 / 1 Регистрация: 20.10.2013 Сообщений: 81
	10.12.2020, 14:14	2
	Сообщение от DmitryDDDD На CMSIS уже задумываюсь попробовать Могу посоветовать для начала собрать и запустить готовый пример с CubeMX + HAL + FreeRTOS, затем попробовать откинуть FreeRTOS. Ну а когда и без FreeRTOS у вас будет всё работать - тогда на CMSIS писать, думаю к тому времени у вас уже опыта будет достаточно, чтоб во всём разобраться. Сообщение от DmitryDDDD Еще есть такой вопрос: как можно получить скорость передачи десятки Мбит/сек на stm32? На STM32 или на любом другом микроконтроллере, компютере, телефоне... Скорость определяется одинаково, нужно взять определнный объем информации и начать передавать. К примеру если у вас файл размером 50 Мбайт, передался за 16 секунд. То вы делаете следующее: 50 / 16 = 3,1875 (узнаете сколько было передано МБ за 1 секунду), затем: 3,1875 * 8 = 22,5 Mbit/s (узнаете какая скорость необходима, для того чтоб передать этот объем информации за 1 сек.) В данном случае: 22,5 Mbit/s. Это ваша скорость 0

@Voland_ 1978 / 1276 / 131 Регистрация: 04.01.2010 Сообщений: 4,607
	12.12.2020, 14:17	4
	Сообщение от DmitryDDDD Но применить их знания и оптимизировать код так, чтобы получить больше 90 Мбит/сек (по их данным) [аналогично наталкивался на это обсуждение, просто подпишусь, чтобы отслеживать Ваши успехи]. Не думаю, что non-RTOS решение будет существенно быстрее (если оно самодельное). Воспользуйтесь wireshark, чтобы отследить как именно стек бьет ваши пакеты по 1к при отправке (кстати, зачем вы бьете данные?). Так же можно много чего диагностировать.И да netconn концептуально написан хоть и с прицелом на оптимальность, но мог бы быть гораздо лучше организован. Не далее как вчера изучал подробности реализации WEB-сервера [lwIP] на его базе. 0

@Voland_ 1978 / 1276 / 131 Регистрация: 04.01.2010 Сообщений: 4,607
	13.12.2020, 15:52	6
	Сообщение от DmitryDDDD Т.е. здесь сервер уже сам занимается фрагментацией всего файла на пакеты. да, и в сервере есть механизмы подбора размера пакета, если при передаче возникают ошибки. Но объединять пакеты для того, чтобы ваши 12кб передать допустим, большим пакетом - он этого конечно не делает ). Сообщение от DmitryDDDD передаваемая страница состоит из нескольких картинок, просто сложил их вес и поделил полученные Биты на время, за которое вся сраница передается сервером возьмите файлы по-больше. Ну, или просто скопируйте в данные содержимое FLASH - хотя бы пару мегабайт будет представительно для передачи (до 100Мбит все еще не дотягиваем). PS: к сожалению, кстати, я пока что не нашел опции в HTTP не отправлять размер пакета в начале. Это сильно мешает, потому что в ряде случаев это просто невозможно сделать без формирования хотя бы части посылки в памяти (что отнимает ее, непосредственно). Добавлено через 6 минут Сообщение от DmitryDDDD есть разница отправлять например 100 МБит одной командой, ну и там уже TCP сам отошлет по пакетам, или же каждый раз вызывая функцию отправки на отдельный пакет в 1кБайт (как раз та самая разбивка данных)? вот это самый интересный вопрос с lwIP (еще не вникал). В нем есть COPY/NOCOPY режимы, которые наверняка в случае COPY выделяют для отправки сообщения память, и соответственно, позволяют не заботиться об отправленном буфере пользователю. Это удобно, пока хватает оперативки, и что еще важно - это может быть мультипоточно, хотя бы в теории. В случае с NOCOPY передавать большие файлы тоже непонятно как. Может ли сервер, грузить данные из stream'а или нет - я еще не понял. 1

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	13.12.2020, 17:12 [ТС]	7
	Voland_, Сообщение от Voland_ В нем есть COPY/NOCOPY режимы Насколько я знаю, COPY копирует данные для отправки, NOCOPY просто использует указатель на эти данные, различие в том, что если передаются какие-то статические данные (страница сервера, что-то редко изменяющееся и т.д.), то можно использовать NOCOPY не заботясь о том, что данные будут изменены до осуществления их передачи. Если же например передавать быстроизменяющиеся данные (опрос датчиков, АЦП и т.д.), то при использовании NOCOPY до осуществления передачи данных они могут быть изменены и передадутся не те данные, какие планировалось, а обновленные. Вот тут есть описание: https://doc.ecoscentric.com/re... write.html Насколько использование COPY или NOCOPY влияет на быстродействие я не замерял, но по-моему, при использовании того и другого я получал примерно одинаковые результаты. Сообщение от Voland_ скопируйте в данные содержимое FLASH - хотя бы пару мегабайт будет представительно для передачи У меня Flash памяти у МК 1 МБайт, плюс там FReeRTOS настроена с добольно большими стеком, кучей, поэтому места на пару МБайт не хватит. Если Вы о внешнем носителе, то там наверно будет тратится дополнительно время на копирование (чтение) данных из памяти носителя в память МК? 0

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	15.12.2020, 06:52 [ТС]	8
	Voland_, Я проанализировал трафик сети, получилось, что много случаев, когда заканчивается место окна клиента (ПК), на стороне ПК я использую терминал PuTTY. Можете посоветовать какой-нибудь годный терминал для TCP? Ну там еще ряд проблем есть, но пока хочу разобраться с размером окна, т.к., насколько я понимаю, в данном случае это сдерживает скорость, ну и есть косяки при открытии и закрытии соединения Миниатюры 0

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	15.12.2020, 10:21 [ТС]	9
	Voland_, В общем взял запустил соединение через Telnet Windows, различия с запуском при помощи PuTTY значительные. Тут уже нет переполнения окна. Поэтому скорость получилась примерно в 10 раз выше, порядка 30 МБит/сек Миниатюры 1

@Voland_ 1978 / 1276 / 131 Регистрация: 04.01.2010 Сообщений: 4,607
	15.12.2020, 10:50	10
	Сообщение от DmitryDDDD соединение через Telnet Windows, различия с запуском при помощи PuTTY значительные прикольно, интересное замечание (я на линуксе, возможно, просто не сталкивался). Сообщение от DmitryDDDD скорость получилась примерно в 10 раз выше, порядка 30 МБит/сек звучит нормально ). Думаю, выжать вот прям 100мбит на системе без FSMC и внешней памяти просто не удастся. Добавлено через 3 минуты Сообщение от DmitryDDDD Если Вы о внешнем носителе, то там наверно будет тратится дополнительно время на копирование (чтение) данных из памяти носителя в память МК? зависит от построения данные. В STM'ках есть QSPI и FSMC - они адресуются обычным буфером, что позволяет прямой доступ к памяти, а это значит что RAM не нужна, и задержки чтения если не в один такт, то все равно очень быстро читается. 1

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	15.12.2020, 11:12 [ТС]	11
	Voland_, Сообщение от Voland_ прикольно, интересное замечание Вот в wireshark прям видно как размер окна понемногу уменьшается до 0, а потом происходит его обновление, которое занимает порядка 100 мсек, и таких моментов во всем потоке передачи 100 МБит данных около 230, т.е. более чем 23 секунды МК просто ждал пока PuTTY разгребет принятую порцию данных. Сообщение от Voland_ Думаю, выжать вот прям 100мбит на системе без FSMC и внешней памяти просто не удастся Хотелось бы, конечно, под 50 МБит получить, но пока не знаю, будет ли нужна такая скорость передачи. Возможно придется искать что можно оптимизировать для более быстрой работы. Сообщение от Voland_ В STM'ках есть QSPI и FSMC - они адресуются обычным буфером, что позволяет прямой доступ к памяти Почитаю про это, но пока не совсем разобрался с прямым доступом к памяти, только DMA использую, и то о принципе работы знаю только в общих чертах. А так еще мне в связке LWIP + FreeRTOS надо копаться и пробовать оптимизировать Миниатюры 0

@Voland_ 1978 / 1276 / 131 Регистрация: 04.01.2010 Сообщений: 4,607
	15.12.2020, 14:29	12
	Сообщение от DmitryDDDD Почитаю про это, но пока не совсем разобрался с прямым доступом к памяти, только DMA использую, и то о принципе работы знаю только в общих чертах. а прогреммисту и знать особо не надо - это хардверная фича. Контроллер внешней памяти делает так, что программеру нужно только обращаться к данным, как к адресуемым ячейкам - все остальные манипуляции с внешней памятью он делает стейт-машиной. Это сильно упрощает код, т.к. он ложится без проблем на модель обращения к переменным, буферам, и вообще - выделенной памяти как к своей собственной. Не так как в SPI или I2C - и нужно было бы сначала читать, потом парсить. 0

	16.12.2020, 14:37

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	16.12.2020, 10:20 [ТС]	13
	Voland_, Можете подсказать по ошибкам? А то никак не могу найти причину. При установлении соединения и перед его закрытием постоянно появляются ошибки с потерей и повторной передачей пакетов. Как только инициирую соединение клиента (ПК) с сервером (МК): 1) Ответ от МК идет долго - 235 пакет - 2.7 сек, за ним 236 пакет повторный 2) 239 пакет - это сообщение от МК, отправляемое автоматически при установлении соединения длиной 5 байт, там retransmission 3) 248 пакет - это команда с ПК для начала передачи данных, тоже retransmission 4) 261 - первый пакет данных от МК, он тоже почему-то постоянно отправляется повторно Дальше все нормально, до окончания передачи 5) В конце отправки две повторные передачи тоже постоянно возникают Вот с этим пока борюсь, но пока не решил это Миниатюры 0

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	16.12.2020, 10:41 [ТС]	14
	Voland_, На первой передаче массива данных (261 пакет) еще постоянно теряется 1.26 сек, что составляет огромную часть времени от передачи всех данных Добавлено через 9 минут Voland_, И последний пакет 13176 тоже идет с потерей времени в 1.5 сек, да еще и по размеру не 1460 Байт как остальные. Что-то у меня правка сообщений на форуме не работает совсем 0

@Voland_ 1978 / 1276 / 131 Регистрация: 04.01.2010 Сообщений: 4,607
	16.12.2020, 11:16	15
	Сообщение от DmitryDDDD постоянно теряется 1.26 сек нашел статью (в поисках уменьшить RTO). Я так понимаю, эти параметры определены спецификацией протокола, поэтому, навряд ли можно с этим что-то сделать, кроме как поменять "железо" (об этом сказано в статье). PS: есть подозрение что проблема повторов компенсируется мультипоточностью передачи, но... система должна это учитывать и быть к этому готовой. 0

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	16.12.2020, 11:30 [ТС]	16
	Voland_, Но тут видите в чем дело, потеря времени на повторы это уже следствие, а вот сама причина этих повторов в начале и конце передачи не понятна. По всему остальному потоку они не возникают 0

@Voland_ 1978 / 1276 / 131 Регистрация: 04.01.2010 Сообщений: 4,607
	16.12.2020, 14:18	17
	Сообщение от DmitryDDDD видите в чем дело да, действительно ). Надо будет поизучать в чем причина. Может бага в lwIP а может со стороны клиента что-то. Попробуйте принять чем-то еще, понадежней. [попробую у себя запустить подобный тест]. 0

@DmitryDDDD 4 / 4 / 0 Регистрация: 12.11.2018 Сообщений: 511
	16.12.2020, 14:37 [ТС]	18
	Voland_, Пытаюсь найти причины повторов, вычитал про SACK, хотел в кубе его включить, но тогда МК вообще перестал отвечать на соединение. Мне кажется проблема в МК, как минимум первый повтор возникает из-за того, что клиент не может "достучаться" до сервера, соответственно МК не отвечает на SYS. Теряться пакетам тут негде, сеть локальная напрямую МК - ПК. По-моему мне как-то удавалось делать сервер без ошибок на базе кода из этого урока https://narodstream.ru/stm-uro... cp-server/ Но потом было некоторое количество изменений. Сообщение от Voland_ Попробуйте принять чем-то еще, понадежней Я тут уже даже не знаю, что еще взять. PuTTY, telnet, сейчас этим пользуюсь. Сообщение от Voland_ попробую у себя запустить подобный тест Ожидаю Ваших результатов, пока буду пробовать искать причину 0