| |
|
  |
 LwIP + FeeRTOS: stats |
|
|
|
|
 May 10 2017, 12:31
|
Местный
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978
|
Тестирую устройство на устойчивость от большого количества трафика по Ethernet. При этом в отладку вывожу статистику: CODE MEM HEAP
avail: 10240
used: 0
max: 6560
err: 0
MEM RAW_PCB
avail: 4
used: 1
max: 1
err: 0
MEM UDP_PCB
avail: 6
used: 4
max: 4
err: 0
MEM TCP_PCB
avail: 10
used: 10
max: 10
err: 0
MEM TCP_PCB_LISTEN
avail: 6
used: 3
max: 3
err: 0
MEM TCP_SEG
avail: 12
used: 0
max: 5
err: 0
MEM NETBUF
avail: 2
used: 0
max: 0
err: 0
MEM NETCONN
avail: 4
used: 2
max: 2
err: 0
MEM TCPIP_MSG_API
avail: 8
used: 0
max: 0
err: 0
MEM TCPIP_MSG_INPKT
avail: 8
used: 65530
max: 65535
err: 0
MEM SYS_TIMEOUT
avail: 10
used: 4
max: 4
err: 0
MEM SNMP_ROOTNODE
avail: 30
used: 21
max: 21
err: 0
MEM SNMP_NODE
avail: 50
used: 30
max: 30
err: 0
MEM SNMP_VARBIND
avail: 10
used: 0
max: 0
err: 0
MEM SNMP_VALUE
avail: 8
used: 0
max: 0
err: 0
MEM PBUF_REF/ROM
avail: 10
used: 0
max: 2
err: 0
MEM PBUF_POOL
avail: 10
used: 11
max: 15
err: 50124
SYS
sem.used: 3
sem.max: 3
sem.err: 0
mutex.used: 0
mutex.max: 0
mutex.err: 0
mbox.used: 3
mbox.max: 3
mbox.err: 878 Есть некоторые вопросы по этой самой статистике: 1) в каких случаях растет счетчик mbox.err: 878 2) как может быть использовано больше пулов чем доступно? Код MEM PBUF_POOL
avail: 10
used: 11
max: 15 Код MEM TCPIP_MSG_INPKT
avail: 8
used: 65530
max: 65535
Сообщение отредактировал IgorKossak - May 12 2017, 08:00
Причина редактирования: [codebox] для длинного кода. [code]-для короткого!!!
|
|
|
|
|
|
|
|
May 12 2017, 05:32
|
Местный
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978
|
да, все так: устраиваю шторм трафика по eth-интерфейсу, при этом срабатывает много-много прерываний. eth-интерфейс при этом виснет. не понимаю, почему стек выделяет больше указанного в настройках стека количества? Код MEM TCPIP_MSG_INPKT
avail: 8
used: 65530
max: 65535
|
|
|
|
|
|
|
|
May 12 2017, 18:09
|
Профессионал
Группа: Свой
Сообщений: 1 215
Регистрация: 22-02-05
Пользователь №: 2 831
|
Цитата(k000858 @ May 12 2017, 08:32)  не понимаю, почему стек выделяет больше указанного в настройках стека количества? Не ломайте голову, а, просто, переходите на статическое создание объектов FreeRTOS, так вы полностью контролируете что, сколько и когда выделяется. Я только поэтому и перелез на эту ось, когда с недавних пор в ней появилась такая возможность. FreeRTOSConfig.h: Цитата #define configSUPPORT_STATIC_ALLOCATION 1
#define configSUPPORT_DYNAMIC_ALLOCATION 0
#define configTOTAL_HEAP_SIZE 0
#define configAPPLICATION_ALLOCATED_HEAP 0
--------------------
Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".
|
|
|
|
|
|
|
|
May 13 2017, 20:34
|
Профессионал
Группа: Свой
Сообщений: 1 032
Регистрация: 13-03-08
Из: Маськва
Пользователь №: 35 877
|
В теме слово lwIP, в сообщениях вывод статистики по lwIP, в ответе - FreeRTOSconfig.h
Forger, Вы вопрос-то читали?
Возвращаясь к нашим утечкам.
Во-первых, мы про какую версию разговариваем? Глянул последнюю, 2.0.2 - там счётчики занятых-свободных объектов - mem_size_t, который тот же size_t, т.е. на ARM'ах явно 32-битный. Гипотеза "счётчик буфера входящих пакетов в один прекрасный момент стал меньше нуля" работает только на 16-битных счётчиках.
Во-вторых, во всё той же версии есть опция проверки утечек памяти - место, которое должно быть свободным, заполняется паттерном, при выделении памяти этот паттерн проверяется. Тормозить будет, конечно, но так только баг быстрее вылезет :-)
--------------------
Тут обсуждается творческий порыв, а не соответствие каким-либо стандартам ©
|
|
|
|
|
|
|
|
May 16 2017, 04:47
|
Местный
Группа: Участник
Сообщений: 319
Регистрация: 31-01-12
Пользователь №: 69 978
|
Цитата(esaulenka @ May 13 2017, 23:34) В теме слово lwIP, в сообщениях вывод статистики по lwIP, в ответе - FreeRTOSconfig.h
Forger, Вы вопрос-то читали?
Возвращаясь к нашим утечкам.
Во-первых, мы про какую версию разговариваем? Глянул последнюю, 2.0.2 - там счётчики занятых-свободных объектов - mem_size_t, который тот же size_t, т.е. на ARM'ах явно 32-битный. Гипотеза "счётчик буфера входящих пакетов в один прекрасный момент стал меньше нуля" работает только на 16-битных счётчиках.
Во-вторых, во всё той же версии есть опция проверки утечек памяти - место, которое должно быть свободным, заполняется паттерном, при выделении памяти этот паттерн проверяется. Тормозить будет, конечно, но так только баг быстрее вылезет :-) Версия 1.4.2. Тип данных счетчиков - u16_t (unsigned short). В каком случае могло так получиться, что счетчик стал отрицательным? Как включаются данные проверочки, быть может они есть и в 1.4.2 версии?
|
|
|
|
|
|
|
|
 May 16 2017, 05:14
|
практикующий тех. волшебник
Группа: Участник
Сообщений: 1 190
Регистрация: 9-09-05
Пользователь №: 8 417
|
Цитата(k000858 @ May 16 2017, 07:47) ...u16_t (unsigned short). В каком случае могло так получиться, что счетчик стал отрицательным?... это всё условности. т.е. то как Вы трактуете. С точки зрения железки - оно тупо два байта. но есть перечень функций языка и команд железки которые будут трактовать это как число со знаком. отсюда ответ: не надо использовать функции языка и команды железки, которые трактуют ваши два байта как число со знаком. кое-что детектируется компилятором на этапе сборки и может вывести предупреждение, в случае типа if (uint16_t > int16_t) в коде так-же может быть явное указание (приведение типа), что дескать далее хочу чтоб это трактовалось ..... При таком раскладе компилятор умывает руки со словами = ну ежели ты сам так хочешь = будь по твоему. удачи вам (круглый)
Сообщение отредактировал kolobok0 - May 16 2017, 05:15
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
