In the early days of BOINC I knew what it was doing and how to adjust it so that it did what I wanted. Now, it has become so convoluted I tend not to bother and just fiddle the quotas for projects to try to acheive what I want. I wondered, if I detatch from a project then reattatch - does that wipe out any damned memory of things that BOINC might be holding? I am using BOINC Manager 6.6.20
I ask here rather then on the SETI forum because I can't be bothered telling people that I want my machines to do what I want and telling me to leave it be and just let BOINC do what it wants is best.
I have been running BOINC from the start and don't believe I have ever been less satisfied with it.
Copyright © 2024 Einstein@Home. All rights reserved.
Getting fed up with BOINC scheduling.
)
Normally it is better to leave BOINC alone, but there are told to be scheduling problems with 6.6.20.
Since you don't say explicitly what bothers you, I assume it's BOINC favoring some project(s) over the others. That's probably a debt problem. BOINC 6.6.x is known to cause such after upgrading.
Yes, detaching/reattaching might clear some buffers for the project in case. Better might be to reset all debt values to zero. There's a cc_config option now for doing that:
More information about cc_config.xml you can find here.
See also the Release notes for version 6.6 in the BOINC wiki.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: I have been running
)
One option would be to run your caches dry and then roll back Boinc to an earlier version that you could control better. The newer versions still have some things that alot of us would rather not see. I have only upgraded 1 machine to the latest and 1 to a version prior to that, all the rest, 15 of them, are still running version 6.2.19. If you want a link to a whole bunch of Boinc versions here it is http://boincdl.ssl.berkeley.edu/dl/
RE: In the early days of
)
If you are interested in running the later versions avoid 6.6.20 and below. Like the plague. 6.6.20 in particular can cause tasks to run up to 4 times slower... cause unknown... I HAVE seen this in other later versions but it is fairly rare and I still cannot put finger to a cause.
Detaching and reattaching does clean up everything associated with the project and is one way to force the system to restart its decent into madness ... :)
Less drastic and usually as effective is the reset of the debts. DA changed the whole system there and does not seem interested in hunting down the issues that remain. Thankfully in the .3x versions MOST of the Resource Scheduler bugs are being found and taken out, though there is resistance to that also ...
If you don't need CUDA, and are not interested in the other newer features, the earlier versions run well... if you are running CUDA, 6.5.0 is the best of the lot as far as I am concerned.
If the developers were more interested in making it so that it would run as it should I would agree with them. Sadly, BOINC has not done well since about 2005 when the multicore systems arrived on the scene... and it still does not do well because the core assumptions on which most of the code is based assumes, fundamentally, that there is only one processing element. The other assumption is that multiple core systems will run that code as efficiently as does the vanishing single core system ...
Concur ... the only thing one can hope is that when they add other features and Snow Leopard gets here we will see that other developer eyes might be put onto the Resource Scheduling and Work Fetch areas which are the sources of the issues.
RE: If you are interested
)
Hi Paul,
Thanks for that info. I was running 6.6.20 and, hated it !
I have now rolled mine back to the 6.2.19 that previous poster
mikey was using.
I wish I could leave the thing alone when it is working well but,
I always want to try the new worthless versions for some reason.
Regards,
Bill
There are reasons to upgrade,
)
There are reasons to upgrade, some better than others... :)
My main complaint is that the developers complain all the time about being swamped and yet they keep chasing mirages instead of concentrating on the issues which really cause people to drop BOINC.
They have this idea that by making FaceBook hooks they are going to get substantial numbers of new users ... heck we would have twice as many users today as we do if they had only been able to hang onto the SaH Classic people ... but they did not listen to the concerns of those people and they are gone now ...
Anyway, there are a few improvements that slowly, ever so slowly are resolving the issues caused by the major changes made to the Resource Scheduler ... just in time for new ones to be introduced with the expansion to the other GPU classes ... sigh ...
Anyway, I pretty much had to upgrade so I could run CUDA and am living with the issues ... been using BOINC VIew and the new replacement to monitor my systems so ... anyway ...
>>> avoid 6.6.20 and
)
>>> avoid 6.6.20 and below
Hmmm, this is what I have. I've been trying to work out the logic behind the system, and have failed. I was interested in CUDA, but it looked like there were problems, and I can't cope with problems anymore.
I don't understand how this machine, for example, a quad core Intel of last years vintage, can ALWAYS be running at least one sometimes more tasks, (Einstein), while other projects, some with a higher quota, run dry then wait. I see their work fetch value drop to -100,000 or lower and work back up to -87,000 before downloading a wu. Yet Einstein is always 0.0, any time I look, whatever is going on - that cannot be right. I have experimentally dropped Einstein to 15%, (and yes, I can see the problems...), and they still have 2 running and one queued. I always assume I have done this somehow, but I don't know what or how.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
RE: >>> avoid 6.6.20 and
)
Hi Adrian,
Here's something to try. Bring up your (web based) Einstein
account info.
Go to computing preferences__ processor usage__ Option
On multiprocessors, use at most
Enforced by version 6.1+
Since you have a quad core, set that to 25 percent ( Einstein limited to 1 core)
or 50 percent ( Einstein limited to 2 cores ) etc.
Update Einstein in Boinc__ this should limit the No.of cores Einstein can use.
Unfortunately, this might have similar affect on your other projects but, if
you play around with the settings, you might come up with something more
tolerable to work with.
Regards,
Bill
RE: >>> avoid 6.6.20 and
)
As suggested above resetting debts is a good idea. The 6.6 versions of BOINC changed the whole concept of debts, thats why its a good idea to reset them when you upgrade. Basically it uses debts to determine what project to get work for and which ones to run.
As for cuda it seems fairly reliable under windows. Linux support is there but from what I gather is quite picky with driver versions and flavour of OS. You can run into issues with driver versions, particularly with GPUgrid. Einstein have some apps in the works but have not yet released them. Seti has one but the science app has issues with VLAR (very low angle-range) work units, nothing to do with BOINC, its the science app.
The main issues with BOINC at the moment, in my opinion, are around the work-fetch and resource share. I find that quite often i'll have too much cuda work and run out of cpu work. I have some machines with 6.6.33 and some with 6.6.36 (which is now the "release" version for windows).
BOINC blog
RE: >>> avoid 6.6.20 and
)
Maybe it’s time for some of these projects to take Boinc and chuck it straight into the great Gehenna where it may belong.
Have there own independent program to run their science app on - ala seti classic and folding @ home.
Maybe some of us don’t need Facebook and myspace capability built in ???
What is next ? - Built in Skype – AIM instant messenger and, MSN search capability ?
Built in Google distributed computing toolbar ? - With youtube links to all of DA’s favorite scenes from the movie ET the extraterrestrial ?
I could go on but,
Regards,
Bill
RE: What is next ? - Built
)
Try news feeds ... :)
At least that is one of the things they are talking about adding ... and have already written some code for it ...
As to the debts and running some projects dry ... well, all the 6.6.x and later versions have a bug or three remaining in the work fetch and this is the current main symptom ... you either run dry on CUDA work or CPU work ...
I have reported it, as have others ... no interest on the part of the developers yet ... the only way to resolve the problem is to reset the debts. I have had streaks where I have had to reset debts about every 3-4 days to keep enough GPU work on one system. It seems a little better with .28 and later, but I suspect that this is not to last ... for the simple reason that they have not changed code in work fetch or RR Sim ... which means that the problem is very likely not yet addressed...