Zephyr benchmark in NRF5340DK

[Victor Lima de Souza]

I'm currently working on a project where I need to assess the power handling capability of my NRF5340-DK board using different scheduling algorithms. For this purpose, I've chosen to utilize the Zephyr benchmark scheduler (tests/benchmarks/sched/).

However, upon executing the benchmark on the NRF5340-DK board, I encountered a peculiar issue. The output obtained is quite different from what I expected based on previous experiences with a different board.

On the reference board, the output resembled the following pattern:

unpend 275 ready 381 switch 905 pend 1006 tot 2567 (avg 2567)
unpend 275 ready 381 switch 905 pend 1006 tot 2567 (avg 2567)
unpend 275 ready 381 switch 905 pend 1006 tot 2567 (avg 2567)
unpend 275 ready 381 switch 905 pend 1006 tot 2567 (avg 2567)

finCode

But on the NRF5340-DK board, the output deviates significantly:

unpend 1 ready 0 switch 0 pend 0 tot 1 (avg 0)
unpend 0 ready 0 switch 0 pend 0 tot 0 (avg 0)
unpend 0 ready 0 switch 1 pend 0 tot 1 (avg 0)
unpend 1 ready 0 switch 0 pend 0 tot 1 (avg 0)
unpend 0 ready 0 switch 0 pend 1 tot 1 (avg 0)
finCode

It seems that the benchmark is resetting the threads on the NRF5340-DK board, causing the total count (tot) to remain at 1 throughout the entire execution.

Could this behavior be attributed to some form of performance optimization specific to the Nordic board?

[Hieu]

Hi Victor Lima,

I will need some time to investigate this. I will follow up with you by the end of this week.

Hieu

[Victor Lima de Souza]

Ok. Much obliged.

[Hieu]

I looked into the sample, and it looks like the sample is running correctly.

The issue is that the sample is designed to timestamp how many cycles there are between scheduling events.
On the nRF5340 (and nRF52s), this cycle count is sourced from RTC1, which runs at 32768Hz. This resolution is not enough to capture meaningful data for something as fast as the scheduler.

I cannot comment about the other MCU you tested with, and I don't know your goal for this evaluation. However, I assume you want to have a meaningful comparison. For that you will need to reimplement the application so that the timestamps are based on something more universal, such as microseconds.

On the nRF5340, you could set up a TIMER peripheral at maximum speed (16MHz) for this purpose. Again, I cannot comment for the other MCU.