I’ve just created a simple systemd service to automatically start jetson_clocks on boot. but it does not work unless I include a delay of greater than 60 seconds. Why is this?
Hi,
Is the issue observed if you immediately execute sudo jetson_clocks once booting to Ubuntu desktop? Or only happens if you run it in a system service?
Nothing happens when I run it in the systemd service without the 60+ seconds delay. Using jtop (uses tegrastats) I can see that the clock speeds on cpu and gpu have not increased.
I don’t care about the delay as I have a working solution. The point of this post is to simply ask why it needs a delay. If there is no reason and it’s just something weird with my nano the it can be closed.
Just speculation: If “/sys” is not yet mounted, or if the other CPU cores are not yet enabled (it starts with only CPU0), then it wouldn’t be possible (yet) to interact with non-CPU0 cores in any way.
Hi,
r28 releases are with Ubuntu 16.04 and we have a patch to disable CPU ondemand service. r32 releases are with Ubuntu 18.04 and probably the way of setting CPU ondemand is changed and the patch does not take effect. We will check this.Thanks for raising it up.
You need to start jetson_clocks after nvpmodel service. The GPU devfreq nodes are emulated only after nvpmodel service. The jetson_clocks would fail if CPU/GPU devfreq nodes are not present.