But it is ok when I use CLI directly on
the remote.
You should
- ensure that the application launches properly on the target and is suspended there. If the application depends on any environment or shell state to be setup beforehand, this may not happen automatically when launching remotely.
- make sure to use the latest available version of Nsight Compute. It is backwards-compatible with older drivers and toolkits and has many bug fixes.
Thanks, but
I ncu the kernel on remote, and open the Compute on my win10.
The result is on the picture. It just cant attach the process.
Compute version is 2022.3 on Win10.
cuda 11.1 and driver 470+ on remote Linux machine.
So should update the cuda and driver on remote ?
I don’t think you need to update neither CUDA toolkit nor driver. You should check that, since you are attaching to a process launched from the remote target, the relevant ports listed in the output messages are opened between these systems. You can also adjust the ports in the options of the UI and pass them to the CLI as parameters.
You could also try the Remote Launch as an alternative, which should only require your ssh port to be opened for these processes.
:) then I did this “You could also try the Remote Launch as an alternative, which should only require your ssh port to be opened for these processes.”
The Compute is just keeping searching the process.
Thanks. Maybe It is a bug. Instead, I can still ncu -o on remote, download the files, then open them on my host.
As I mentioned before, have you confirmed in the remote launch case (i.e. the last screenshot you shared) that the application is in fact started and waiting on the remote target? Since you have ssh access, that may be easy to check. I am not sure what environment settings it may depend on, so the app behavior itself can differ between local and remote launches.
Is there anything in your SSH configuration that relates to the host you are trying to connect to? E.g., do you have an alias set in your SSH config file by any chance?
Also, do you know if the port range listed in the log (49152 - 49215) can be accessed on the remote machine and aren’t blocked by a firewall?
no alias no firewall. But I notice that the process is started on the remote and soon killed, I’ll check the log to find the reason. Sorry for my poor English :)