Самые высокие показатели CPU в симуляции Contiki Cooja Sky mote снижаются
Мои Энергетические оценки энергии не имеют смысла в симуляции Куджи небесного мотылька. Я хочу зачитать значения CPU, TX и RX до и после шифрования и передачи данных из одного мотка в другой. Показания общего процессора сначала увеличиваются, но после нескольких раундов снова внезапно уменьшаются. Насколько я понимаю, они не сбрасываются, а отображают общее количество кликов. Поэтому я вычитаю старые значения из текущих значений, чтобы отобразить потребление каждого периода.
energest_init();
printf("Ticks per second: %u\n", RTIMER_SECOND);
while(1) {
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&periodic_timer));
etimer_reset(&periodic_timer);
etimer_set(&send_timer, SEND_TIME);
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&send_timer));
addr = servreg_hack_lookup(SERVICE_ID);
if(addr != NULL) {
powertrace_getold();
//here happens what I want to track
powertrace_print("");
} else {
printf("Service %d not found\n", SERVICE_ID);
}
}
здесь самые энергичные функции я называю
void powertrace_getold(void){
energest_flush();
last_cpu = energest_type_time(ENERGEST_TYPE_CPU);
last_lpm = energest_type_time(ENERGEST_TYPE_LPM);
last_transmit = energest_type_time(ENERGEST_TYPE_TRANSMIT);
last_listen = energest_type_time(ENERGEST_TYPE_LISTEN);
}
/*---------------------------------------------------------------------------*/
void
powertrace_print(char *str)
{
uint32_t cpu, lpm, transmit, listen;
uint32_t all_cpu, all_lpm, all_transmit, all_listen;
static uint32_t seqno;
energest_flush();
seqno++;
all_cpu = energest_type_time(ENERGEST_TYPE_CPU);
all_lpm = energest_type_time(ENERGEST_TYPE_LPM);
all_transmit = energest_type_time(ENERGEST_TYPE_TRANSMIT);
all_listen = energest_type_time(ENERGEST_TYPE_LISTEN);
cpu = all_cpu - last_cpu;
lpm = all_lpm - last_lpm;
transmit = all_transmit - last_transmit;
listen = all_listen - last_listen;
printf("SQ:%d AllCPU:%lu AllLPM:%lu AllTX:%lu AllLST:%lu\n",seqno, all_cpu,all_lpm,all_transmit,all_listen);
printf("SQ:%d CPU:%lu LPM:%lu TX:%lu LST:%lu\n",seqno,cpu,lpm,transmit,listen);
}
Вот некоторый вывод:
SQ:1 AllCPU:1186791424 AllLPM:756219905 AllTX:1756561462 AllLST:1931870208
SQ:1 CPU:93716480 LPM:93716480 TX:93650944 LST:93650944
SQ:2 AllCPU:3010854912 AllLPM:3091398657 AllTX:2625110086 AllLST:2710700032
SQ:2 CPU:93716480 LPM:93716480 TX:93782016 LST:93716480
SQ:3 AllCPU:4026073088 AllLPM:2875260929 AllTX:2958426201 AllLST:3292790784
SQ:3 CPU:97386496 LPM:97320960 TX:97320960 LST:1703936
SQ:4 AllCPU:2539323392 AllLPM:2459107330 AllTX:3841982587 AllLST:123666432
SQ:4 CPU:97320960 LPM:97320960 TX:97320960 LST:1703936
SQ:5 AllCPU:194379776 AllLPM:3890544643 AllTX:4187422878 AllLST:1273561088
SQ:5 CPU:93782016 LPM:93782016 TX:93782016 LST:93716480
SQ:6 AllCPU:1199505408 AllLPM:2522808323 AllTX:183107761 AllLST:1925709825
SQ:6 CPU:93978624 LPM:93913088 TX:93913088 LST:93978624
Как видите, значения не складываются. Что мне не хватает? ENERGEST_ON/OFF тоже ничего не меняет.
1 ответ
Вы определяете all_cpu
, all_lpm
, all_transmit
, а также all_listen
как 32-разрядные целые числа без знака. 32-разрядное целое число без знака может содержать только значения до 232-1. Если вы посмотрите на последовательность всех тактов процессора (1186791424
, 3010854912
, 4026073088
,...) ты это видишь 4026073088
довольно близко к 232-1 (4294967295
), поэтому неудивительно, что следующее печатное значение (2539323392
) меньше этого - переменная переполнена.
Чтобы решить это, вы можете:
- Храните галочки в
uint64_t
вместоuint32_t
, - Уменьшите количество тиков в секунду - но в Sky это зависит от аппаратного обеспечения, поэтому это будет нетривиально.
- Обнаружьте переполнение и учтите их позже: например, обратите внимание на каждый раз, когда счетчик уменьшился, и сохраните счетчик переполнения в отдельной переменной. Вероятно, вы можете сделать это на этапе постобработки при анализе журналов - вам просто нужно убедиться, что счетчики печатаются достаточно часто, так что между каждым вызовом может быть не более одного переполнения.
powertrace_print()
,