1) BOINC Manager/project view Window positioning; Save those settings!

I would like to know if in the next BOINC release revision, if it might be possible to incorporate the saving of window positions.

As things stand, they might open near to where I want them, they might be shorter or narrower, or they might be smaller in both dimensions. Of course, if I want to show off BOINC to other people and try to get them interested, first I've got to reorganize and resize the manager window, and then open the project windows so that they get the "full effect."

Personally, I prefer to open the window the same location each time I run it, and I prefer to open the project status views in the same locations as well. (I run a dual core CPU on one machine, so it'd be nice to have BOTH of the project view window positions saved...not just the first one that opens...)

I've taken a screenshot of my "preferred window positions" with the main BOINC Manager and both active project view windows open to illustrate (as though it were needed ;) what I mean.

2) Multiple CPUs/Multi-Core CPUs and multiple projects.

a) When running on a multi-chip or multi-core machine (and enabled) I find it strange there isn't any method to choose HOW the extra core is utilized.

I think that--rather than "switching projects" when a user is running only two projects on their machine--a user should have the option to run both projects simultaneously.

To be more specific, allow the current project switching operation for those who want/need it, but make it possible to continue processing workunits from one project on one core/CPU, while processing workunits from a second or third project on the other.

The reason that I see this as important is for projects such as the BBS ClimatePrediction Project--or any other such HUMONGOUS project--needs as much CPU time as possible to get done, and switching COMPLETELY to secondary/tertiary project cuts into the needed CPU time for the "main project."

b) Further to this idea, it would also be nice to be ableto limit the number of active processes a given project can employ.

Put quickly, do you really want to run two HUGE projects at once, or would you rather run one HUGE project, and several smaller ones at the same time?

By allowing the user to limit the number of CPUs/cores a given project can use at maximum, this might make multiple projects just that much easier for those people with multi-core machines...and those numbers are growing!


c) Multiproessing, on the other hand, could also be used to double the speed at which a SINGLE workunit could be processed...but it ain't. ;)

If I had the ability to slam through workunits at twice my current speed by having both cores active on a single project at a time, it would "partially negate" the multi-cpu/core thoughts expressed above, as I would then NEED to switch projects at a given interval, otherwise I'd never get to a second project's workunit started until the first WU was completed. Obviously, it would be bad for the LHC WU's to wait two months till they got touched after downloading them while the climate model(s) chugged merrily along...

d) When you've got multiple projects running and your system launches the screen saver (sic) it shouldn't ALWAYS pick ONLY the first project running, but it should randomly select which of the two projects to display.

This is just something that I noticed, that when it pops up th screen saver, it ONLY displays the first climte model that I downloaded/began running, but it NEVER shows the second model.

Used with a few of the suggestions made herein, this would allow the random display of one of two possible projects as the screen saver, rather than ONLY the first model which was started, OR it would allow a random selection of which PROJECT's screen saver to display.

3) COnfiguration editing & documentation.

It'd sure be nice to have a configuration editor available to tweak a project's/client's operation WITHOUT needing to login on the net.

It'd also be VERY NICE to see a comprehensive set of documentation included with the client download. It doesn't have to be pretty, ad I prefer plan, green ASCII text myself, but I'd really LOVE to see more documentation INCLUDED, or at the very least, add a button somewhere in the BOINC manager to take a user to a "Comprehensive Software/Project Configuration Documentation" web page.

"Nuff said." ;)

In any case, those are my thoughts for the moment...hope they help at some point down the road.

PS: Typed this on the laptop and I am NOT used to these (*@#in' chicklet keys just yet...please excuse any typos. ;)

---

1) BOINC Manager/project view Window positioning; Save those settings!

BOINC Simple GUI will stay on the screen where you last left it.
That's in the next version of BOINC.

Leaving 2 to be answerd by someone else.

3) COnfiguration editing & documentation.

It'd sure be nice to have a configuration editor available to tweak a project's/client's operation WITHOUT needing to login on the net.

BSG will have simple preferences.
You can further add all you want in a global_preferences_override.xml file.
For now you will need to add this by checking in the options on the BOINC site.

It'd also be VERY NICE to see a comprehensive set of documentation included with the client download.

I am advocating to have a comprehensive enough multiplatform HTML readme/help file included. HTML as it will be available on all operating systems.

---

1) The manager does remember it's last position, however you have to use file-exit to actually cause it to save.

2) It would be nice if BOINC set affinity for running tasks. Even though the real world gains are not as large as you would expect. This is especially true on HT CPUs where setting affinity can actually decrease performance.

2c) In general it is not possible to use multiple CPUs to process one task faster. The tasks are already paralellised as much as possible in most cases. When multiple CPUs are trying to run one task, one is running it and any other CPUs are waiting for that one to get to a stopping point where they can take over.

2d) The screensaver semi-randomly decides which task to display on multi-CPU systems. The client polls all apps and the first one to reply gets the screensaver first. After 10 minutes it changes to a different one.

3) This is exactly why the wiki in my sig was started. I don't know if anything offical will ever be done about it though.

---

BOINC WIKI

BOINCing since 2002/12/8

2) Multiple CPUs/Multi-Core CPUs and multiple projects.

a) When running on a multi-chip or multi-core machine (and enabled) I find it strange there isn't any method to choose HOW the extra core is utilized.

I think that--rather than "switching projects" when a user is running only two projects on their machine--a user should have the option to run both projects simultaneously.

To be more specific, allow the current project switching operation for those who want/need it, but make it possible to continue processing workunits from one project on one core/CPU, while processing workunits from a second or third project on the other.

The reason that I see this as important is for projects such as the BBS ClimatePrediction Project--or any other such HUMONGOUS project--needs as much CPU time as possible to get done, and switching COMPLETELY to secondary/tertiary project cuts into the needed CPU time for the "main project."

Set up your resource shares on each project, so that the big task uses 50% of the total (i.e., say 24/12/12 out of a total of 48. I like to use core-hours as the 'currency' for resource share since it makes it easy to visualise).

Set 'no more work' on the big project. This will prevent a second model being downloaded during a lull in computation of the other projects. Once the model is done, you'll need to turn off no more work until your next model is downloaded, etc.

b) Further to this idea, it would also be nice to be ableto limit the number of active processes a given project can employ.

b) is indirectly handled by the second paragraph above - you can prevent new WUs being downloaded, and hence control the maximum number of copies running at one time. Only works for long duration tasks of course, otherwise you'd forever have to be turning it on and off to download seti-sized tasks! <grins>

---

He asked about the number of cores 'a given project' is going to use. The multiprocessors setting is for Boinc as a whole. The reasons for wanting to limit these could include memory - for example two SAP models on a busy 1GB machine would probably crash, whereas one would be OK.

The current scheduler doesn't take memory usage into account, although there are discussions on the developer's email list about improving this.

---

He asked about the number of cores 'a given project' is going to use. The multiprocessors setting is for Boinc as a whole. The reasons for wanting to limit these could include memory - for example two SAP models on a busy 1GB machine would probably crash, whereas one would be OK.

The current scheduler doesn't take memory usage into account, although there are discussions on the developer's email list about improving this.

Actually, that's exactly my thinking.

I figured that if I'm running two separate BBC climate models at a time, it's definitely going to be a major resource hog, to put it mildly...so logic dictates that it would be nicer to be able to run ONE climate model and ONE "alternate project" at the same time, rather than simply running two of whatever happens to be chosen based on the current (limited) configuration alternatives.

Now, on the other hand, I am (forced to be) running two climte models at a time at the moment, and things haven't become unstable on this lil' box as yet, and I am only running with a gig of RAM, so I'm quite surprised as well as happy it isn't crashing/locking up on me. The plain facts of the matter are that as more and more people join into the fray, there will be more and more custom/alternative hardware configurations that will need to be addresed.

God help us all when Vista comes out... d8'o

PS: To all respondents, thanks for the hints, suggestions & tips! Those which I don't employ myself will surely come in handy for many others!

---

Actually, that's exactly my thinking.

Actually, I neglected to mention one other thing, an that was the fact that while the way thigs are set up currently, I am "able" to run multiple climate models, without config changes (or the "manual method" offered earlier--which WILL work, but only BEFORE you download the second workunit, which is done automatically--this would still open the potential for having such large projects with one model sitting idle for MONTHS before getting touched.

I've got one machine taking approximately 6 months per climate model, another taking approximately 4 months, another "somewhere in the middle"...so logic dictates that a second climate model could theoretically take a year or more before being returned...and while I know my collection isn't the absolute quickest available, I also know there's people out there with MUCH slower machines than I've got on hand, and the potential for unneccessary delays--and especially so for "humongous" projects like the BBC project--could be, and should be, allowed for in the next release of the BOINC manager.

NOTE: There could always be simple defaults which could take all of this into account which would only apply for mutiprocessors/multicores...and these could also be "hidden functions" which would ONLY display on multiples. I'm sure there's a simple CPU-ID check avaiable which would make this an easy (sic) thing to incorporate down the road...

---

The climate models need to periodically talk to the servers to let the server know they're still running. So a second model which is just sitting there for 6 months will be counted as 'lost in action', and a replacement generated. This usually happens after 6 - 8 weeks or so.

The way to avoid this is to let it run for a day or so every month, so a trickle is uploaded and keeps the servers happy.

Regarding the actual amount of time it takes to finish ... the climate project is happy to accept results even way past the 'deadline', although Boinc itself will panic somewhat and possibly go into EDF mode if it thinks it's going to miss the deadline. Some of my fellow CPDN moderator's own models will take a year to 18 months to run to completion, which is fine, we're patient people :-)

The coupled model actually has a relatively small memory footprint (90MB or so), compared to the CPDN-SAP model which is 150-450MB, or many of the other projects (often in the 150-250MB area). So you can run about 4 of them comfortably within a gig before you start to have memory problems, unlike CPDN-SAP where I could just about run 2 models on a 1gb machine which had been stripped down as far as I could.

---

Iain Inglis who posts on the cpdn BBC forum is running 4 models simultaneously on an '8-core' machine, which really has 4 cores hyperthreaded in pairs. I feel that however good the machine, one would have to be quite brave to do this.

Electro, I hope you're backing your models up just in case anything goes wrong? We can point you to easy instructions.

---

Iain Inglis who posts on the cpdn BBC forum is running 4 models simultaneously on an '8-core' machine, which really has 4 cores hyperthreaded in pairs. I feel that however good the machine, one would have to be quite brave to do this.

I figureif you've got the CPU and the RAM...why not? ;)

Electro, I hope you're backing your models up just in case anything goes wrong? We can point you to easy instructions.

Actually I back up my entire OS partition (with Ghost 2003...before Symantec screwed it all up...) on all systems weekly, then toss the backups onto an 80-gig 2.5" HD I keep in my pocket "just in case" so that's not a huge issue...(Overkill to keep 7 different machines' OS backups in your pocket? I think not!) although the idea of backing up models DOES intrigue me, as I'm just about to do some heavy hardware/component reorg in preparation of the sale of one or two of my "computer collection" to lighten the load on my desk.

I'm particularly interested in finding out if it's possible to migrate climate models/WUs from the machine(s) which are outbound and place them in the queues on the other machines which my "packratitis" will not allow me to part with without suitable replacements. d:'D

---

I'm particularly interested in finding out if it's possible to migrate climate models/WUs from the machine(s) which are outbound and place them in the queues on the other machines which my "packratitis" will not allow me to part with without suitable replacements. d:'D

Yes it is, I did it a couple of times. You just need a way of transferring your backup to the other machine. (I did it over our local network). Having said that I backed up the entire boinc folder and dumped it across so if you've got other stuff already running I guess that wouldn't work.
If you wait till after one of the 10 year uploads there won't be much there to transfer (size-wise) anyway because these latest models clean up after themselves. I'm sure there's been advice about it on the cpdn phpbb forum but needless to say I can't find it now... No doubt someone more techy than me will be along soon :-)

Love the prakratitis btw, not heard that before, but I'm a severe sufferer myself!

---