Getting fed up with BOINC scheduling.

adrianxw
adrianxw
Joined: 21 Feb 05
Posts: 242
Credit: 322654862
RAC: 0
Topic 194380

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.

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Gundolf Jahn
Gundolf Jahn
Joined: 1 Mar 05
Posts: 1079
Credit: 341280
RAC: 0

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:

Set resource scheduling debts to zero. This lets you fix situations where client bugs have resulted in distorted debt values. Set it, run the client, then clear it (otherwise you'll start out with zero debts every time you run the client). New in 6.6.11


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)

mikey
mikey
Joined: 22 Jan 05
Posts: 12684
Credit: 1839089911
RAC: 3810

RE: I have been running

Quote:
I have been running BOINC from the start and don't believe I have ever been less satisfied with it.

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/

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

RE: In the early days of

Quote:
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


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.

Quote:
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.


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 ...

Quote:
I have been running BOINC from the start and don't believe I have ever been less satisfied with it.


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.

Bill592
Bill592
Joined: 25 Feb 05
Posts: 786
Credit: 70825065
RAC: 0

RE: If you are interested

Message 93331 in response to message 93330

Quote:

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...

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

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

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 ...

adrianxw
adrianxw
Joined: 21 Feb 05
Posts: 242
Credit: 322654862
RAC: 0

>>> 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.

Bill592
Bill592
Joined: 25 Feb 05
Posts: 786
Credit: 70825065
RAC: 0

RE: >>> avoid 6.6.20 and

Message 93334 in response to message 93333

Quote:

>>> 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.

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

MarkJ
MarkJ
Joined: 28 Feb 08
Posts: 437
Credit: 139002861
RAC: 0

RE: >>> avoid 6.6.20 and

Message 93335 in response to message 93333

Quote:

>>> 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.

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).

Bill592
Bill592
Joined: 25 Feb 05
Posts: 786
Credit: 70825065
RAC: 0

RE: >>> avoid 6.6.20 and

Message 93336 in response to message 93333

Quote:

>>> 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.

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

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

RE: What is next ? - Built

Message 93337 in response to message 93336

Quote:
What is next ? - Built in Skype – AIM instant messenger and, MSN search capability ?

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...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.