-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Как заставить google chrome давать ack не через 0.2 сек для стека http на esp8266?
- Автор темы pvvx
- Дата начала
Пока только реверс-инжиниринг IDA_plugin_xtensa_v0.2.zip и патч библиотек SDK
pvvx
Активный участник сообщества
Это всё дает любая заливка в ESP8266. Возникает E:\esp_iot_sdk\bin\eagle.app.v6.S - asm c метками.
А проблема в другом. Explorer подтверждает пакет стека через 0.000xx сек, а Хром - через 0.2...0.01 сек. За это время стек ESP8266 (5800 байт) уже весь передается и ждет подтверждения, для возможного отката. Даже мобильники и то быстрее дают ответ. Тут дело в самом Хромом и его стеке HTTP. Его версия стоит ещё в одном браузере.... Самые тормозные
- Читайте на гугле - установите быстрый .... а не нравиться - оптимизируйте свой сайт
https://developers.google.com/speed/pagespeed/insights/
Все запросы на добавочные файлы в конец странички, пока Хромой додумается, но уже яве сообщит, что загрузил всё
А проблема в другом. Explorer подтверждает пакет стека через 0.000xx сек, а Хром - через 0.2...0.01 сек. За это время стек ESP8266 (5800 байт) уже весь передается и ждет подтверждения, для возможного отката. Даже мобильники и то быстрее дают ответ. Тут дело в самом Хромом и его стеке HTTP. Его версия стоит ещё в одном браузере.... Самые тормозные
- Читайте на гугле - установите быстрый .... а не нравиться - оптимизируйте свой сайтhttps://developers.google.com/speed/pagespeed/insights/
Все запросы на добавочные файлы в конец странички, пока Хромой додумается, но уже яве сообщит, что загрузил всё
Последнее редактирование:
pvvx
Активный участник сообщества
https://yadi.sk/d/tsti_h_2dVHLc Отладочная прошивка для исследования областей памяти в ESP8266 и скорости передачи больших файлов...
(собрал наскоро, с отрезанным функционалом установок по http, т.к. ещё не отладил и лень делать дизайн страниц сервера, но задачу проверки скорости передачи и чтения RAM/Flash выполняет).
При включении имеем WiFi станцию с именем "ESP8266" и паролем "0123456789". COM порт установлен на 256000 Baud. Соединяемся со станцией, входим на страничку отладки (введя имя и пароль) и считываем интересующие области памяти из чипа в файлы. Области, занятые распределением flash в RAM читать не стоит - будет "эксепшн" и перезагрузка модуля.
По скорости передачи: Google Chrome у меня дает ~ 10кбайт/сек, а Internet Explorer и другие браузеры - более 650кбайт/с. Проблема с этим так и не решена.
Адреса: файл прошивки для FLASH_DOWNLOAD_TOOLS_v0.9.3.x
0x7e000: blank.bin
0x7c0000: esp_init_data_default.bin
0x00000: 00000_eagle.app.v6.bin
0x40000: 40000_eagle.app.v6.bin
0x1e000: WEBFiles.bin
(собрал наскоро, с отрезанным функционалом установок по http, т.к. ещё не отладил и лень делать дизайн страниц сервера, но задачу проверки скорости передачи и чтения RAM/Flash выполняет).
При включении имеем WiFi станцию с именем "ESP8266" и паролем "0123456789". COM порт установлен на 256000 Baud. Соединяемся со станцией, входим на страничку отладки (введя имя и пароль) и считываем интересующие области памяти из чипа в файлы. Области, занятые распределением flash в RAM читать не стоит - будет "эксепшн" и перезагрузка модуля.
По скорости передачи: Google Chrome у меня дает ~ 10кбайт/сек
, а Internet Explorer и другие браузеры - более 650кбайт/с. Проблема с этим так и не решена.Адреса: файл прошивки для FLASH_DOWNLOAD_TOOLS_v0.9.3.x
0x7e000: blank.bin
0x7c0000: esp_init_data_default.bin
0x00000: 00000_eagle.app.v6.bin
0x40000: 40000_eagle.app.v6.bin
0x1e000: WEBFiles.bin
Sanya_kv
New member
Это не баг, это фича. И проблема эта не в "google chrome", а прокладки которую он использует.
Для ускорения обмена, передача выполняется по 2 пакета. Получатель, после получения первого пакета в течении 200 мСек ожидает второй. Если за первым приходит сразу второй, то АСК передается сразу, либо по истечении 200 млСек.
Т.Е. Вам достаточно выполнять отправку два раза, не дожидаясь 1-го ACK.
Для ускорения обмена, передача выполняется по 2 пакета. Получатель, после получения первого пакета в течении 200 мСек ожидает второй. Если за первым приходит сразу второй, то АСК передается сразу, либо по истечении 200 млСек.
Т.Е. Вам достаточно выполнять отправку два раза, не дожидаясь 1-го ACK.
pvvx
Активный участник сообщества
В два пакета на MS Explorere само всё... Больше 2-х просто стек у ESP2866 короток
На MS Explorere и выходит 1.2Mbps/s. На Хромом - наверно 100к При 200ms Хромой подтверждает стек 5 раз в секунду. А стек у нас (максимальное окно) 5-ть с копейками килобайт. Вот и выходит 5*5 = 25
Sanya_kv
New member
Так не важна какова длинна отправляемого пакета. Отправляй хоть по 100 байт, главное по 2 пакета (2 раза). Это сам MS придумал, по умолчанию это используется в его библиотеках, хром работает через них, ещё пару лет назад также работал IE и другие. С lwip разбирался очень давно, что уже забыл как в нем. По этому подсказать не могу. До ESP руки дошли только сейчас.В два пакета на MS Explorere само всё... Больше 2-х просто стек у ESP2866 короток
При 200ms Хромой подтверждает стек 5 раз в секунду. А стек у нас (максимальное окно) 5-ть с копейками килобайт. Вот и выходит 5*5 = 25
У меня к Вам пара вопросов, какой Вы используете адаптер USB to RS232? и Возможно из исходников полностью выкинуть стек LwIP?
Заранее благодарен за ответы.
pvvx
Активный участник сообщества
Хром вроде имеет свой стек HTTP, по тому и дурит.
А это, отправка по два пакета никак не управляется в Lwip. И приведет только к потере скорости ещё с Хромым...
Он просто считает, что у всех должен быть стек минимум в 128кило...Любой - у меня есть практически все типы. К модулю включен FT2232, т.к. он двойной. По одному (UART0 в ESP) программируется, а по второму - только TX UART1 - отладочная информация. С двумя отключать/переключать ничего не надо при отладке/заливке прошивки.
Всё возможно, но Lwip более менее что работает в сборке SDK от Espressif. Всё остальное гораздо хуже, особенно где в заголовке цельно-стянутых примеров из опен-сорцов в SDK красуются надписи "Copyright (c) Espressif System" и вставлены эксклюзивные баги
Последнее редактирование:
Sanya_kv
New member
Эта проблема транспортного уровня - TCP, это хорошо видно из Вашего видео в wireshark. Я с этим тоже в своё время наелся.
pvvx
Активный участник сообщества
Большинство ПО писанное на Windows не тормозит, как это делает Chrome. Из этого и выводы, что что-то с ним не то.Эта проблема транспортного уровня - TCP, это хорошо видно из Вашего видео в wireshark. Я с этим тоже в своё время наелся.
pvvx
Активный участник сообщества
Выкинуть все либы и оставить только ROM с загрузкой вашего кода. Пример вложен там: http://esp8266.ru/forum/threads/moja-sborka-espressif-devkit.32/page-4#post-948
Sanya_kv
New member
Спасибо большое. Планирую использовать свой стек. К сожалению пока не могу его выложить, из-за ограничений.
pvvx
Активный участник сообщества
Ещё долго придется ковыряться - внятных описаний регистров чипа, особенно части WiFi пока нет.Спасибо большое. Планирую использовать свой стек. К сожалению пока не могу его выложить, из-за ограничений.
d946
New member
pvvx, посмотрите результат строчки
"web_conn->msgbufsize = tcp_sndbuf(ts_conn->pcb);"
скорее всего при запросе через хром будет
2920 -первая передача
потом будет падать до 1500-1700 и так до конца передачи, в результате падение скорости передачи.
Выход из этой ситуации полностью заполнять буфер до 2920, при каждом формировании посылки.
У Вас при получении файлов с Content-length тоже идет падение скорости через хром или передача идет без падения скорости?
"web_conn->msgbufsize = tcp_sndbuf(ts_conn->pcb);"
скорее всего при запросе через хром будет
2920 -первая передача
потом будет падать до 1500-1700 и так до конца передачи, в результате падение скорости передачи.
Выход из этой ситуации полностью заполнять буфер до 2920, при каждом формировании посылки.
У Вас при получении файлов с Content-length тоже идет падение скорости через хром или передача идет без падения скорости?
pvvx
Активный участник сообщества
tcp_sndbuf(ts_conn->pcb) (snd_buf; /* Available buffer space for sending (in bytes). */) это и есть сколько можно заполнить в буфер. Передачи организованы так - заливается сколько влезет и как есть место снова заливается. Куда Lwip будет класть то, что больше его буферов ?
И прошло достаточно времени, чтобы протестировать скорость на других устройствах и браузерах. Беда только с Хромом. У не него не только в этом беда. Корпоративные клиенты отказываются от Хрома - он требует очень много ресурсов от общего сервера, т.к. в конторах у всех стоят только мониторы, а диск и ПО сидят на общем сервере... У него ещё и другие беды....
Лучше объясните, почему Хром делает задержку в подтверждении пакетов TCP? IE и другие так не делают.
Могу дополнить только это:
Если модуль успел выплюнуть, а експлорер не успел подтвердить. Модуль всегда выплевывает по максимуму окна TCP стека. И мы не можем передать ещё, т.к. TCP стек у модуля забит и ждет подтверждения о приме от обратной стороны. А Хром тупит и делает задержку, ожидая что у нас стек в мегобайты...
Последнее редактирование:
d946
New member
проблема при формирование ответа Chunked в функции webserver_send_fdata
в начале функции мы получаем
web_conn->msgbufsize=tcp_sndbuf(ts_conn->pcb)
но в конце функции мы пошлем на 2 -3 байта меньше ранее полученного, за счет ранее зарезервированного места под размер chunka.
Посмотрите в начале функции
os_printf("sndbuf=%u! ", web_conn->msgbufsize);
и поставьте вызов os_printf("sndbuf=%u! ", web_conn->msgbufsize); перед
tcpsrv_int_sent_data(ts_conn, web_conn->msgbuf, web_conn->msgbuflen);
и если они у Вас равны значит я не прав, но у меня была именно эта причина падения скорости.
в начале функции мы получаем
web_conn->msgbufsize=tcp_sndbuf(ts_conn->pcb)
но в конце функции мы пошлем на 2 -3 байта меньше ранее полученного, за счет ранее зарезервированного места под размер chunka.
Посмотрите в начале функции
os_printf("sndbuf=%u! ", web_conn->msgbufsize);
и поставьте вызов os_printf("sndbuf=%u! ", web_conn->msgbufsize); перед
tcpsrv_int_sent_data(ts_conn, web_conn->msgbuf, web_conn->msgbuflen);
и если они у Вас равны значит я не прав, но у меня была именно эта причина падения скорости.
pvvx
Активный участник сообщества
При чем тут 2 или 3 байта? Хром дает подтверждение TCP стека через 0.1..0.2 сек.
Как итог - больше, чем 10..20 размеров ТСP стека в секунду ему не передать. У нас mss, размер TCP пакета ~1500 байт, а "стек" TCP = 4 * mss. Итого 1500*4*10 = 60000 байт в секунду для Хрома, как предел.
У IE и остальных время подтверждения приема пакета = скорости CPU и системы = микросекунды.
Размер chunka в HTTP вообще не связан со скоростью. Это вложенный в HTTP TCP протокол. У нас тормозит TCP, а не что он транспортирует.
Пошлите стек разбитый хоть на 1000 пакетов, Хром подтвердит всего 10..20 штук стеков в сек. В то-же время IE будет слать пакеты подтверждения сколько успеет по быстродействию.
При том, что у нас всего 6 кило TCPстек на модуле разница в передаче и составляет:
Хром – до 60 килобайт в сек
IE– 1.2 Мегабайта в секунду (предел по WiFi на модуле)
А вы считаете мелкие издержки на накладных расходах (размеры заголовков в пакетах).
Как "дойдет" - отпишитесь, а то из меня объяснятель фиговый (не знаю того, что вы знаете или чего не знаете и пытаюсь описать без специальных сложных терминов, а это сложно).
Последнее редактирование:
d946
New member
На картинках видна скорость до 150 явно больше 60 килобайт в сек
В течении 10 минут скину прошивку и описание.
pvvx
Активный участник сообщества
Ровно в десять раз медленнее, чем у меня при flash Winbond на модуле.В IE 1 Мегабайт в секунду с моей "Свалки" в Web при трансляции проекта без вывода отладки. В теме "свалки" дано много графиков и замеров.
d946
New member
Прошивка в прикрепленном файле
Wi-fi : ESP8266 без пароля
URL : http://192.168.4.1:8080/flash.cgi - дамп flash 512 килобайт
URL : http://192.168.4.1:8080/big.cgi - отдает файл 20 Мбайт для теста
Цель начатой мной дискуссии не замеры скорости, а факт если стек LWIP разрешает определенный размер буфера отправки, а мы его не заполняем полностью, при следующей отправке разрешенный размер буфера будет сокращаться.
Wi-fi : ESP8266 без пароля
URL : http://192.168.4.1:8080/flash.cgi - дамп flash 512 килобайт
URL : http://192.168.4.1:8080/big.cgi - отдает файл 20 Мбайт для теста
Цель начатой мной дискуссии не замеры скорости, а факт если стек LWIP разрешает определенный размер буфера отправки, а мы его не заполняем полностью, при следующей отправке разрешенный размер буфера будет сокращаться.