Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
|
Hey Michael and John, Thanks to both of you for pointing me to startd_cron! I will give this a try! Bet, Jens From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
On Behalf Of Michael Pelletier Hey Jens, That’s just what the startd_cron system is for: STARTD_CRON_JOBLIST = $(STARTD_CRON_JOBLIST) loginsessions STARTD_CRON_LOGINSESSIONS_EXECUTABLE = $(SITE_LIBEXEC)/condor_loginsessions STARTD_CRON_LOGINSESSIONS_MODE = Periodic STARTD_CRON_LOGINSESSIONS_PERIOD = 5m STARTD_CRON_LOGINSESSIONS_KILL = True STARTD_CRON_AUTOPUBLISH = If_Changed STARTD_CRON_LOGINSESSIONS_RECONFIG_RERUN = True The “condor_loginsessions” script generates the following output: $ /usr/local/condor/libexec/condor_loginsessions LoginSessions = 2 -- $ That attribute is added to the machine ad. Michael V. Pelletier From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Jens Schmaler Ok, I will try this. Could you maybe give me a pointer/example of what would be the recommended way to do something like this? E.g. how to make HTCondor regularly
run some external tool and update a machine ad based on the result, etc. Thanks a lot, Jens From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
On Behalf Of John M Knoeller Yes, that should work. From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Jens Schmaler Regarding the gpu_monitor: I could imagine that, in the meantime, I could script something (based on nvidia-smi for example) that regularly updates the machine ad
with the current GPU usage. Would you agree? And what would be the best way to do something like that? Thanks and best regards, Jens From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
On Behalf Of John M Knoeller > Regarding the gpu_monitor: I assume there is a reason why this is not built on Windows? Is there a fundamental limitation of the OS or will this be activated in
one of the next versions? Not a limitation of the OS that I’m aware of, it’s just a matter of changing the code to build for Windows as well as LINUX. We plan on doing that work as part of the 8.9 series.
>
In my case, condor_gpu_discovery reports CUDADriverVersion=10.0, but fails to detect the run time version since it fails to access the registry key I mentioned (see condor_gpu_discovery.cpp, line 386). That code is a backstop for situations when cudart.dll does not load. Did you try adding the cuda runtime to the path? -tj From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Jens Schmaler Hi, In my case, condor_gpu_discovery reports CUDADriverVersion=10.0, but fails to detect the run time version since it fails to access the registry key I mentioned (see
condor_gpu_discovery.cpp, line 386). This key is not present in any of our systems, although we definitely have a working installation of CUDA 10. What else do I need to install to make it work? Regarding the gpu_monitor: I assume there is a reason why this is not built on Windows? Is there a fundamental limitation of the OS or will this be activated in one
of the next versions? Thanks and best regards, Jens From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
On Behalf Of John M Knoeller condor_gpu_discovery does not access any registry keys. it just loads cudart.dll or nvcuda.dll and calls functions from those DLLs. If the registry is being accessed, it is by those DLLs, so you would need to refer to the documentation from NVIDA about registry keys. What does condor_gpu_discovery report as your driver version and runtime version? The value that condor_gpu_discovery reports comes from these dlls. If the value is wrong, it is because your version of the CUDA libraries is incompatible with programs built with older versions of their SDK. We are looking in to what it would take to make
our gpu_discovery work with CUDA 10 without breaking backward compatibility, but so far we do not have a solution for this problem.
As for the gpu_monitor, this tool is currently only being built on LINUX, the documentation needs to be updated to reflect that. -tj From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Michael Pelletier I think ran into this same problem with CUDA 10.0 in a recent 8.6 release, and I think it had something to do with a change to the interface between the 9.x and 10.0 CUDA libraries. It was giving some really
off-the-wall numbers to the collector. I believe there’s a ticket open for the issue as a result of my inquiry to support. In the meantime, you can also install the 9.2 release, and then set up the library path for condor_gpu_discovery to refer to /usr/local/cuda-9.2 instead of /usr/local/cuda, and that should get you through until
they come out with an update for CUDA 10 support. Michael V. Pelletier From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Jens Schmaler Dear all, we are using HTCondor 8.8 on Windows (Win 10 and Win 2016 specifically) with CUDA 10.0 installed. Some systems do have large GPUs, e.g. with 12 GB or even 32 GB of
memory. Nevertheless, condor_gpu_discovery will only show a maximum of Besides that, I discovered that condor_gpu_discovery tries to access the registry key
"SOFTWARE\\NVIDIA Corporation\\GPU Computing Toolkit\\CUDA" which does not seem to exist on any of our systems. Could you please tell me under which circumstances you would expect this key to exist? Thanks a lot, Jens |