Posts by Ryan Ludwig

1) Message boards : Number crunching : New Docker image with Virtualbox and Nvidia GPU passthrough support (Message 102924)
Posted 12 Oct 2021 by Profile Ryan Ludwig
P.S. This docker image could potentially also run on Windows, right?

Yes. Windows 11, for example, completely supports Docker and also the access to gpu from the virtual machine (Cuda on WSL, AMD on WLS, etc)

My fault.
Also Windows 10 (from 1809 release) supports Docker and "gpu acceleration" on WSL2

I didn't know this! Interesting... My build likely will not work in Windows docker containers as Microsoft threw some dependencies in the prebuilt image they are using. Hence the "The container base image must be or newer."

I don't have much experience with windows docker deploys but I can look into creating a custom build to suit that use case!
2) Message boards : Number crunching : New Docker image with Virtualbox and Nvidia GPU passthrough support (Message 102923)
Posted 12 Oct 2021 by Profile Ryan Ludwig
Good question! Unfortunately nothing that exciting.

Containers are a great way to rapidly deploy BOINC with all needed dependencies out to your systems. Though by default they have no access to low level devices on the host. This makes containerizing BOINC a bit tricky as you want to A) standardize the BOINC rollout without B) Artificially limiting the type of WU's you can complete.

This is a docker image build that lets you run a containerized BOINC instance without limiting the WU's you are able to complete due to running BOINC within said container.

I threw a README in the git repo. But essentially the setup process for a fresh debian system is...

1. Install base nvidia drivers on host
2. reboot
3. Install nvidia-container-toolkit, virtualbox-dkms, virtualbox
4. reboot
5. clone repo, cd into repo, run docker build
6. Run image (example Run commands in git repo)

You can seamlessly migrate over from a bare-metal BOINC install by modifying the RUN command (Step #6).

Requirements for migration (unsure about Windows, this again may only apply to Linux)
1. Suspend current WU's and completely stop the existing BOINC client. (eg. systemctl stop boinc-client)
2. In the RUN command
--a) point the volume (-v /path/to...) to your existing BOINC data directory
--b) (optional) modify the hostname to match your existing BOINC hostname. <-- This may not work as it will conflict with the host. Regardless I've found that there's some unique identifier in the BOINC data directory as projects transferred over my host average + total credit even though the hostname changed.

Once the build is vetted to work on other systems (IDK about windows and what exactly it allows you to passthrough) I'll create images so you no don't need to build the image yourself and can instead pull directly from :)

I also have docker build files for AMD's ROCM and the generic Intel OpenCL runtimes. Both work and have completed WU's on WCG. Still working on getting repo's setup for them.[/list]
3) Message boards : Number crunching : New Docker image with Virtualbox and Nvidia GPU passthrough support (Message 102915)
Posted 10 Oct 2021 by Profile Ryan Ludwig
Hey R@H fam!

I've been playing around with docker and have created a docker build file that passes through virtualbox and an Nvidia GPU from the host to the container

My PCs (Host: Ubuntu 20.04) running this have been successfully completing the python vbox project WUs along with GPUGrid acemd CUDA WUs so at some level this does work.

I would love any suggestions at improving it from anyone here!
4) Message boards : Number crunching : Should Rosetta Limit the amount of tasks queued per PC? (Message 100179)
Posted 27 Dec 2020 by Profile Ryan Ludwig
Basically the title. I noticed I got an influx of tasks that had all timed out from the same Computer ID.

This users PC has an 8 thread i7 processor with (as it currently stands at the time of writing this) 397 Tasks in progress and 425 Errors (All "Not started by deadline" of course, because that's a crazy amount for one PC with 8 threads, haha)

It doesn't appear that there's any hard and fast boundary to how many work units can be queued for a single computer? Would it possibly make sense to limit the amount of Queued work on a per PC basis by (at the very least) saying you can only queue up some TBD multiple of your thread count?

eg. I have 8 threads, and Rosetta has a threadCount-to-tasksQueued multiple of 10. So for that PC the max I can queue up for Rosetta is 80 tasks before the server refuses to assign me any more

This might help server load and overall project efficiency as this would prevent more novice BOINC users from inadvertently pulling down tasks that they have a zero percent chance of touching before the deadline.

©2022 University of Washington