i have a question regarding the power modes of the Jetson Xavier NX Module. Currently i am working with an AGX Xavier DevKit in MAXN Mode, which gives a nice performance. According to Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation, the Jetson NX does not offer such a mode, but instead just different 15/10W modes that all result in drawbacks regarding cpu speed / nr of cpu cores and so on.
Is it possible to get the full performance (full frequency for GPU, DLA, Mem, CPU, all cpu cores active) for the NX, for example by defining a custom power mode? Or what is the reason why there is no predefined MAXN Mode as compared to the AGX?
Yes, NX does not have MAXN.
This is hardware design limitation. You could check the module datasheet and notice the difference between NX and AGX Xavier.
Thank you for your fast response.
One question still remains, if i understand the l4t guide correctly (link posted above) i can define custom power modes for both AGX and NX, with the limitation of “The frequencies you select are subject to the MaxN limit defined in mode 0”.
In NX there is no MAXN Mode and the 15W is due to hardware design limitation. What happens if i then define a custom mode that e.g. activates all 6 cpu cores with a higher frequency than 1400Hz (NX, mode 2), therefore possibly exceeding the limitations? I couldn’t find helpful information on that topic in the data sheet.
The electrical /thermal and quality test of NX are all based on 10 and 15W mode. I guess you could still enable them by defining the power modes. But we cannot guarantee the behavior and quality of NX then.
You might be able to get all six cores at 1.9 GHz and maintain 15W power budget actually but only as long as you make savings in other components and say don’t use GPU too much.
On the devkit, I’ve been playing with the clocks (for my own needs - which is to see how it performs as a console emulator and push it above the limits :) ) and did some power benchmarks (using jtop from jetson_stats, you can install it tools by “pip install jetson-stats” and then run “sudo jtop”) and was observing “CPU GPU CV” power consumption:
- When OC’ing all 6 cores to 2.49 GHz and stressing them, while keeping the GPU idle, “CPU GPU CV” would show between 15-16W current power usage and fan would spin around 78% and there was no throttling (room temperature etc.).
- When OC’ing all 6 cores to 2.49 GHz, GPU to 1.6 GHz and stressing both (used Doom 3 BFG to stress the GPU) the peak power usage would jump to between 25 - 28W, fan is on 100% and I see some thermal throttling (losing around 100 - 200 MHz on the CPUs / GPUs).
- Tried to run Doom 3 BFG with OC’d settings. That would end up stressing GPU (@ 1.6 GHz) but not so much the CPUs and I’d see power usage around 15 W.
In a nutshell, you could define your custom power profile and tailor it to your needs; however in that case I suggest you verify the actual power consumption by monitoring the “CPU GPU CV” rail and make sure you stay within the power budget.
We are also looking at OC’ing the NX. However, we are not sure how you got past the 15W limit? We have set the critical current limit from 3.6A to 5.0A (as shown here) and also defined a custom power mode following your previous post: 6 cores to 2.49 GHz, GPU to 1.6 GHz. However, we don’t seem to be witnessing the same performance gains as you did.
Would it be possible for you to share the exact procedure on how you boosted performance, would it be possible for you to share your custom profile settings? Are there any other settings you need to change to push past the 15W limit, if so which ones?
Thank you very much for your help!
I’ve applied patches in the BPMP firmware to go past the stock frequencies (think at the on Jetpack 4.4 you’d not get the overcurrent limit or I disabled it in BPMP as well, don’t remember now). Without patching BPMP you can enable all 6 cores but will be only on 1.9 GHz.
The frequencies (or max freq.) are defined in the BPMP device tree and are relatively simple to edit by hand. That said I was primarily experimenting above with OC rather than running some real stress testing.