There is significant increase in GPU clock, but no significant increases in CPU and MEM clock. That’s why “max.sh” did not increase significantly bench marks of non-GPU tests, such as DMA tests which use kernel “copy_to_user” function.
The errors are OK to see on Jetson TX1 (I will note this in the script comments). They are there for Jetson TK1 actually, so the script is compatible. TK1 has multiple clusters so there’s cluster/active and TK1 can offline core 0. TX1 needs at least 1 core active because it has 1 cluster.
In the case of “permission denied” you need to run as root (“sudo”). There was mention that the non-existent files/directories are ok to hit because the script is compatible with a TK1.
I don’t know about the specific lines of the script, I’m just commenting about “/sys” in general. Files in “/sys” are not real files, and work instead as communications interface to/from the drivers involved. If the file is marked read-only, then this will be a reason for refusing based on permissions. However, it is up to the driver whether to allow a write to the file…even if file permission is modified a driver coded to not allow a write will still ban a write (or perhaps chmod will fail). There may be cases where drivers have changed over time and on different releases such that a file which was allowed a write on some other platform or software version no longer produce the file, or no longer allow writes to the file. The file permissions are very likely correct to start with.
An example of likely change in behavior or existence of those files would be between a 3.x kernel version and a 4.x kernel version…so if you used R24.2.1 in the past, or if the script was written for this, then many prior versions would also work with that script…future versions (R28.1 and newer) are likely to fail because of major kernel differences. The question becomes “what version of L4T is the script intended to be compatible with”, and “what version of L4T is the script being used with”.
I use to read Jetson/TX1 Controlling Performance - eLinux.org and adapt it to work with L4T 24.2.1. I have recently updated to 28.1.0, and everything is different there. I have never tried the script you mention here on 24.2.1, but I’ve tried it on 28.1.0 and it does not look to do the job.
R28.1 has jetson_clocks.sh in the ~nvidia and ~ubuntu home directories. There is also now “nvpmodel” (in “/usr/sbin/”…see “nvpmodel -h”). “nvpmodel -p --verbose” is a listing of all modes, the one you are probably interested in is:
sudo nvpmodel -m 0
EDIT: I was looking at a TX2 when writing this, and do not have a TX1 connected at the moment…not sure if this all applies to a TX1 on R28.1.
I’m afraid ‘nvpmodel’ is only available on TX2. I don’t find it on TX1. I did not find ‘jetson_clock.sh’ in nvidia and ubuntu homedirs, but I will double check.
(I’ve just seen your post edit, so it matches my observations.)
“jetson_clocks.sh” (plural). This is definitely part of both older and newer TX1 and TX2 installs. Just to see if the install was as expected, does “sha1sum -c /etc/nv_tegra_release” run ok?
Correct, my apologies, I was using a wrong ‘find’ in the rootfs. First test with no arguments just froze my device, and as board (and kernel) is different, I need to investigate first:
# bash -x ./jetson_clocks.sh
…
+ case "${SOCFAMILY}" in
+ GPU_MIN_FREQ=/sys/devices/57000000.gpu/devfreq/57000000.gpu/min_freq
+ GPU_MAX_FREQ=/sys/devices/57000000.gpu/devfreq/57000000.gpu/max_freq
+ GPU_CUR_FREQ=/sys/devices/57000000.gpu/devfreq/57000000.gpu/cur_freq
+ GPU_RAIL_GATE=/sys/devices/57000000.gpu/railgate_enable
+ case "${ACTION}" in
+ echo 0
./jetson_clocks.sh: line 251: echo: write error: Invalid argument
+ cat /sys/devices/57000000.gpu/devfreq/57000000.gpu/max_freq
and then freeze. It seems that I cannot write into ‘/sys/devices/57000000.gpu/railgate_enable’:
My bad, I was using the wrong device. I am able to run ‘./jetson.sh’ without any problem, and the system is not freezing anymore. Sorry for my wrong analysis.
– NicoD