CPU Frequency vs FreeRTOS

[teckhaokoh]

Hi,

I've tried to printf the system ticks using gettimeofday.
And I found that the differences between 2 printf for the gettimeofday are around 2-3 ms.

My printf result as below, in ns:
ets_get_cpu_frequency : 240
before gettick : 884583000
after gettick : 887201000

As I set the CPU frequency to be 240MHz, why the processing speed seems to be in kHz?
I printf direct inside the app_main(), and the 2 lines of "gettick" are the continuous 2 lines of codes.

2-3ms for these 2 lines of codes seems to be very slow for a 240MHz processors (dual core) right?

Any idea what's wrong with it?
My FreeRTOS configuration issue?

[ESP_igrr]

Can you post your exact code?

Here's what i tried:

Code: Select all

static inline uint64_t timeval_to_usec(struct timeval* tv)
{
    return 1000000LL * tv->tv_sec + tv->tv_usec;
}

void app_main()
{
    struct timeval tv1, tv2;
    gettimeofday(&tv1, NULL);
    gettimeofday(&tv2, NULL);
    uint64_t t1 = timeval_to_usec(&tv1);
    uint64_t t2 = timeval_to_usec(&tv2);
    printf("t1=%lld t2=%lld t2-t1=%lld\r\n", t1, t2, t2 - t1);
}

The result was:
t1=2066004 t2=2066070 t2-t1=66

That's 66 microseconds between gettimeofday calls, which looks reasonable, given that gettimeofday needs to take a mutex and do some 64-bit math.

[teckhaokoh]

Oh, thanks for showing your codes....
That's the part that I'm checking in the wrong way.
I take the gettimeofday in the printf, and I think printf itself need quite some process cycles, right?

Below is how I printf the previous result I got.
"printf("before gettick : %lld\n",getTicks());"


In fact, I'm trying to create a very big switch...case (around 230+ cases) task, which running infinite loop to do some works for me continuously, in a task.
It may involve quite busy udp socket transactions (when i'm connecting in and request some data) at the same time, while the loop is running.

Should I put the task in a priority higher or lower than the WIFI?
I've pinned the task to cpu1, and it still seems to be running slower than expected.
I did the same application running using esp8266 before, and it seems to be slower in esp32.

[Ritesh]

Hi,

I've tried to printf the system ticks using gettimeofday.
And I found that the differences between 2 printf for the gettimeofday are around 2-3 ms.

My printf result as below, in ns:
ets_get_cpu_frequency : 240
before gettick : 884583000
after gettick : 887201000

As I set the CPU frequency to be 240MHz, why the processing speed seems to be in kHz?
I printf direct inside the app_main(), and the 2 lines of "gettick" are the continuous 2 lines of codes.

2-3ms for these 2 lines of codes seems to be very slow for a 240MHz processors (dual core) right?

Any idea what's wrong with it?
My FreeRTOS configuration issue?

Hi,

I have checked same thing in my code and getting 16 to 20 usec difference between 2 consecutive gettimeofday calls. So, Please check below code snippet which I am using.

Code: Select all

struct timeval tv_start, tv_stop;
	float time_sec;
	ESP_LOGI(TAG,"****** Inside while loop ********\r\n");
	
	gettimeofday(&tv_start, NULL);
	gettimeofday(&tv_stop, NULL);
	ESP_LOGI(TAG,"time differece: %ld usec\n", ((tv_stop.tv_usec) - ((tv_start.tv_usec))));

If possible then send me your code snipet and .config file settings in which you have did configurations using make menuconfig command which might be helpful to see your issue.

[ESP_igrr]

Should I put the task in a priority higher or lower than the WIFI?

If your task is the producer and TCP/IP stack is the consumer, you should not make your task priority higher than that of the TCP/IP task, which is 18. If you make it higher, you have a chance of flooding TCP/IP stack with UDP packets.

I've pinned the task to cpu1, and it still seems to be running slower than expected.
I did the same application running using esp8266 before, and it seems to be slower in esp32.

Unfortunately without more specifics i can't help you with this... We are working on a profiling tool which will make such cases easier to analyze, but it is not ready for release yet. If you can isolate the thing that runs slower on ESP32 than on ESP8266 to a small example, then that would help figuring out the cause.

Note though, there are also cases when same code will run on ESP32 slower than on the ESP8266, if they are clocked at the same frequency.

[Ritesh]

Should I put the task in a priority higher or lower than the WIFI?

If your task is the producer and TCP/IP stack is the consumer, you should not make your task priority higher than that of the TCP/IP task, which is 18. If you make it higher, you have a chance of flooding TCP/IP stack with UDP packets.

I've pinned the task to cpu1, and it still seems to be running slower than expected.
I did the same application running using esp8266 before, and it seems to be slower in esp32.

Unfortunately without more specifics i can't help you with this... We are working on a profiling tool which will make such cases easier to analyze, but it is not ready for release yet. If you can isolate the thing that runs slower on ESP32 than on ESP8266 to a small example, then that would help figuring out the cause.

Note though, there are also cases when same code will run on ESP32 slower than on the ESP8266, if they are clocked at the same frequency.

Hi,

I have one quick question for you that is there any plan to provide API support like to check Task is running into CPU0 or CPU1 core is anyone has used xTaskCreate API to create task?

Also one more thing that by-default WiFi Stack is running into CPU0 and we can execute FreeRTOS Stack on CPU0 using make menuconfiguration. correct? SO, If I have selected FreeRTOS running stack into CPU0 and still I can create Task into CPU1 using xTaskCreatePinedToCore API. correct?

[ESP_igrr]

I have one quick question for you that is there any plan to provide API support like to check Task is running into CPU0 or CPU1 core is anyone has used xTaskCreate API to create task?

No, but it should be possible to add a member to TaskStatus_t indicating task affinity, and extend uxTaskGetSystemState function to set this member. Please feel free to submit such a change as a PR on Github, or open a feature request there.

Also one more thing that by-default WiFi Stack is running into CPU0 and we can execute FreeRTOS Stack on CPU0 using make menuconfiguration. correct? SO, If I have selected FreeRTOS running stack into CPU0 and still I can create Task into CPU1 using xTaskCreatePinedToCore API. correct?

No, that's not correct. Menuconfig option you are referring to allows to run FreeRTOS scheduler either on one CPU, or on both CPUs.
If FreeRTOS runs only on PRO CPU, then APP CPU is clock gated and held in reset. In this case all tasks in the system run on PRO CPU.
If FreeRTOS runs on both CPUs, then each task will have affinity determined when the task is being created. You may create tasks pinned to CPU 0, you may create tasks pinned to CPU1, and you may create non-pinned tasks which may be scheduled on any CPU.

With regards to WiFi stack, it contains multiple tasks, and currently there is no way of pinning these tasks based on user choice. Whether WiFi stack tasks are pinned or not pinned isn't specified, and may change in the future. We are open to feature requests though, and may consider adding some kind of configuration for WiFi stack tasks affinity.

[Ritesh]

I have one quick question for you that is there any plan to provide API support like to check Task is running into CPU0 or CPU1 core is anyone has used xTaskCreate API to create task?

No, but it should be possible to add a member to TaskStatus_t indicating task affinity, and extend uxTaskGetSystemState function to set this member. Please feel free to submit such a change as a PR on Github, or open a feature request t

Also one more thing that by-default WiFi Stack is running into CPU0 and we can execute FreeRTOS Stack on CPU0 using make menuconfiguration. correct? SO, If I have selected FreeRTOS running stack into CPU0 and still I can create Task into CPU1 using xTaskCreatePinedToCore API. correct?

No, that's not correct. Menuconfig option you are referring to allows to run FreeRTOS scheduler either on one CPU, or on both CPUs.
If FreeRTOS runs only on PRO CPU, then APP CPU is clock gated and held in reset. In this case all tasks in the system run on PRO CPU.
If FreeRTOS runs on both CPUs, then each task will have affinity determined when the task is being created. You may create tasks pinned to CPU 0, you may create tasks pinned to CPU1, and you may create non-pinned tasks which may be scheduled on any CPU.

With regards to WiFi stack, it contains multiple tasks, and currently there is no way of pinning these tasks based on user choice. Whether WiFi stack tasks are pinned or not pinned isn't specified, and may change in the future. We are open to feature requests though, and may consider adding some kind of configuration for WiFi stack tasks affinity.

Hi,

Thanks for quick Reply.

Can you please tell me how to submit PR on GitHub for this type of changes Request?

[ken2004]

I'm wondering how

With regards to WiFi stack, it contains multiple tasks, and currently there is no way of pinning these tasks based on user choice. Whether WiFi stack tasks are pinned or not pinned isn't specified, and may change in the future. We are open to feature requests though, and may consider adding some kind of configuration for WiFi stack tasks affinity.

in this thread fits with:

In dual core mode, if your pin your task to the APP CPU, there won't be any problems for wifi stack, because all WiFi stack tasks are supposed to run only on PRO CPU. In this case, your task can hog all the CPU time it needs.

from an earlier thread. I can think of several possibilities.

[ESP_Sprite]

Pretty simple: in general, it's not specified where the WiFi tasks will run, but in the current incarnation of esp-idf, they only run on CPU0. Because that is not in the official specs, however, this behaviour may change (or become configurable) if we see advantages to it.