Перейти к содержанию
    

LwIP + FeeRTOS: stats

Тестирую устройство на устойчивость от большого количества трафика по Ethernet. При этом в отладку вывожу статистику:

 

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
[codebox] для длинного кода. [code]-для короткого!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2) как может быть использовано больше пулов чем доступно?

 

MEM PBUF_POOL
avail: 10
used: 11
max: 15

Должно быть, между "avail: 10" и "used: 11" произошло прерывание.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

да, все так: устраиваю шторм трафика по eth-интерфейсу, при этом срабатывает много-много прерываний. eth-интерфейс при этом виснет.

 

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

MEM TCPIP_MSG_INPKT
avail: 8
used: 65530
max: 65535

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Я только поэтому и перелез на эту ось, когда с недавних пор в ней появилась такая возможность.

 

FreeRTOSConfig.h:

#define configSUPPORT_STATIC_ALLOCATION 1

#define configSUPPORT_DYNAMIC_ALLOCATION 0

#define configTOTAL_HEAP_SIZE 0

#define configAPPLICATION_ALLOCATED_HEAP 0

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В теме слово lwIP, в сообщениях вывод статистики по lwIP, в ответе - FreeRTOSconfig.h

Forger, Вы вопрос-то читали?

 

 

Возвращаясь к нашим утечкам.

Во-первых, мы про какую версию разговариваем? Глянул последнюю, 2.0.2 - там счётчики занятых-свободных объектов - mem_size_t, который тот же size_t, т.е. на ARM'ах явно 32-битный. Гипотеза "счётчик буфера входящих пакетов в один прекрасный момент стал меньше нуля" работает только на 16-битных счётчиках.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В теме слово 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 версии?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...u16_t (unsigned short). В каком случае могло так получиться, что счетчик стал отрицательным?...

 

 

это всё условности. т.е. то как Вы трактуете. С точки зрения железки - оно тупо два байта. но есть перечень функций языка и команд железки которые будут трактовать это как число со знаком.

 

отсюда ответ:

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

 

кое-что детектируется компилятором на этапе сборки и может вывести предупреждение, в случае типа

 

if (uint16_t > int16_t)

 

в коде так-же может быть явное указание (приведение типа), что дескать далее хочу чтоб это трактовалось .....

При таком раскладе компилятор умывает руки со словами = ну ежели ты сам так хочешь = будь по твоему.

 

удачи вам

(круглый)

Изменено пользователем kolobok0

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...