Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

Делюсь опытом Super fast WIFI UDP

Тема в разделе "SDK и создание собственных прошивок", создана пользователем nikolz, 26 май 2019.

  1. nikolz

    nikolz Гуру

    Сообщения:
    5.350
    Симпатии:
    473
    Немного истории.
    ---------------------
    Прошло четыре года с тех пор ,
    как я выложил свои результаты исследований энергопотребления ESP8266 на основе SDK.
    --------------------
    В ту пору общепринятым было время выхода из режима deep-sleep
    и передача сообщения порядка 4 секунд.
    Но у меня получилось время выхода из режима deep-sleep
    и передача сообщения по UDP порядка 0.3 секунд,
    что не удалось получить до настоящего времени никому в интернет.
    ------------------------------
    Тогда гуру pvvx гневно утверждал,
    что у меня неисправен роутер и такого быть не может,
    так как он достиг в режиме AP 0.54 секунды.
    Я не стал спорить о том, что и у кого неисправно.
    ----------------------------
    Но вот прошло четыре года.
    В инете достигли минимального времени 1 сек.
    Меньшее время достигается либо протоколом ESP-NOW,
    либо переделкой софта роутера и использованием служебных пакетов.
    Что не является стандартом.
    ---------------------------
    Получить мой результат ,без костылей, со стандартным SDK никто так и не смог.
    =====================
    Настало время рассказать как это сделать.
    ------------------------
    При выходе из depp-sleep возможны три варианта подключения к WiFi
    и передачи сообщений.
    --------------------
    1) логин и пароль - новые значения.
    Время подключения и передачи сообщения UDP 4 секунды.
    ----------------------

    2) логин,пароль и IP сохраняем в RTC.
    Время подключения и передачи сообщения UDP 1.2 секунда.
    ----------------------

    3) логин, пароль, IP сохраняем в RTC и отключаем dhcpc.
    Время подключения и передачи сообщения UDP 0.3 секунды.
    =============
    Время рассчитывается с учетом интервала начального старта,
    которое составляет в стандартном boot 0.12 секунды.
    Если переписать загрузчик rboot, что я сделал,
    или использовать RepiadLoader от pvvx, что у меня так и не получилось использовать,
    то время можно еще сократить дополнительно на 0.04-0.06 секунды.
    Сейчас у меня получается 0.26 секунды.
    ==================
    Теперь вы можете уменьшить время активности своих устройств
    и увеличить время работы от батарейки в 3 раза, если у вас вариант 2,
    или в 13 раз, если у вас реализован вариант 1.
    ----------------------
    Успехов
     
    =AK= и tretyakov_sa нравится это.
  2. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    10.240
    Симпатии:
    1.349
    Это новая "история"? Ссылочки то можно было дать?
    Хотя-бы такие: (RTL 2016 год, стандартный SDK) Скорость подключения модуля к внешней AP
    Что это? Обзывательство?
    Я не "гуру". Не приписывайте мне того, чего нет.
    Просьба провести тест: Уточнить время выдачи запроса IP (DHCP) роутером после соединения к AP c зависимостями и привести модели роутеров.
    В "истории данного сайта" это уже было представлено многими (поищите)... и вывели - если опоздал и не уложился всеми стадиями соединения в один период beacon, то среднее для DHCP около 0.7 сек. Если нет - то десяток мс, но SDK ESP всегда опаздывает и проходит несколько beacon-ов...
    Особенно всем хотелось бы видеть полную диаграмму всех шагов WiFi станции при выходе в эфир и присоединении к AP по стандарту, а не малиновых слонов на графике и глюков вашего роутера, считающего что в эфире помехи и ему не достучаться до вашей станции десятками секунд после последнего необъявленного обрыва связи (по вашим описаниям он её ищет вечно - часами, а должен очистить ресурсы для других соединений)... А тут вдруг она опять появилась и орет в эфир, рушит всю синхронизацию сети, сбивая чужие пакеты, ломая распределение участников...
    Когда изучите, тогда и пишите :)
    Успехов в изучении простых вещей.
     
  3. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    10.240
    Симпатии:
    1.349
    Я могу вам в десятый раз описать кратко, не внедряясь в дебри 802.1, разбив на глобальные стадии:

    1. Включить питание. Дождаться, когда все PLL и аналоговые потроха выдут на стабильный режим работы.
    2. Произвести сканирование WiFi эфира. Типов бывает 2 – активный и пассивный.
    3. Объявить о выходе в эфир. Есть зависимости от п.п.2.
    4. Подправить частоту WiFi по преамбуле beacon той AP, которой будем соединяться или другими методами. Т.е. ждем до периода becon (0.1024 сек по умолчанию или как выставили на AP) и всегда имеем джиттер на синхронизацию со временем следования маяка от AP.
    5. Синхронизоваться (уточнить параметры AP) и начать перепалку пакетами с AP для соединения и всяких там согласований о шифрации, паролях и прочим. (если AP не занята другими клиентами, более приоритетной передачей…)
    6. Тут уже WiFi транспортный уровень для IP и надо получить IP от роутера.
    7. Передавать-принимать IP пакеты (UDP, TCP т.д.). Передача от станции ведется исключая активности во время и на время следования beacon от AP, учитывая арбитраж от AP.
    8. Объявить и завершить соединение с AP (или перейти в спящий режим DTIMn, договорившись с AP). Многие автоматом переходят в спящий режим в зависимости от профиля. Их несколько стандартных и все параметры к ним описаны и обычно задаются в SDK (в ESP - нет). Обычно умолчанию, автомат тратит на анализ, что трафика нет пару секунд, включая согласование с переходом в “спящий режим” с AP. ESP в режиме “Modem” – от 10 сек…
    9. Если в спящем режиме, то надо проснуться как договорились с AP (после пропуска n beacon)и включить приемник загодя c указанной тут точностью (-25 us для Low-cost ширпотреба) .

    • Время, затрачиваемое дешевыми роутерами на любой стадии зависит от объема их RAM, т.к. в свободной RAM в Linux размещены “кеши”. Если она уже выедена другими задачами, то для дешевых роутеров с 64..128МБ RAM это дает доп. задержки на каждой стадии/задаче к 20 ms. При наличии в “кеш” всего необходимого – пару ms. Даже по этому параметру у вас не видно +- в соединении, а в итоге, если специально не озаботиться, оно достигает нескольких периодов beacon...
     
  4. clinkme

    clinkme Новичок

    Сообщения:
    32
    Симпатии:
    3
    Написано много, а полезной информации нет (либо я не смог ее понять).
    При выходе из deep-sleep происходит полная инициализация (кроме RTC понятно).
    В любом случае при этом надо вызывать
    wifi_station_set_config(&conf);
    При чем тут RTC? Или Вы хотите сказать, что все задержки связаны с чтением этой conf из flash?
    C таким же успехом конфигурацию можно просто в коде забить константами, тогда это еще быстрей будет (поскольку она окажется в RAM).
     
  5. nikolz

    nikolz Гуру

    Сообщения:
    5.350
    Симпатии:
    473
    Я рассказал свой результат и объяснил Вам как смог.
    У меня вообще нет проблем, тем более что Вы не поняли.
    ----------------------------
    можете сделать быстрее, расскажите результат, а не свои фантазии.
    это будет ваш опыт.
     
  6. clinkme

    clinkme Новичок

    Сообщения:
    32
    Симпатии:
    3
    Когда человек делится своми достижениями, целью все-таки должно являться
    донести информацию и обеспечить возможность их повторения другими (и как сверхзадача - превзойти их). Так устроена цивилизация.
    Если задача - просто прокричать, что вы все м., а я весь в белом - тогда да...
    Можете хотя-бы псевдо-кодом расписать ваши операции при выходе из deep sleep?
     
  7. nikolz

    nikolz Гуру

    Сообщения:
    5.350
    Симпатии:
    473
    это ваше мнение.
    применяйте его к себе.
    если мне надо будут нравоучения я пойду к батюшке в церковь.
    ------------
    и не пытайтесь свои хотелки навязывать другим.
    Не придумывайте того что не написано .
     
  8. nikolz

    nikolz Гуру

    Сообщения:
    5.350
    Симпатии:
    473
    А вы полагаете что у меня будет желание Вам что-то рассказывать после ваших нравоучений и наставлений?
    Нахрена мне это надо?
    Я общаюсь на форуме, если мне это интересно.
     
  9. clinkme

    clinkme Новичок

    Сообщения:
    32
    Симпатии:
    3
    м. и есть
     
  10. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    10.240
    Симпатии:
    1.349
    Не стоит слишком высоко оценивать всё человечество, особенно по его примитивным обитателям...
    Тут всё гораздо проще - сам ТС не может создать код или выдумать какой новый алгоритм, новое решение задачи и т.д.
    По этому он выдумывает разные байки по теме как вы и описали - он типа что-то превзошел. Похвастался тем, чего у него нет.
    И цель этого - чтобы вы создали, обучили или дали ему всё готовое. :p
    Глупый вопрос. См. первый абзац. :)
     
  11. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    10.240
    Симпатии:
    1.349
    В ESP8266 по вашему описанию не учитываются задержки заполнения кеш для кода и данных с SPI FLASH. При старте вся кеш (в IRAM) пуста. Большинство кода стартовых процедур инициализации исполняются линейно, при постоянной подгрузке из SPI FLASH. Т.е. скорость работы CPU ограничен скоростью отработки шины SPI. Это в теоретическом максимуме при QSPI 80 MHz составляет до:

    80*0.6/2 = 24 МБ в сек. где 0.6 – это учет тактов на передачу заголовка адреса для запроса блока из spi-flash, а 2 – это что требуется 2 такта шины qspi для считывания байта.

    Средняя длина кода (АСМ) команды для CPU ESP8266 составляет более 2.5 байта.
    Итого в CPU поступает не более чем:

    32/2.5 = 12.8 мега команд в сек.

    Т.к. ещё не учтены многие другие задержки и прочие факторы типа прерываний отнимающих время исполнения основных задач, имеем что ESP8266 работает со скоростью 8..10 МГц CPU с другой архитектурой.
    Длина исполняемого кода SDK, перелопачиваемая CPU при инициализации на сегодня (особенно в Arduino) разрослась за многие мегабайты. Туда надо добавить, что каждое обращения к процедуре чтения Flash вызывает опустошение всех 32 килобайт кеш памяти в IRAM, плюс любая запись в flash имеет неимоверную задержку во времени…

    Наш Гуру @nikolz ещё не дошел до учета оптимизации по данным параметрам, которая была проделана более 3-х лет назад другими...
     
  12. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    10.240
    Симпатии:
    1.349
    И вот эти утверждения совершенно неверны:
    Чтобы данные оказались в RAM (сегмент .rodata), требуется их загрузка boot-loader-ом. А он у Espressif загружает их с Flash в режиме однобитной шины SPI и при пониженной частоте процедурами из ROM с максимально выставленными задержками в протоколе работы с Flash (чтобы работала любая Flash). Отношение скоростей доступа к блокам при нормально сконфигурированной системы аппаратной трансляции/отображения QSPI Flash в память процессора от boot-loader-а в ROM составляет сотни единиц. Туда надо ещё прибавить время разборки boot-loader-ом заголовков и особенно низкоскоростной вывод в UART сообщений без использования FIFO UART. В итого скорость загрузки констант в RAM в среднем не более сотни килобайт в секунду.

    Это спорно и зависит от объемов и особенно программной процедуры чтения из Flash или RTC, если таковая используется.

    Чтение из RTC имеет узкое место в виде низкоскоростной шины, тактируемой в 26МГц, её FIFO и дополнительных команд для CPU опустошения реального cache (которого нет у ESP) вставленных неправильно сконфигурированным транслятором gcc любителями… (они ещё и увеличивают размер кода загрузки и т.д.)

    Размещение константы в ICACHE_FLASH_ATTR (и типа, в сегменте кода) запросто конкурирует с чтением аналогичных данных по шине из RTC по фактическому адресу. Если используется процедура от любителей (Espressif) для чтения из RTC, то это в сотни раз дольше. Т.е. тут чисто программная зависимость…
     

Поделиться этой страницей