Advanced search

Message boards : Wish list : SWAN_SYNC in Linux client

Author Message
Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50180 - Posted: 31 Jul 2018 | 20:58:40 UTC

I'm convinced that the lack of "SWAN_SYNC" in the Linux client is hindering this project.
In the near future (when faster GPUs will arrive) this performance loss will increase.
To prove it to you, I have set up an experiment consisting of two almost identical configurations:

#1 #2 CPU: i7-4790K @ 4.4GHz i3-4160 @ 3.6GHz, M/B: Gigabyte GA-Z87X-OC MB ASUS B85M-G RAM: 2x4GB DDR3 1866MHz 2x4GB DDR3 1333MHz GPU: Gigabyte GTX 980Ti WF3OC Zotac GTX 980Ti AMP CLK: 1315MHz, v384.13 1354MHz, v359.6 OS: Linux (Ubuntu 14.04 LTS) Windows XP x64, SWAN_SYNC ON
No CPU tasks were running on these hosts during the test.

Tasklists: #1: Linux and #2: WinXPx64 with SWAN_SYNC ON
Note that until 29 July the Linux client had a GTX 1080Ti, which was about as fast as a GTX 980Ti in my Windows XP x64 host.

Here are the test results so far:
-- run time -- Workunit batch credits #atoms #1 #2 ADRIA_FOLDT1019s2_v2_predicted_pred_ss_contacts_50_T1019s2 63,300 11,269 10,117 8,236 ADRIA_FOLDT1015_v2_predicted_pred_ss_contacts_50_T1015s1 63,300 11,184 10,200 8,210 ADRIA_FOLDUCB_NTL9_50_crystal_crystal_ucb_50_ntl9 63,750 11,340 11,000 8,410 PABLO_2IDP_P10275_1_ALAP23W_IDP 110,400 24,609 12,747 ----- PABLO_2IDP_P01106_1_ALAP26W_IDP 110,400 24,591 ------ 9,441 PABLO_2IDP_P01106_1_ASNP3P_IDP 110,400 24,469 12,692 ----- PABLO_2IDP_P10275_1_ARGP27P_IDP 110,400 24,577 ------ 9,426 PABLO_2IDP_P10275_1_ALAP23Y_IDP 110,400 24,639 11,970 ----- PABLO_2IDP_P01106_2_ARGP7P_IDP 110,400 24,593 ------ 9,433 PABLO_2IDP_P01106_1_ALAP26P_IDP 110,400 24,596 12,008 ----- PABLO_2IDP_P61244_0_ARGP38P_IDP 110,400 24,481 ------ 9,457

The Windows XP x64 client with SWAN_SYNC ON is faster than the Linux client by 19-31% which is pretty high to ignore.
(I've Normalized the percentage calculation by the GPU clock ratio of the two hosts: the GPU in the Windows XP x64 host is 3% faster)
It is a myth that Linux does not need SWAN_SYNC.
So I urge the GPUGrid staff to put the SWAN_SYNC option back in the Linux client, and publish how to make it work.
It should be easy, as the Linux client puts the following line in its output:
# CUDA Synchronisation mode: BLOCKING
If it's more convenient, there could be two Linux app: the present one, and anonther with SWAN_SYNC ON. The user could select in his/her profile the preferred one. The default should be the present one (without SWAN_SYNC).

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50181 - Posted: 31 Jul 2018 | 21:14:02 UTC - in response to Message 50180.

That is a very nice comparison, and it certainly would be nice to give SWAN_SYNC in Linux a try.

But:

Note that until 29 July the Linux client had a GTX 1080Ti, which was about as fast as a GTX 980Ti in my Windows XP x64 host.

This seems a little strange. The 1080Ti in Linux should easily beat the 980Ti in WinXP, unless it is somehow being limited. Maybe there is a memory or bus limitation of some sort?

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50182 - Posted: 31 Jul 2018 | 21:23:21 UTC - in response to Message 50181.

That is a very nice comparison, and it certainly would be nice to give SWAN_SYNC in Linux a try.

But:
Note that until 29 July the Linux client had a GTX 1080Ti, which was about as fast as a GTX 980Ti in my Windows XP x64 host.

This seems a little strange. The 1080Ti in Linux should easily beat the 980Ti in WinXP, unless it is somehow being limited. Maybe there is a memory or bus limitation of some sort?
There's no such limitation:
1. The iGPU is off
2. The NVidia GPU runs at PCIe3.0x16
3. The (CPU) memory is running in dual channel mode
4. No CPU tasks are running
The only thing missing is SWAN_SYNC

I can swap the OS between the two hosts, but there's no point in it.

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50183 - Posted: 1 Aug 2018 | 1:18:34 UTC - in response to Message 50182.

It is probably the memory bus on the cards themselves that is the limitation. The GTX 980 Ti has 384 bits, while the GTX 1080 Ti has only 352 bits. While the memory on the 1080 Ti is faster, there is probably not much difference in bandwidth, which is probably what is limiting the performance of the 1080 Ti.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50184 - Posted: 1 Aug 2018 | 5:35:55 UTC - in response to Message 50183.

It is probably the memory bus on the cards themselves that is the limitation. The GTX 980 Ti has 384 bits, while the GTX 1080 Ti has only 352 bits. While the memory on the 1080 Ti is faster, there is probably not much difference in bandwidth, which is probably what is limiting the performance of the 1080 Ti.
This is nonsense to put a lower bandwidth memory to a faster GPU.
The NVidia homepage is a little inconsistent (or I should call erratic) by the definition of Memory Bandwidth, (which is simply the memory clock multiplied by the bus width in bits divided by 8 to convert it to bytes).
GTX 980 Ti Memory Specs: Memory Clock 7.01 Gbps Standard Memory Config 6 GB Memory Interface GDDR5 Memory Interface Width 384-bit Memory Bandwidth (GB/sec) 336.5
7.01*384/8=336.48 GigaByte/sec

GTX 1080 Ti Memory Specs: Standard Memory Config 11 GB GDDR5X Memory Interface Width 352-bit Memory Bandwidth (GB/sec) 11 Gbps
11*352/8=484 GigaByte/sec

484/336.48=1,4384

So in reality the GTX 1080 Ti has 43,84% more memory bandwidth over the GTX 980 Ti.

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50186 - Posted: 1 Aug 2018 | 10:34:03 UTC - in response to Message 50184.
Last modified: 1 Aug 2018 | 10:49:01 UTC

That may explain the bandwidth, but it just confirms that the GTX 1080 Ti should be faster. I will be interested to see the numbers if they can enable SWAN_SYNC on Linux. Good luck in your effort to jog them on that.

PappaLitto
Send message
Joined: 21 Mar 16
Posts: 427
Credit: 3,125,997,241
RAC: 7,329,652
Level
Arg
Scientific publications
watwat
Message 50187 - Posted: 1 Aug 2018 | 11:01:04 UTC

Correct me if I'm wrong, but I think the main bottleneck for this application for operating systems without SWAN_SYNC is when the data comes over the PCIe BUS from the GPU, it is waiting in system memory for the CPU to do what it needs to do (I assume double precision compute) and send it back to the GPU for GPGPU compute.

With SWAN_SYNC it leaves one thread spun up so there is no delay in the data stream leading to a much more efficient process. As with Zoltan's data, you have up to 2000 seconds of time savings which on a WU is over 20% saved time AND power. The thing about processors is, even if they don't have data to compute, they still use almost the same amount of power when at max clock speed (which our GPUs are.)

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50188 - Posted: 1 Aug 2018 | 13:17:10 UTC - in response to Message 50187.
Last modified: 1 Aug 2018 | 13:40:46 UTC

With SWAN_SYNC it leaves one thread spun up so there is no delay in the data stream leading to a much more efficient process. As with Zoltan's data, you have up to 2000 seconds of time savings which on a WU is over 20% saved time AND power. The thing about processors is, even if they don't have data to compute, they still use almost the same amount of power when at max clock speed (which our GPUs are.)

The only thing that SWAN_SYNC can do is provide more processor support to the GPU. But all the other cores were free in Zoltan's tests anyway, so it is not clear how SWAN_SYNC can improve that. (Maybe locking a given CPU core to the GPU makes it faster?)

PappaLitto
Send message
Joined: 21 Mar 16
Posts: 427
Credit: 3,125,997,241
RAC: 7,329,652
Level
Arg
Scientific publications
watwat
Message 50189 - Posted: 1 Aug 2018 | 14:35:50 UTC - in response to Message 50188.

Locking one thread will provide the least latency. Because the computation replies so much on the latency of the CPU, things like CPU clock speed, PCIe bandwidth, memory speed and operating system optimizations like SWAN_SYNC lower the latency far more than without SWAN_SYNC.

Latency is always the enemy.

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50190 - Posted: 1 Aug 2018 | 15:38:05 UTC - in response to Message 50189.

Maybe. But that says that allowing the OS to chose the right core is worse than locking the GPU to a given core. That might be true when you have multiple CPU projects running. I am not sure it will show up in tests with all the cores free. So I think you will have to test it under varying conditions to see the real effect in practice.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50191 - Posted: 1 Aug 2018 | 17:20:57 UTC - in response to Message 50187.
Last modified: 1 Aug 2018 | 17:26:13 UTC

Correct me if I'm wrong, but I think the main bottleneck for this application for operating systems without SWAN_SYNC is when the data comes over the PCIe BUS from the GPU, it is waiting in system memory
I think the data is waiting in the GPU's memory.
... for the CPU to do what it needs to do (I assume double precision compute)
As far as we know it that's the case
and send it back to the GPU for GPGPU compute.

With SWAN_SYNC it leaves one thread spun up so there is no delay in the data stream leading to a much more efficient process.
Actually without SWAN_SYNC the app gives control back to the OS. When the GPU finished a bit of calculation it gives an interrupt to the OS (signaling it needs attention). This interrupt takes thousands of CPU cycles to process, as the state of the interrupted process should be saved (even if it's the "system idle" process), and the state of the GPUGrid app should be restored to be able to continue from where it gave back control to the OS. With SWAN_SYNC ON this step is obviously omitted so there's much less latency in each step resulting in much faster processing. The faster the GPU the larger the performance loss.
See my old post about the comparison of the two way of processing.

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50192 - Posted: 1 Aug 2018 | 18:35:09 UTC - in response to Message 50191.

I don't have very fast GPUs on at the moment, only a couple of GTX 750 Ti's. But they show 95 to 96% utilization under Linux. I will try out a GTX 1070 if they get SWAN_SYNC enabled, to see more of a difference. It looks promising, but it has been ages since I used it last under Windows.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50213 - Posted: 6 Aug 2018 | 12:11:43 UTC
Last modified: 6 Aug 2018 | 12:14:57 UTC

I've compared the run times of my GTX 1080Tis under different OS.
My host Windows 10 / SWAN_SYNC on is faster by ~2.8% and ~8.6% than my hosts with Linux / SWAN_SYNC off.
Strangely the older Linux host (i3-4360) is faster and takes less CPU time too to process the GPUGrid workunits (the other host has an i3-7300).
BTW the Windows 10 host runs a Rosetta@home CPU task simultaneously, while the Linux hosts run only GPUGrid.
Host 113852: Win10, i7-4930K @ 4.4GHz, 16GB DDR3@1866MHz
Host 391255: Linux (Ubuntu 14.04 LTS), i3-4360 @ 3.7GHz, 4GB DDR3 @ 1333MHz CL6
Host 482653: Linux (Ubuntu 14.04 LTS), i3-7300 @ 4.0GHz, 32GB DDR4 @ 2133MHz

Aurum
Send message
Joined: 12 Jul 17
Posts: 5
Credit: 3,504,141,081
RAC: 55,486,178
Level
Arg
Scientific publications
wat
Message 50471 - Posted: 11 Sep 2018 | 22:14:42 UTC
Last modified: 11 Sep 2018 | 22:19:00 UTC

Very interesting thread. I don't have any answers but an observation. At first I thought those CPUs are different. Linux rig has an i7-4790k with 16 lanes, 4 GHz & 8 MB cache. WinXP rig has an i3-4160 with 16 lanes, 3.6 GHz & 4 MB cache. I've seen where MIP WUs at WCG choke for lack of L3 cache but here smaller cache computer is faster.
I've also seen much discussion of PCIe bus speed at F@H forum. These MBs are very different and the Asus manual is very uninformative. As I understand it, it takes 16 lanes to run the PCIe bus at full 3.0 x16 speed. The Asus manual says 16x and first 1x slots are shared. I assume nothing was plugged into either of the 1x slots. The Asus manual has no block diagram so maybe they use all 16 CPU lanes to run the single 16x slot and do all other bus functions with their B85 chip. Maybe not. GPU-Z can monitor the bus speed on a Windows computer but I don't recall seeing that here.
The GA-Z87X may be the issue. A much better manual with a block diagram shows that only one of the four 16x slots is capable of 3.0 x16 speed and that's if nothing else is plugged in. The Z87 handles the 1x slots and other bus functions. Is there a way with Linux to monitor actual bus speed???
Also, the BIOS usually has a version of an option for the PCIe speed: Auto, Gen 1, Gen 2 or Gen 3. I set all mine to Gen 3 from the default Auto.

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50524 - Posted: 16 Sep 2018 | 16:59:59 UTC - in response to Message 50213.

I've compared the run times of my GTX 1080Tis under different OS.
My host Windows 10 / SWAN_SYNC on is faster by ~2.8% and ~8.6% than my hosts with Linux / SWAN_SYNC off.

This may be the wrong place to ask a Windows 7 64-bit question, but my GTX 970 is running the same time (7 1/2 hours) on a PABLO_2IDP whether I have swan_sync enabled or not. I am using the 373.06 drivers (CUDA 8), which used to be the best ones, but maybe no longer are. What is the current CUDA version I should be using?

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50526 - Posted: 16 Sep 2018 | 22:59:34 UTC - in response to Message 50524.

Well it made a small difference.

With swan_sync, the PABLO_2IDP took 7 hours 13 minutes, and used 99.5% of the CPU.
Without swan_sync, the PABLO_2IDP took 7 hours 40 minutes, but used 60% of the CPU.

I would rather have the CPU. And I don't think drivers would make a difference.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50533 - Posted: 17 Sep 2018 | 19:20:25 UTC - in response to Message 50471.
Last modified: 17 Sep 2018 | 19:37:19 UTC

... I assume nothing was plugged into either of the 1x slots.
True. I build single GPU hosts to maximize the performance of the GPUGrid app.

The Asus manual has no block diagram so maybe they use all 16 CPU lanes to run the single 16x slot and do all other bus functions with their B85 chip.
That's the case. Nothing is plugged into the other PCIe slots.

The GA-Z87X may be the issue. A much better manual with a block diagram shows that only one of the four 16x slots is capable of 3.0 x16 speed and that's if nothing else is plugged in.
The GPU is plugged into the slot closest to the CPU (the x16 one). Nothing else is plugged into the other PCIe slots. I've bought this MB when I thought that I should build dual GPU hosts, but it turned out that they hinder each other's performance, so I gave up putting a second GPU in the same MB.

The Z87 handles the 1x slots and other bus functions. Is there a way with Linux to monitor actual bus speed???
I don't know.

Also, the BIOS usually has a version of an option for the PCIe speed: Auto, Gen 1, Gen 2 or Gen 3. I set all mine to Gen 3 from the default Auto.
This host had Windows XP before, and the card run on PCIe3.0x16. I didn't change the hardware, I just installed Linux on that host to compare its performance.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50534 - Posted: 17 Sep 2018 | 19:32:04 UTC - in response to Message 50524.
Last modified: 17 Sep 2018 | 19:33:42 UTC

What is the current CUDA version I should be using?
CUDA 8 is fine at the moment.
But you should know that NVidia changes (hopefully improves) the CUDA driver also, so later drivers with only CUDA 8 support could have better performance, than the latest drivers. (I haven't tested it.)
The latest CUDA version is 9.2.217

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50536 - Posted: 17 Sep 2018 | 20:57:52 UTC - in response to Message 50526.

Well it made a small difference.

With swan_sync, the PABLO_2IDP took 7 hours 13 minutes, and used 99.5% of the CPU.
Without swan_sync, the PABLO_2IDP took 7 hours 40 minutes, but used 60% of the CPU.
You can't really test in on an OS with WDDM, as WDDM in itself cause a lot of latency.

I would rather have the CPU.
I don't want to force SWAN_SYNC on everyone, I just like to have the choice to use it. Now I'm forced not to use it by the lack of this option.

And I don't think drivers would make a difference.
They did made a difference back in the CUDA6.5 times under Windows XP, as the fastest driver was the 359.06. The later drivers had CUDA 8, and it somehow made them a bit (3-6% as far as I can recall) slower with the CUDA 6.5 GPUGrid app. My Windows XP hosts are still using this driver. I have only one Windows XP host online at the moment (with a GTX TITAN X GPU, which is basically a GTX 980 Ti with all the CUDA cores), but it still can beat hosts with a GTX 1080 Ti.
Check the "Performance" page, section "Top performers per batch", batch PABLO_2IDP_P01106_2_GLUP20P_ID. My Windows XP host is at the 7th place, you can find a host with a GTX TITAN Xp at the 23rd place. There are 8 hosts with GTX 1080 Ti which are ranked lower than my GTX TITAN X under Windows XP with SWAN_SYNC ON.

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50537 - Posted: 17 Sep 2018 | 21:44:36 UTC - in response to Message 50536.

Yes, I am sure it is useful. It would just take a faster card than I use at the moment.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50807 - Posted: 1 Nov 2018 | 11:04:27 UTC
Last modified: 1 Nov 2018 | 11:07:04 UTC

To answer my on question:
Under Ubuntu 16.04 and 18.04, with the BOINC manager installed from the repository, the manager runs as a daemon, and it has it's own environment, so the SWAN_SYNC=1 setting should placed in it's own configuration file at

/lib/systemd/system/boinc-client.service
This file should be edited as 'root'.
In the [service] section of that file there should be a line containing:
Environment="SWAN_SYNC=1"
It should be exactly like the above (the SWAN_SYNC should be capitalised, and the quotation marks should be there.)
The host should be rebooted to make this change take effect.

Thanks to Rod4x4 for this solution!

PappaLitto
Send message
Joined: 21 Mar 16
Posts: 427
Credit: 3,125,997,241
RAC: 7,329,652
Level
Arg
Scientific publications
watwat
Message 50812 - Posted: 1 Nov 2018 | 12:35:44 UTC - in response to Message 50807.

Hey Zoltan, what do you mean by edited as root? Does this mean you change User=boinc to User=root?

Jim1348
Send message
Joined: 28 Jul 12
Posts: 641
Credit: 1,210,698,512
RAC: 77,290
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 50813 - Posted: 1 Nov 2018 | 14:08:07 UTC - in response to Message 50812.

Hey Zoltan, what do you mean by edited as root? Does this mean you change User=boinc to User=root?

Try running the text editor as root; for example:
sudo gedit /lib/systemd/system/boinc-client.service

Keith Myers
Send message
Joined: 13 Dec 17
Posts: 155
Credit: 132,230,638
RAC: 994,249
Level
Cys
Scientific publications
wat
Message 50814 - Posted: 1 Nov 2018 | 16:44:36 UTC

Good to hear that Zoltan and Rod4X4 worked it out how to get SWAN_SYNC=1 working on repository versions of BOINC. My posts in the Linux thread seems to have provided the necessary dialog and testing for the solution to be exposed.

So now both the Seti Tbar and repository versions of BOINC can benefit from the improvement in using SWAN_SYNC. Project benefits from increased throughput.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1965
Credit: 12,911,154,394
RAC: 11,469,048
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50815 - Posted: 1 Nov 2018 | 17:39:22 UTC - in response to Message 50813.

Hey Zoltan, what do you mean by edited as root? Does this mean you change User=boinc to User=root?
Try running the text editor as root; for example:
sudo gedit /lib/systemd/system/boinc-client.service
That's what I meant.

rod4x4
Send message
Joined: 4 Aug 14
Posts: 16
Credit: 1,012,616,569
RAC: 1,529,536
Level
Met
Scientific publications
watwatwatwatwat
Message 50816 - Posted: 2 Nov 2018 | 5:37:20 UTC - in response to Message 50807.


/lib/systemd/system/boinc-client.service
This file should be edited as 'root'.
In the [service] section of that file there should be a line containing: Environment="SWAN_SYNC=1"


NOTE:
1. Ensure the Environment= line is before the ExecStart= line.
The Environment= line is best placed as the first line after the [Service] heading.
2. Performing an update on the boinc-client package may need this line re-added after the update. (have not tested this)

Profile ServicEnginIC
Send message
Joined: 24 Sep 10
Posts: 6
Credit: 947,426,923
RAC: 1,135,817
Level
Glu
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 50824 - Posted: 4 Nov 2018 | 16:33:39 UTC

First of all, thank you very much to all kind contributors to bringing this to work, in this and other threads.

Now, a step-by-step practical way to apply this in a few minutes (for Linux rookies like me and above)
I've just applied successfully this method in three different computers with already running GPU tasks without the need for them to end, and all tasks have restarted normally after applying the new configuration.
All three computers are running under Linux 16.04.5 LTS and repository BOINC versions (7.6.31 x64).

-1) If there are tasks running: Enter BOINC Manager - Activity - Suspend. Exit Boinc Manager. This will checkpoint and stop all running tasks
-2) Open a Terminal window, and execute the following commands:
-3) sudo killall boinc
-4) sudo gedit /lib/systemd/system/boinc-client.service
-5) Add the following line immediately below [Service] tag: Environment="SWAN_SYNC=1"
-6) Save the change and close gedit instance. Return to Terminal window
-7) sudo systemctl daemon-reload
-8) sudo /etc/init.d/boinc-client restart
-9) Close Terminal window
-10) Enter BOINC Manager - Activity - Run

That's all. Previous running tasks will restart from its stored checkpoint, but a full CPU thread will be assigned to every GPU.

One last advise:
Please, be caraful. This configuration will bring the whole system to its maximum performance.
More power = more heat. It Might be a good idea to check system fans and heatsinks to be free of dust...
And I use Psensor program from Linux repository. I recommend it to check temperatures, fan levels, and several other interesting indicatives.

Profile Logan Carr
Send message
Joined: 12 Aug 15
Posts: 240
Credit: 60,038,511
RAC: 139,117
Level
Thr
Scientific publications
wat
Message 50869 - Posted: 15 Nov 2018 | 2:05:20 UTC - in response to Message 50824.

Thank you all!

my gtx 1080 GPU is now on 99% usage with linux!
____________
Cruncher/Learner in progress.

Post to thread

Message boards : Wish list : SWAN_SYNC in Linux client