Yea, I agree with the guide, because even if it's wrote outside of the /etc directory it still needs sudo to modify anything going into the /etc directory. I think it would be much simplier to use a script using "sed" to do a find and replace. But I think most Linux users would just use the terminal to pass sudo to gedit and modify that file. example:
Code:
sudo gedit
or edit the file outside of /etc like the "Documents" folder and then copy it to /etc/boinc-client.
That's the advantage of using that program though: it processes the XML file as an XML file. It literally reads the whole file, makes the changes, and writes it back. I don't know if *nix has an XML parser for Bash Shell script but if it does, that would probably be the best way to go.
That's the advantage of using that program though: it processes the XML file as an XML file. It literally reads the whole file, makes the changes, and writes it back. I don't know if *nix has an XML parser for Bash Shell script but if it does, that would probably be the best way to go.
Yea, even if you're able too, the biggest obstacle is still getting a Linux user to except they need a program to do something as simple as editing a text file. and don't take that as me taking a cheap shot at the program or your ability buddy, because that's far from what I'm trying to do. It's just the mind set of 95% of Linux users. It's getting a lot better with more users using Ubuntu and Android, but we still have a ways to go.
No one "needs a program" to do what these do. Like most programs, their intent is to take a 10 step process and simplify it to one or two. Linux is engineered, it seems, to prevent that so, naturally, people that don't like wasting time doing frivolous tasks are going to stay away from Linux.
The problem isn't me, it isn't you, it isn't BOINC, it is Linux. None of us are going to fix Linux (it's a systemic problem, not a distro problem) so a thorough guide is the best we can do. I don't have Linux on any of my computers so I can't write that guide but I hope someone else will. I recommend using spoiler tags and images for whoever does it though.
I'm not intending to remove the Linux code by the way so if someone finds a way to make it work on Linux, let me know and I'll keep trying. Until then, it's really only useful on Windows.
Fine work guys. Really. This noob absorbs this stuff. I think I could edit my config in *nix with just reading these posts! Of course, both my *nix-er's are sitting in storage, at the moment but, good info for future use.
BTW, MAD, anytime spent writing a Guide will be essential to getting people to switch up their Crunchers to *nix. Effectively improving the PPD and eventually propping TPU on the top of the WCG list!!
Well, I've been looking at writing something using GTK+, but that turned into a pain pretty fast, so a command line program seemed simpler to start, and the attached program is what I threw together last night.
It's a horrible hack that asks whether to report tasks immediately and whether to use GPUs, and then writes strings to the XML file with the options in place. It doesn't parse any XML, so it will OVERWRITE the config file, which is only useful if you don't care about any other options.
Edit Sep 15: Version 0.01 had a bug where cc_config.xml was written as root, and boinc can't write to it until it's manually removed. V0.02 fixes that.
Usage:
To run it, open a terminal in the directory with the program, and type
Code:
sudo ./boinc-config
to use the default path "/etc/boinc-client/cc_config.xml" or
Code:
sudo ./boinc-config 'path-to-cc_config.xml'
for a custom path (on my system it's /var/lib/boinc/cc_config.xml).
I'll keep messing with some kind of GUI, but it might take me weeks to get that working.
The zip file has the compiled program, plus source code if anyone wants it.
Edit: I realize this is hardly easier than just editing the config file with a text editor, but at least you don't have to write the XML every time.
Updated BOINC Config Utility to 1.0.1 including changes:
-Changed "Program..." to "Running..." to avoid confusion.
-Redid the "Running..." dialog so now it shows process ID, process name, and CPU usage. This is sortable via clicking on the column header to make it much quicker to find the application you are looking for.
-Made the Exclusive Application list view sortable as well via clicking on the column header. Related: added "Value" to the header because the sorter needs it (silly sorter).
-Made it save exclusive GPU apps even if no GPUs is set to true. I'll let BOINC sort that one out. Because the application saves and loads directly to/from cc_config.xml, I didn't want to lose exclusive GPU app settings just because no GPUs was true.
Note: the program will freeze for a few seconds when opening the "Running..." dialog. This inadvertently happens because it is loading information about the running processes. I figure it isn't slow enough that it requires a "loading" dialog.
Note: It doesn't save the sorted order in the Exclusive Applications list view because, frankly, there's no reason to. Performance is better by not sorting the underlying collection, only sorting the user interface.
Updated BOINC Config Utility to 1.0.2 including changes:
-Revamped code for reading registry so it will properly fall through the options should they fail (e.g. check 64-bit registry, then 32-bit registry, then ask user).
-Changed windows icons from icons to portable network graphics. Don't ask why but if this isn't done, it will crash on start in Server 2003 and potentially other, older operating systems (read: XP).
-It now supports 5.10 which is still in service on Windows Server domain controllers.
Just updated BOINC Config Utility to 1.0.3. The changes I can remember...
-Exclusive Apps list now defaults to sorting alphabetically.
-Add running program list now defaults to sorting highest CPU load.
-Double click to add a program from the running program list is now supported again.
-When a program is added to the exclusive apps list, it automatically scrolls to it and selects it.
-When a program is added to the exclusive apps list, the default is to select "All" instead of "Default."
-Add running program and add program name dialogs no longer show up in the taskbar.
These changes should make it much faster to find, add, and apply rules so you can get back to what you were doing as quickly as possible.
Hey guys I've unsticked my old "Easy WCG Config" thread, and stickied this thread. Ford and I agree that we don't think anyone still uses the old one. If you do then I added the link to it here just in case.
Hey guys I've unsticked my old "Easy WCG Config" thread, and stickied this thread. Ford and I agree that we don't think anyone still uses the old one. If you do then I added the link to it here just in case.
<ncpus>N</ncpus>
Act as if there were N CPUs; e.g. to simulate 2 CPUs on a machine that has only 1. To use the number of available CPUs, set the value to -1 (was 0 which in newer clients really means zero).
Lets just take an i5 for example here. 4 cores 4 threads. Would this allow you to run 8 wu's and 4 cores, so essentially running 8 threads? If so, I wonder if this would hurt, help, or do nothing at all to ppd. If so this would require testing.
Code:
<no_alt_platform>0|1</no_alt_platform>
If enabled, the client will run applications only for its primary platform. For example, a Win64 machine will run only Win64 apps, and not Win32. List-add.pngNew in 5.9.10
I don't know how apps work exactly. If there are 32bit and 64bit FAAH or MCM apps then I would definitely prefer to only run 64bit apps as long as I had plenty of work. If so this would require testing.
Code:
<no_priority_change>0|1</no_priority_change>
If 1, don't change priority of applications (run them at same priority as client). List-add.pngNew in 6.6.18
NB: This option can, if activated, impact system responsiveness for the user. Default, all CPU science apps run at lowest (idle) priority Nice 15.
This might be useful on dedicated crunchers that don't get used on even a weekly basis.
Code:
<start_delay>nseconds</start_delay>
Specify a number of seconds to delay running applications after client startup. List-add.pngNew in 6.1.6
I could see this being useful to someone but not myself.
Lets just take an i5 for example here. 4 cores 4 threads. Would this allow you to run 8 wu's and 4 cores, so essentially running 8 threads? If so, I wonder if this would hurt, help, or do nothing at all to ppd. If so this would require testing.
The only time I can think of this being useful is a processor that disables cores if there isn't enough load to warrant running it. By running two applications, the processor would look at the load, say "whoa, I need more power," and turn on that disabled core. Maybe some IBM PowerPC processors do that but I can't see that being a great thing for the common user. I can add if there is demand though.
I don't know how apps work exactly. If there are 32bit and 64bit FAAH or MCM apps then I would definitely prefer to only run 64bit apps as long as I had plenty of work. If so this would require testing.
x86-64 can do 64-bit and 32-bit. If this is enabled, only 64-bit work will be requested. [Ion] has repeatedly said that 64-bit operating systems yields about 10% more PPD. Whether 64-bit only work translates to higher PPD, I don't know. I could add it if there is demand for it.
The only time I can think of this being useful is a processor that disables cores if there isn't enough load to warrant running it. By running two applications, the processor would look at the load, say "whoa, I need more power," and turn on that disabled core. Maybe some IBM PowerPC processors do that but I can't see that being a great thing for the common user. I can add if there is demand though.
This makes me think back to the gpu wu's we used to have where I maximized my ppd but having 16 wu's distributed over 4 cores. The work was done on the gpu not cpu so it is different, but I do wonder if there could be a slight ppd gain. Sandy bridge and up has such great single threaded performance.... I could just be totally wrong as I am speaking about something similar that I did in my experience but might be totally different. I could try this on my own to see if there is a difference in ppd.
x86-64 can do 64-bit and 32-bit. If this is enabled, only 64-bit work will be requested. [Ion] has repeatedly said that 64-bit operating systems yields about 10% more PPD. Whether 64-bit only work translates to higher PPD, I don't know. I could add it if there is demand for it.
I know there is that 10% from x64. That is where I had my thought there, but now that I think about it x32 and x64 really only applies to memory management. Right? I barely touch my 8gb of memory on each of my rigs whether I have 2 wu's going or 12.
Edit:
What file do I need to edit? Where would I find it?
C:\ProgramData\BOINC\cc_config.xml most likely. Make sure to put it between the options flags. Which reminds me, I should show the full path to the file it is editing.
x86-64 has more processor registers so that can significantly boost performance. The 10% gain doesn't really make any sense just for using 64-bit client. I mean, it's not memory because I have mine set up to accept high memory units and I don't think they exceed 256 MiB each. I'm running 16 tasks presently and the most memory intensive is only using 54 MB--a pittance. I think the more plausible scenario is that the tasks itself are 64-bit which yields that that bonus.
Ncpu option does allow you to run more WU's than you have cores. In my i7 4 cores 8 threads I just put 14 in the Ncpu area. I now have 12 wu's going. I will leave this like this for a few days. I am currently getting about 5600ppd average. Lets see if I do better.
The estimate of time to completion went up about 5 minutes also. So if I get 50% more wu's done in about the same amount of time that should relate to an increase in ppd.
V0.02 fixes that.
