This thread is to allow discussion of the following (locked) FAQ thread,

How to - install Ubuntu 16.04 x64 Linux & setup for GPUGrid

Post here about Ubuntu 16.04-x64 LTS installation and configuration.
Create a new thread for other distros, please.

I think, this is the more appropriate thread for the discussion I started over in COOLBITS as LUBUNTU and LINUX MINT are UBUNTU derivates.

My computer with the LUBUNTU 16.04 64-bit installation runs great for over 2 weeks now.

I installed LINUX MINT 18 64-bit on the computer with LINUX MINT 17.3 32-bit previously. Beside that the video card is too old to run GPUGRID, everything works very smooth.

So, I would like to say, that it is quite easy to use Linux for crunching with Nvidia GPUs since the UBUNTU 16.04 LTS release.

THANK YOU so much for doing this.

Would you recommend a USB 3.0 drive, or is a 2.0 drive sufficient?

If you use the USB-stick for installation on a Hard Disk it is not so important if you use USB 2.0 or 3.0, although the latter is noticeable faster during installation or running LINUX from the USB-stick (The start-up process is much slower on the USB 2.0).

However I do recommend that you use an USB-stick of at least 16 GB for installation only and 32 GB if you like to run LINUX Mint from the stick itself. The best thing is to use a spare/cheap one, as I have burned several in the process, but I am not a computer or Linux specialist at all.

I always used Multiboot Yumi http://www.pendrivelinux.com/yumi-multiboot-usb-creator for the primary installation and then installed the LINUX Distro to second destination from there to either USB-stick or the Hard Disk.

If you use the USB-stick for installation on a Hard Disk it is not so important if you use USB 2.0 or 3.0, although the latter is noticeable faster during installation or running LINUX from the USB-stick (The start-up process is much slower on the USB 2.0).

However I do recommend that you use an USB-stick of at least 16 GB for installation only and 32 GB if you like to run LINUX Mint from the stick itself.

My intention was to cover a basic/standard installation to an internal drive, rather than an external USB stick to create a multi-boot environment.
Overall, I found the OS and NV driver installations very easy but that might not be the case if you need to multi-boot &/or boot to a USB stick.

In your case I don't know what's going wrong, but you may need to select the drive you are booting to when you restart or remove the other USB drive (assuming you are installing the OS from one USB stick onto the other)?

I've been slowly moving my DC machines to Ubuntu 16.04 LTS. There's been some trials along the way but I was able to search for answers. The only problem I have not been able to solve is getting the Boinc manager to connect to the boinc client again. It was working fine until I did a sudo service boinc-client restart command in a terminal. After that the manager is shown as disconnected and it will not reconnect even after a restart or a complete power down and restart. I think it may have something to do with the client_state.xml file. The is no ip addy listed but when I edit the file and add one it doesn't stick. When I restart boinc it's empty again. When I check that file on other Linux hosts it shows the ip 127.0.0.1. On my lone windows host it shows the assigned ip addy I gave it (192.168.1.xx). Have no idea what else to try and asking for help @ askubuntu.com has resulted in no responses.

The only problem I have not been able to solve is getting the Boinc manager to connect to the boinc client again.

nanoprobe,

Never saw the issue that you have, but here are some ideas that might help.

Start up System Monitor and see if the boinc client is running. The Process Name will be "boinc" and the User will be "boinc".

Try restarting the boinc client with this command: "sudo /etc/init.d/boinc-client restart". Then restart the boinc manager and see if it connects.

If it is still not connected, from the boinc manager, from the menu bar at the top of the window, click on "File", then "Select computer...". A small window will open up asking for host name and password. In the host name box, try "localhost" (without the quotes) no password and see if that connects. If that doesn't work, try host name "127.0.0.1:31416" (without the quotes) and no password.

If none of that gets you going, how did you install BOINC?

The only problem I have not been able to solve is getting the Boinc manager to connect to the boinc client again.

This is the issue I've always had with BOINC in Ubuntu. I've never been able to get it working because the Manager and the Client don't seem to want to talk to each other.

nanoprobe,

Never saw the issue that you have, but here are some ideas that might help.

Start up System Monitor and see if the boinc client is running. The Process Name will be "boinc" and the User will be "boinc".

Try restarting the boinc client with this command: "sudo /etc/init.d/boinc-client restart". Then restart the boinc manager and see if it connects.

If it is still not connected, from the boinc manager, from the menu bar at the top of the window, click on "File", then "Select computer...". A small window will open up asking for host name and password. In the host name box, try "localhost" (without the quotes) no password and see if that connects. If that doesn't work, try host name "127.0.0.1:31416" (without the quotes) and no password.

If none of that gets you going, how did you install BOINC?

The only problem I have not been able to solve is getting the Boinc manager to connect to the boinc client again.

This is the issue I've always had with BOINC in Ubuntu. I've never been able to get it working because the Manager and the Client don't seem to want to talk to each other.

I have had this problem on every BOINC installation I have done in Ubuntu 16.04 on four machines.

The solution is:
Copy "gui_rpc_auth.cfg" from the /etc/boinc-client folder to the home directory and reboot to allow BM to connect.

Since you are only reading from the /etc/boinc-client it should work, but if you have a permission problem let me know. Why they did not get this right to begin with is beyond me, but I am new to Ubuntu myself and don't know what worked before.

I copied the gui_rpc_auth.cfg from the /etc/boinc-client folder but I was not able to paste it into the home directory. The paste option was greyed out which means I have a permissions issue. Did a lot of searching and tried some terminal commands but have not found an answer yet.

I copied the gui_rpc_auth.cfg from the /etc/boinc-client folder but I was not able to paste it into the home directory. The paste option was greyed out which means I have a permissions issue. Did a lot of searching and tried some terminal commands but have not found an answer yet.

Here is a more complete list of what I do to allow access to /etc/boinc-client.

Note that I copy a modified "gui_rpc_auth.cfg" into that folder, but you may not need to modify it. Also, it allows for creating (or changing) a "cc_config.xml" file, if you need to do that. I also use a "remote_hosts.cfg" file to allow access over the LAN, but you may not need it.

I have also included the commands to allow access to /var/lib/boinc-client, where the project folders are located. You will need that to copy an "app_config.xml" file into the GPUGrid project folder, for example.

-> Just replace "user_name" with you actual user name.

Join the root group: sudo adduser user_name root
Join the BOINC group: sudo adduser user_name boinc

Allow group to read, write and execute in /etc/boinc-client folder: sudo chmod -R g+rwx /etc/boinc-client
Allow group to read, write and execute in /var/lib/boinc-client: sudo chmod -R g+rwx /var/lib/boinc-client
Reboot

Copy “gui_rpc_auth.cfg” to /etc/boinc-client folder
Copy “remote_hosts.cfg” to /etc/boinc-client folder
Copy “cc_config.xml” to /etc/boinc-client folder
Copy "gui_rpc_auth.cfg" to the home directory
Reboot

Copy the "app_config.xml" files to the project folders in /var/lib/boinc/

For someone who claims to be new at Linux you fixed something I've searching for weeks. Where did you come up with the info?
Thanks again.
David

Each distribution/version of Linux has different features, terminal commands and add ons which makes it almost as difficult moving from one distribution to another as it is to move from Windows to Linux. However, Ubuntu 6.04-x64 is a Long Term Support distro, so it's something you can stick with for longer. While the command lines might have changed somewhat, again, the GUI updates (via the Ubuntu Sortware icon and Sortware & Updates in System Settings) are encouraging.
At present 6.04-x64 LTS works for GPUGrid crunching due to the driver support for GTX900 series GPU's. The question at the back of my mind is will it support NV's GTX1000 series GPU's?

http://www.omgubuntu.co.uk/2016/06/top-5-terminal-commands

http://manpages.ubuntu.com/manpages/xenial/man8/

When I first installed 16.04 I was using a 750Ti and I installed the 361 driver from the repository. When I tried to install my 1060 I couldn't get it to boot. I put the 750 back in and started searching. The 367.27 driver is needed for the 10xx cards. I also found it helped me to install synaptic package manager first.
I used the following commands to get started with the video drivers.

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install nvidia-367 nvidia-settings

I then reinstalled the 1060 and it booted but there were still some issues. Installing the 367 driver did not install the needed OpenCl or CUDA libraries. I used synaptic package manager to install them. Now we're almost done.

Add the unprivileged boinc account to the video group

sudo usermod -a -G video boinc

Move BOINC start-up to the end of the start-up processing.

sudo update-rc.d -f boinc-client remove
sudo update-rc.d boinc-client defaults 99

Without nvidia-modprobe installed boinc will not find the GPU

sudo apt-get install nvidia-modprobe <-- when I did this I found that it was already installed YMMV

sudo modprobe nvidia_uvm

sudo service boinc-client restart

That's it but in some cases a reboot is needed. Hope this will help someone. My 1060 now happily runs POEM and Einstein. Patiently waiting for support here
You can find more driver info here.

I have a setup running


Boinc 7.6.31
GenuineIntel Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz [Family 6 Model 60 Stepping 3]
(8 processors) [2] NVIDIA GeForce GTX 780 (3052MB) driver: 375.20 Linux
4.4.0-21-generic 25 Nov 2016 | 16:44:32 UTC


I was doing an upgrade from Linux Mint 17.3 (ubuntu 14.04) to 18 (ubuntu 16.04) ,
I did test the 375.20 drivers with both versions. however to get the latest boinc client I had to get to mint 18.

Basic approach - your milage may vary :)

sudo apt-get purge nvidia*

Note - Once you reboot here you have to do the next steps from the Console as it will not boot into X
sudo reboot

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo
apt-get update

sudo apt-get install nvidia-375 nvidia-settings libcuda1-375

sudo apt-get install boinc 7.6


I found these sites usefull -
http://askubuntu.com/questions/757080/why-is-it-so-hard-to-install-nvidia-drivers-what-is-the-most-fool-proof-method
https://sites.google.com/site/easylinuxtipsproject/12

Here is what appears to be the relevent packages - there may be more - these are the ones I touched during the upgrades

paz@stealth-mint ~ $ sudo dpkg -l | grep -i nvidia
[sudo] password for paz:
rc libcuda1-331 331.113-0ubuntu0.0.4 amd64 NVIDIA CUDA runtime library
rc libcuda1-346 346.22-0ubuntu1~xedgers14.04.1 amd64 NVIDIA CUDA runtime library
rc libcuda1-349 349.16-0ubuntu0~xedgers14.04.1 amd64 NVIDIA CUDA runtime library
ii libcuda1-375 375.20-0ubuntu0~gpu16.04.1 amd64 NVIDIA CUDA runtime library
ii nvidia-375 375.20-0ubuntu0~gpu16.04.1 amd64 NVIDIA binary driver - version 375.20
ii nvidia-settings 375.20-0ubuntu0~gpu16.04.1 amd64 Tool for configuring the NVIDIA graphics driver

paz@stealth-mint ~ $ uname -a
Linux stealth-mint 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

paz@stealth-mint ~ $ sudo dpkg -l | grep -i boinc
ii boinc 7.6.31+dfsg-6ubuntu1 all metapackage for the BOINC client and the manager
ii boinc-client 7.6.31+dfsg-6ubuntu1 amd64 core client for the BOINC distributed computing infrastructure
ii boinc-manager 7.6.31+dfsg-6ubuntu1 amd64 GUI to control and monitor the BOINC core client
ii libboinc7:amd64 7.6.31+dfsg-6ubuntu1 amd64 libraries of BOINC the client depends on

paz@stealth-mint ~ $

UBUNTU 18.04 LTS
BOINC 7.9.3
NVIDIA driver 390.77
GPU 980 TI

How configure driver and BOINC, to reach 100% GPU load ?

GPU load about 30% 60%
T° 79° speed fan 50%
____________

I am not familiar with Linux, but to me it seems that there may be some GPU throtteling due to the high temperature (79° - which, running constantly, is definitely not good for the lifetime of the card).

UBUNTU 18.04 LTS
BOINC 7.9.3
NVIDIA driver 390.77
GPU 980 TI

How configure driver and BOINC, to reach 100% GPU load ?

GPU load about 30% 60%
T° 79° speed fan 50%

UBUNTU 18.04 LTS
BOINC 7.9.3
NVIDIA driver 390.77
GPU 980 TI

How configure driver and BOINC, to reach 100% GPU load ?

GPU load about 30% 60%

T° 79° speed fan 50%

UBUNTU 18.04 LTS
BOINC 7.9.3
NVIDIA driver 390.77
GPU 980 TI

How configure driver and BOINC, to reach 100% GPU load ?

GPU load about 30% 60%
T° 79° speed fan 50%

I use a windows laptop that runs BOINC Tasks to control the crunchers but also have the manager on the desktop of each cruncher.

My GTX 750 Ti on a SuSE Leap 15.0 Linux and an Opteron 1210 CPU runs at 57 C, GPU clock 1137 MHz, memory clock 2700 MHz. Driver is 390.87.
Tullio

Yes, all the Nvidia cards down/up clock in 12 Mhz bins for every 5 degrees decrease/increase in temps. I think the temp where the card doesn't hit the thermal binning point is somewhere around 54°C. At that point it will run at max clocks. All my EVGA Hybrid cards always run at max clocks since they are always cooler than 54°C. The only card that even gets close or rarely goes past that point is the GTX 1080Ti in the summer. So the cooler you can run the card, the higher the clocks it will maintain.

I run multiple projects on the cards but only 1 gpu task at a time. So any card at any time might have a Seti, MilkyWay, Einstein or GPUGrid task on it. Yet any time I look at nvidia-smi I always see all cards always at 95 - 100% utilization.

With Ryzen or TR, try and keep cpu utilization below 75% to allow enough cpu support for the gpu tasks.

You can't use the SWAN_SYNC environmental variable under Linux to dedicate a CPU thread for the GPUGrid app to increase GPU usage.
(It works only under Windows.)

You can't use the SWAN_SYNC environmental variable under Linux to dedicate a CPU thread for the GPUGrid app to increase GPU usage.
(It works only under Windows.)

Maybe you can explain why I have one host that is able to run all GPUGrid tasks with SPIN synchronization. All my other hosts run with BLOCKING.

All the hosts have identical hardware for mobo, cpu and memory. The only differences are in the mix of Nvidia gpus each host has.

All the hosts run Ubuntu 18.04 with Nvidia 410.66 drivers.

So how is this host any different than the others? https://www.gpugrid.net/show_host_detail.php?hostid=456812

The only obvious difference is this host has three identical 1070Ti's and the other hosts have a mix of 1070/1070Ti/1080/1080TI cards in each host.

I've been asked a couple times now how I managed this feat. I don't have a clue.

Well mystery solved after reading your history of threads regarding swan_sync. I believe that host 456812 was the first host I brought up on Linux and the project.

Seems I somewhere in the past put the SWAN_SYNC=1 entry into the /etc/environment file.

I assume that is the reason that host has been running tasks with the SPIN synchronization parameter.

Even though everyone said their attempt with the same entry never worked, I wonder if the reason it works with my hosts is that I don't use the repository versions of BOINC.

I use a specially Seti@home user compiled version 7.4.44 with settings allowing 3000 tasks on board and also the developer compiles it on much older distributions for compatibility. I believe he makes it compatible with distribution as old as 12.04.

Anyway, I am now modifying the environment file for the other hosts and see whether they too start running in SPIN synch.

So I experimented and now have changed to SWAN_SYNC=1 on all my hosts. I ran overnight on the odd BOINC 7.8.3 host to make sure that it wasn't just the BOINC 7.4.44 that was able to use the SWAN_SYNC environment variable. I have the tasks now marked with SPIN synchronization too and the cpu_times equal the run_times so I used 100% of a cpu core to support the gpu task. Looks like I shaved 30-60 minutes of the typical PABLO task.

So I experimented and now have changed to SWAN_SYNC=1 on all my hosts. I ran overnight on the odd BOINC 7.8.3 host to make sure that it wasn't just the BOINC 7.4.44 that was able to use the SWAN_SYNC environment variable. I have the tasks now marked with SPIN synchronization too and the cpu_times equal the run_times so I used 100% of a cpu core to support the gpu task. Looks like I shaved 30-60 minutes of the typical PABLO task.

It's fairly easy. Question is whether the version of BOINC manager you are using will allow you to use it.

Keith and I both run a BM that was compiled by one of the Seti Gurus.

First thing is to unhide your files. In the right upper corner you should have a button to see files, you want to click show hidden files.

Once you do that, open files. Find your computer, click on it. Find the etc folder, click on that and then locate the environment file. Check it with texteditor. Might say something with "games" in the name. All you are doing is looking at it. Then close the file

move mouse over the open etc folder and right click and open the terminal.

Next get to root, so

"sudo su"

hit return then it will ask you to enter your password

you should be at root

"sudo nano environment"

Now you can edit the environment file

Add the

"SWAN_SYNC=1"

then control o to write, hit enter. You have now overwritten that file

control x to exit the edit

close terminal.

now using textedit, recheck to see if the edit took. If it did then you should be good.

I don't think you need to reboot. That should be it. I've tested it on one of my system and it works.

Edit..

Ok, reboot then. I always reboot anytime I do anything to a computer. Thanks Keith.
____________

So I experimented and now have changed to SWAN_SYNC=1 on all my hosts. I ran overnight on the odd BOINC 7.8.3 host to make sure that it wasn't just the BOINC 7.4.44 that was able to use the SWAN_SYNC environment variable. I have the tasks now marked with SPIN synchronization too and the cpu_times equal the run_times so I used 100% of a cpu core to support the gpu task. Looks like I shaved 30-60 minutes of the typical PABLO task.

I don't think you need to reboot. That should be it. I've tested it on one of my system and it works.

So I experimented and now have changed to SWAN_SYNC=1 on all my hosts. I ran overnight on the odd BOINC 7.8.3 host to make sure that it wasn't just the BOINC 7.4.44 that was able to use the SWAN_SYNC environment variable. I have the tasks now marked with SPIN synchronization too and the cpu_times equal the run_times so I used 100% of a cpu core to support the gpu task. Looks like I shaved 30-60 minutes of the typical PABLO task.

Did the tasks change w/in the past day or have you not been getting the 24hr bonus? All your tasks are worth 73k, 92k or 120k. I had mainly been getting 110k and 180k credit tasks. I was hoping to compare vs my 1070 running 2x tasks at once but want to make sure I compare proper task length.

I would appreciate those attempting the SWAN_SYNC=1 parameter in their environment file on repository versions of BOINC to report success or not. You can check if the parameter took or not with a

OK merci beaucoup pour vos commentaires.
Je test pour vous dire si c'est bon.

OK thank you very much for your comments.
I test to tell you if it is good.

SWAN_SYNC=1
99% CORE CPU
GPU FAN Setting 60%
GPU load 60 to 90%
T° 77° to 82%

____________

Alain, that was with repository BOINC version 7.9.3. Correct?

Keith Myers asked:

I would appreciate those attempting the SWAN_SYNC=1 parameter in their environment file on repository versions of BOINC to report success or not.

Did you logoff or reboot to enable the parameter to be read?
[Edit] Also any task started before the parameter was set already has the old BLOCKING parameter written into the header in the slot. So only tasks started after the parameter was set will have the new SPIN synchronization set in the stderr.txt output.

Now you can edit the environment file

Add the

"SWAN_SYNC=1"

Just drop down to a new line below the PATH statement. And just put in SWAN_SYNC=1. No quotes. But is does have to be capitalized since Linux cares about upper/lower case in names.

Keith asked:

Did you logoff or reboot to enable the parameter to be read?
[Edit] Also any task started before the parameter was set already has the old BLOCKING parameter written into the header in the slot. So only tasks started after the parameter was set will have the new SPIN synchronization set in the stderr.txt output.

Keith asked:

Did you logoff or reboot to enable the parameter to be read?
[Edit] Also any task started before the parameter was set already has the old BLOCKING parameter written into the header in the slot. So only tasks started after the parameter was set will have the new SPIN synchronization set in the stderr.txt output.

The PC was rebooted and the GPU tasks started after the reboot. You should be able to see my computers, the computer that I am testing is named Sledgehammer if you want to look.

Question for you, does the version of BOINC that you are using run under your id or the id of "boinc" or other? You probably know that the repository version of BOINC runs under the id of "boinc".

.

So either your higher level of BOINC is the issue or their is something different in your system compared to the 3 successful cases so far.

Of course I have no proof, since PM's leave no record, but I'm positive he said his gpu is running at 100%, thus he has a full cpu feeding it.

I wont get a chance to try this solution for another 6 hours, but...

If you check host id: 153837 and 423329. (both belong to same user, [not me])

Both running Boinc client 7.8.3 and have been using SPIN since at least 21st October (possibly longer)

Alain, that was with repository BOINC version 7.9.3. Correct?

Alain, that was with repository BOINC version 7.9.3. Correct?

Yes 7.9.3 version.

# CUDA Synchronisation mode: BLOCKING
# SWAN Device 0 :
# Name : GeForce GTX 980 Ti
# ECC : Disabled
# Global mem : 6075MB
# Capability : 5.2
# PCI ID : 0000:42:00.0
# Device clock : 1076MHz
# Memory clock : 3505MHz
# Memory width : 384bit
# GPU [GeForce GTX 980 Ti] Platform [Linux] Rev [3212] VERSION [80]
# SWAN Device 0 :
# Name : GeForce GTX 980 Ti
# ECC : Disabled
# Global mem : 6075MB
# Capability : 5.2
# PCI ID : 0000:42:00.0
# Device clock : 1076MHz
# Memory clock : 3505MHz
# Memory width : 384bit
# Time per step (avg over 6560722 steps): 3.356 ms
# Approximate elapsed time for entire WU: 33555.639 s
# PERFORMANCE: 24566 Natoms 3.356 ns/day 0.000 ms/step 3.356 us/step/atom
06:41:38 (8543): called boinc_finish
# CUDA Synchronisation mode: BLOCKING
# SWAN Device 0 :

Hello, I followed the instructions and typed "printenv SWAN_SYNC" and it returned with 1. Below are my tasks from last night but it appears not to have synced the CPU time with the overall time. This computer's BOINC version is 7.6.31.

http://www.gpugrid.net/results.php?hostid=490728

Same thing here. printenv SWAN_SYNC returns a 1 now, but still showing Blocking on the WUs from overnight.

http://www.gpugrid.net//results.php?hostid=48715
(WUs completed on 31 Oct all started after SWAN_SYNC=1)

Boinc 7.9.3 from Linux Mint Software Manager.

(Thank you to Keith and Zalster for trying to figure this out.)

ALAIN's second work unit returned also with BLOCKING still in the stderr. So it is not picking up the SWAN_SYNC=1

Thanks to everyone who is reporting back with their results.

I think it maybe necessary to use the BOINC Manager version compiled by TBar at crunchers anonymous in order to get it to work properly.


http://www.arkayn.us/lunatics/BOINC-7.8.3.7z

The default of the BM is set to connect to Seti@home but you can always add GPUGrid as a project and then delete the Seti@home folder.
____________

OK, yes I agree with Zalster's assessment now too. It looks like only the TBar BOINC versions is able to run with SWAN_SYNC=1 and have it applied to the tasks.

To add to just the link that Zalster posted, I thought the full post describing the steps necessary to run TBar's BOINC versions.

The Latest version of BOINC for Testing in Linux. You should check the Dependencies and Execute bits before running. This version should work in Ubuntu 12.04 and above by installing libwebkitgtk from the Package Manager, however, Mint users should probably use the repository version of BOINC .

This version has Fixed the BOINC Manager Tasks view problem that resulted in the view being focused on the bottom of the Tasks page, and Simple View works. If you have an existing BOINC folder in your Home folder expand the download to your Downloads folder, and Stop all boinc Apps. Open the download, Copy the files and Paste them into your existing BOINC folder in Home. Double click boincmgr to launch the Manager.

To expand the file in Linux you need to have 7zip installed, in the terminal;
To install 7zip run, sudo apt-get install p7zip
To install libwebkitgtk run, sudo apt-get install libwebkitgtk-1.0-0

To install libwebkitgtk run, sudo apt-get install libwebkitgtk-1.0-0

Yes, you should just drop the trailing zero.

I wont get a chance to try this solution for another 6 hours, but...

If you check host id: 153837 and 423329. (both belong to same user, [not me])

Both running Boinc client 7.8.3 and have been using SPIN since at least 21st October (possibly longer)

I've managed the BOINC client (installed from the repo) to notice the SWAN_SYNC=1 parameter (in /etc/environment).
(BTW it has to be spelled with all caps to work.)
By default the BOINC client runs under the account called 'boinc', as a daemon (system service).
When it runs this way, it won't regard the environment settings in /etc/environment.
So I stopped the BOINC daemon by opening a terminal and elevating it with

Thanks for the update. I had a hunch the issue with the repository version was because of the account "boinc" permissions preventing the system wide environment variable not being picked up.

The TBar BOINC versions avoid this issue since both the client and Manager are installed and run under the user account.

Thank you and trying now.

Is there a way to manage via another manager, like BAM, while in this state?

You should still be able to control the client with the boinccmd tool.
Controlling_BOINC_remotely

As far as using another manager, you could install Wine and then install BoincTasks to manage the client.

I found BoincTasks indispensable when I was running Windows, so the first thing I did after moving to Linux was to investigate whether BoincTasks would run under Linux. It does, quite well in fact. So I have Wine installed on my daily driver that I sit in front of 8 hours of the day and I control and monitor my 4 other hosts from that chair without having to get out of it and sit in front of the other hosts to interact with them.

BoincTasks, TThrottle

I am running SuSE Leap 15.0 on two Linux hosts. BOINC 7.8.3 is given to me by SuSE. One is running QC only, no graphic board, the other both QC and acemd on its GTX 750 Ti, CUDA 80, BLOCKED parameter.
Tullio

We think it doesn't matter what the BOINC version is . . . if it comes from a repository and is installed as a daemon with the user 'boinc', it is not going to allow the SWAN_SYNC=1 parameter to be enabled on gpu tasks.

Only the Seti user developed BOINC versions which are installed in /home with the user the owner use the parameter correctly.

Retvari Zoltan has figured out a method around the repository versions but without Manager control of the client.

ALAIN's second work unit returned also with BLOCKING still in the stderr. So it is not picking up the SWAN_SYNC=1

Thanks to everyone who is reporting back with their results.

I think it maybe necessary to use the BOINC Manager version compiled by TBar at crunchers anonymous in order to get it to work properly.


http://www.arkayn.us/lunatics/BOINC-7.8.3.7z

The default of the BM is set to connect to Seti@home but you can always add GPUGrid as a project and then delete the Seti@home folder.

My workaround in my previous post is just a temporary solution (it's fine for me for the time being).
To completely solve this issue we should:
1. change the owner of /var/lib/boinc-client to the user (I know how to do that, but it's pointless if I can't do the next steps).
2. change the user account under which the boinc daemon starts. There should be a Linux configuration file containing this setting, which I haven't found yet (it's not enough to change the BOINC_USER in /etc/default/boinc-client and in /etc/init.d/boinc-client)
3. the user should have the right to start a daemon (at least in Windows it works that way).

I have successfully automated the start of boinc client.

It does weaken the security of the installed boinc package so use at your own risk!!

in the service control file /lib/systemd/system/boinc-client.service:
Under [service] heading, make this the first line
Environment="SWAN_SYNC=1"

Under [service] heading, change User=boinc to:
User=root (this is the line that weakens security)
EDIT: as per testing by Retvari Zoltan, this line does not need to be changed. It can stay as User=boinc (and hence not compromise security). Thanks Retvari Zoltan

You do not need to add SWAN_SYNC=1 to the /etc/environment file as a service creates it's own environment(my understanding)

reboot. (easiest way to implement)

run top in a terminal (or your favourite GUI task manager) to check acemd process is using 100% of cpu

Success! I did the steps recommended by Retvari Zoltan and then also installed Wine and BoincTasks (thank you Keith Myers) in order to have a manager (which installed very nicely and automatically 'synced up' with the running Boinc Client).

As implied by Zoltan's follow-up post, I did realize I had to leave the terminal open with the root-level Boinc Client running.

Overnight, my PABLO WUs processed about 8 percent faster.

http://www.gpugrid.net//results.php?hostid=487152

Looks like more ideas flowing here -- I will wait until this evening to set up my second host and see what else is discovered.

in the service control file /lib/systemd/system/boinc-client.service:
Under [service] heading, make this the first line
Environment="SWAN_SYNC=1"

Under [service] heading, change User=boinc to:
User=root (this is the line that weakens the security)

Thanks for the feedback, will reset
User=boinc as you suggested!

Zoltan, now that you've tried all of the potential solutions, what do you think is the easiest, safest, and most fool proof?

Zoltan, now that you've tried all of the potential solutions, what do you think is the easiest, safest, and most fool proof?

Thanks for the feedback, will reset
User=boinc as you suggested!

I am running both python and acemd as user tullio, so I have almost the whole 1 TB disk available to BOINC 7.8.3.
Tullio

Success! I did the steps recommended by Retvari Zoltan and then also installed Wine and BoincTasks (thank you Keith Myers) in order to have a manager (which installed very nicely and automatically 'synced up' with the running Boinc Client).

As implied by Zoltan's follow-up post, I did realize I had to leave the terminal open with the root-level Boinc Client running.

Overnight, my PABLO WUs processed about 8 percent faster.

http://www.gpugrid.net//results.php?hostid=487152

Looks like more ideas flowing here -- I will wait until this evening to set up my second host and see what else is discovered.

Retvari Zoltan wrote:

"My tasks that are started as 'root' won't continue after I've started the BOINC manager as 'boinc', so don't be surprised if you have to manage this (aborting the task, or deleting the files from the slot as 'root')."

First, thank you for pursuing the great Linux/Boinc SWAN_SYNC mystery to completion -- I really appreciate it.

Next, on one of my hosts I did the 'run-BOINC-as-root' thing before the final answer. Based on your post quoted above, I might have some difficulty switching back to 'normal' Boinc manager. Do you have a recommendation on how to do it with minimal pain? (I also installed BoincTasks, so I do have a manager running.)

Thank you for any help on this.

You can do it with minimal pain by waiting for the tasks run out on the GPUGrid servers (or you can set the BOINC manager not to request new tasks from the GPUGrid project) and when the GPUGrid tasks run out on your host you can switch back to run BOINC daemon as 'boinc'.

UBUNTU 18.04 LTS
BOINC 7.9.3
NVIDIA driver 390.77
GPU 980 TI

How configure driver and BOINC, to reach 100% GPU load ?

You can't use the SWAN_SYNC environmental variable under Linux to dedicate a CPU thread for the GPUGrid app to increase GPU usage.
(It works only under Windows.)
BTW the GPUGrid app can't reach 100% GPU usage. The maximum is about 95% (under Windows XP with SWAN_SYNC on).

I think it's relatively accepted that the Linux scheduler is smarter than the Windows one. Probably the difference.

Don't be surprised if the power dissipation (i.e. the temperature and the fan speed) of your GPU(s) increase (about as much as its speed increases) after you apply the SWAN_SYNC=1.