jetson_clock.sh 1 minute delay

I had a question about the ~/jetson_clocks.sh script.

In earlier versions (or perhaps TX1 only) when I would run the script directly after boot-up I would get an error saying that I have to wait X more seconds. Back then I google’d the error and found a reply in this forum from a moderator, seems that there’s a 1 minute delay built in to prevent clocks from being changed after the fact by the OS. I cannot find the thread now, though can search more if somebody wants a reference. I also can dig up the error if somebody doesn’t know what I’m talking about.

I’m not sure if it went away from the switch from TX1 → TX2 or the switch to BSP 28.1 but at some point this error message went away. Now if I run the jetson_clocks.sh script immediately (< 1 minute) after boot-up) I no longer get an error. Does this mean that the 1 minute delay is no longer required? Has this issue been fixed a different way?

Thanks,
Greg

Hi greg2,

Thanks for info. I am going to check it internally.

greg2,

I have confirmed that on rel-28.1, this waiting time is no longer needed. On rel-24.2.1 BSP, there was an ondemand service that will modify clock in 60 seconds. As a result, if you try to write your own clock too early, it is possible being overwritten by that ondemand service.

However, that service is disabled after rel-28.1.

Great to know, it’ll be nice to remove the delay we have in there.
Thanks!

I made a few tests with R28.2 and it seems that the delay of 60 seconds after the boot is still required to set the clocks of the GPU and of the CPUs at the max frequency.

If you run “jetson_clocks.sh” before 60 seconds after the boot you get all the CPUs online, the fan starts to spin, but the clocks remain “ondemand” instead of max performances.

I can measure the difference in ~5 FPS (!!!) in my Computer Vision application (~11.5 FPS to ~16.5 FPS)

Are you able to up clocks earlier if you first do this:

sudo update-rc.d -f ondemand remove

(this was from a long time ago, I don’t know if it still applies)

Yes, it worked. But the problem is not waiting 60 seconds before boosting the TX2, I wonder why in R28.1 you should not wait and in R28.2 you must wait again.

With these differences the better way of working is to wait every time to be sure that boosting is applied…

The ondemand rc script (so far as I know) is entirely from the Ubuntu distribution. I have no idea what other parts of init may also have frequency scaling…but until that stage of boot is reached I would bet it ignores whatever state the Jetson is currently in and does what it was set to do instead of preserving the existing state.

Myzhar,

I didn’t notice this waiting time is back. Let me check and update once I find something.

This is all good to know, look forward to response.

I was not too far away from updating our main TX2 image to R28.2 to cover heartbleed (currently on 28.1). The 60 second timer is a huge issue for us because it is highly expected that the end user will connect to the device within that time frame, in which case it’ll be underperforming.

Myzhar,

May I ask where did you check your frequency? Are you using tegrastats? Could you share what did you see?

In fact, I cannot repro this issue on my device.

Wayne,

I noticed the issue just because I were using tegrastats and I noticed that the 6 clocks were not at maximum value, so I checked using “jetson_clocks.sh --show” and it confirmed that the clocks of GPU and CPUs were not boosted.

So I launched a “sudo ./jetson_clocks.sh” and the clocks boosted immediately showing the increasing of ~5 FPS in my algorithm speed.

To be sure that it was not a momentary issue I rebooted the TX2 and noticed the exactly same problem.

I’m sure that jetson_clocks.sh is executed at boot because I get the fan running just before Unity comes on display.

To be more precise my configuration, I’m using the “jetson_easy” repo by Raffaello Bonghi and “Jetson Performances” is launched at boot as a service.

You can check it here:

Myzhar,

So you didn’t run this script manually but as a service?

Exactly… if I stop the service and restart it I get the boost correctly.

I get the boost correctly also if in the script of the service I introduce the 60" of delay

I’ve tried to run it manually without waiting for 60 second and it looks good.

It looks like the correct error statement for this one is if you run this as a service, it needs to wait 60" delay.

We should understand why… I think that services are launched before “rc.local” and between them there is something that changes governor again to “ondemand”

It may be the dependencies of the services, a race condition. If there is a service changing the governor to “ondemand” the perf service you’re using needs to list it as a dependency so it launches only after it.

If an in-built service sets the initial frequency after the perf one runs, it may undo it.

Yeah, rc.local generally executes after services start, but I don’t think you can necessarily rely on that, like you pointed out with the 60 second wait, I think that will cause execution of the service after rc.local.