Cannot enable denver cores for TX2 (Jetpack 4.4 DP)

Thank you very much,

I did enabled the two denver cores several months ago after your kind assistance.

We test the performance then, the performance did not take any improvement. The reason maybe that the 4 ARM cores are enough for our algoithm, while the ability of GPU being the limitation. Thus, the additional two denver cores are redundant even though they took the majority of the cpu calculations.

We would try to add more loads on the cpu in order to see if the optimization for cpu scheduling is problematic or it is the power management who limited the performance of the two denver cores.

Finally, thank you for your patience and the Nvidia team supports.

Kind wishes,

ZHU Yijun

Hello all,

Actually, it seems that lots of bugs appeared on the Jetpack 4.4 DP, but I found that the performance of cuda 10 .2 is much better than that on hte Jetpack 4.3. The cusparse became much more faster.

If you have some other caracteristics found to improve the calculation performance, please remind me. Thank you all.

Kind Regards,

ZHU Yijun

It worked for you on the DP, however there were some changes since then that appears to render this fix unusable.

Per the other thread. It appears your fix is temporary and is undone after a normal update.

I know this will be a bit of a pain, but if you get this set up working again, and then go to do an update, perhaps you could log the update. Then, if the problem comes back, there will be a list of packages triggering the issue. For example:

sudo apt update
sudo apt-get upgrade 2>&1 | tee log_upgrade.txt

ok carolyuu. There is something in /etc/apt/sources.list.d/nvidia-l4t-apt-source.list that undoes the ā€œCONFIRMED ITā€™S WORKINGā€ once updated.

Mark as a bug and notify when fixed.

Hi,
We have confirmed the issue is not seen on Jetpack 4,4 GA with the steps

Not sure but you probably have -r in the flash command. If you have -r, please remove it and try again.

DaneLLL,

I understand you ā€œconfirmedā€ it, however I havenā€™t seen you respond to the fact that the cores are disabled after an update.

Iā€™m willing to try again, but I need to see that you have done this and an update.

This is what it looks like when I lock /etc/apt/sources.list.d/nvidia-l4t-apt-source.list after your fix. Looks good right?
before

unlock it and do an update. BOOOM. dead cores.
after

This is not fixed and if I see CONFIRMED typed one more time Iā€™m going to throw something through my monitor.

Hi,
Thanks for information. We will execute sudo apt update and check again.

and upgrade and reboot.

Hi carolyuu,

I have the same problem and want to enable denver cores in jetpack 4.4 dp.
I am new to jetson and I am a little confused. Would you please let me know where the Linux_for_Tegra folder is?

Many thanks

Itā€™s on your host machine that you flashed 4.4 with. However, I would not bother as it will return to 4 core state after an update. Wait for a fix or flash 4.3.

1 Like

Thanks!
So I should reflash my jetson? Is there any way to enable denver cores on flashed jetpack?

4.4 is completely broke on the TX2 until further notice. You can reflash 4.3.

1 Like

Hi,
Please check 5.16 Increased Kernel Launch Latency on Denver 2 Cores in release notes of r32.4.3.
Due to the concern, we disable Denver cores by default. For leveraging Denver cores, please execute sudo nvpmodel -m 0 and taskset:
https://man7.org/linux/man-pages/man1/taskset.1.html
For using core #1, please set 0x2:

$ taskset 0x2 <_USER_APPLICATION_> &

For using core #2, please set 0x4:

$ taskset 0x4 <_USER_APPLICATION_> &

We have worked out a solution. Please check this comment.

1 Like

Hi DaneLL

thankā€™s for your reply .
your link is not working.

Laurent

Hi,

Please go to

And click Release Notes.

Is NVIDIA going to fix the latency issue with the Denver cores?
OR
Is the plan to leave them disabled by default as it is for all future JetPack releases and force customers to make the described change if they want to run processes on the Denver cores?

1 Like

Hi,

We have seen performance deviation between Denver cores and ARM cores in MAXN mode, triggering certain issues in benchmark. With further investigation, a better solution for now is to let tasks be scheduled to ARM cores. For leveraging Denver cores, would need to manually schedule it through taskset. From r32.4.3, this is the default mode for TX2.

so the fix is to kill 1/3 of the processors?