Fedora 11 x86_64 RPMS

http://www.vacuumtube.org.uk/folding/fedora/11/unstable/x86_64/boinc-client-6.10.7-2.fc11.x86_64.rpm
http://www.vacuumtube.org.uk/folding/fedora/11/unstable/x86_64/boinc-client-doc-6.10.7-2.fc11.noarch.rpm
http://www.vacuumtube.org.uk/folding/fedora/11/unstable/x86_64/boinc-manager-6.10.7-2.fc11.x86_64.rpm

Well they seem to have splatted the cuda preempting bug in this version.

Paul has raised concerns about the amount of cuda work fetched, which looks like it might be a problem. Its been a problem from the 6.6.x days really but we need to get logs and such so the developers can work out whats going on.

Well they seem to have splatted the cuda preempting bug in this version.

Paul has raised concerns about the amount of cuda work fetched, which looks like it might be a problem. Its been a problem from the 6.6.x days really but we need to get logs and such so the developers can work out whats going on.

There have been problems with the amount of work fetched, both here and at AQUA, because of inaccurate project estimates and DCF interactions. I read Paul's report, and it was unclear whether this possibility had been ruled out in the case he quoted.

There remains the work fetch issue regarding GPU and CPU mixes - 6.10.x (including 6.10.7) STILL goes looking for CPU tasks from GPU projects (including GPUGRID and Collatz) and still goes looking for GPU tasks from CPU only projects (Spinhenge, POEM, etc.). That strikes me as something which could and should be fixed. Seems that few have observed this, or that any who have don't seem bothered by it -- at least on the developer side.

Last point, to this recent point in history there has been almost no one that has been running more than one GPU project at a time on a system. We are only now able to attach to multiple GPU capable projects and so this is virgin territory. For CUDA the only real choice (IMHO) has been GPU Grid, others likely opted for only SaH... but now one has GPU Grid, MW and Collatz as CUDA choices and MW and Collatz as ATI choices ... and now we are seeing the issues ...

{edit - add}
Oh, and if you have been avoiding 6.10.4 through .6 I am moving my recommendation to "suggested" over 6.10.3 ... to play safe stay with 6.10.3 till I have another couple days ... but 6.10.7 looks like the next stable version that is usable ...

There remains the work fetch issue regarding GPU and CPU mixes - 6.10.x (including 6.10.7) STILL goes looking for CPU tasks from GPU projects (including GPUGRID and Collatz) and still goes looking for GPU tasks from CPU only projects (Spinhenge, POEM, etc.). That strikes me as something which could and should be fixed. Seems that few have observed this, or that any who have don't seem bothered by it -- at least on the developer side.

Well, how do you test-out to see if a project has added support for new hardware, if you don't ask about this ocassionally? Currently the only way client knows this is to send a scheduler-request for work.

I posted this over on the BOINC client message board in response to Richard's comment of "the only thing you gain by degrading to v6.6.33 or earlier is ignorance (lack of information in the logs). And the only thing you gain by degrading to v6.4.5 is the inability to run both CPU and GPU tasks for the same project/application."

I'd note that he ignores that the other thing I gain by moving back to say 6.4.5 is not only do I ready GET work from projects like POEM or Spinhenge since they only support CPU work and will fail a 'too quick' work fetch (which you generate when you ask for non-existent GPU work), but also, I don't extraneously ping the servers (as Paul noted). He's also ignoring that the current work fetch routine FAILS way too often.

But as Paul noted, this no doubt is a losing effort regarding the client, and since the multi-project concept of BOINC (hello BOINC developers) means it makes sense to have multiple GPU and multiple CPU projects attached, I find myself compelled to use the later troublesome, noisy client unless I am either CPU only (5.10.45 is lovely there), or GPUGrid as a single CUDA project (6.4.5) is OK here UNLESS GPUGrid forces CUDA 2.3).

Why the development folks won't simply set things up to read the user account settings and then have them stored locally on the workstation as part of the account_project file is now more a matter of developer ego than lack of feasibility.

***** what posted over there ***********
That might be what you want to do with 'default users' -- those who install, attach and don't do anything else. There used to be a LOT of those folks back in the old Seti@home days. To the extent that many of them are running BOINC today, I suspect they are using legacy clients and haven't changed much since they set up BOINC on their computers.

But these days, those remaining in the BOINC population as active include a fair number of folks who actually have hardware configurations matched to the projects they attach to. These folks (including myself) support multiple projects -- some of which support 'everything' (MW as an example = though their CUDA and ATI support is only double precision' or Collatz -- which supports the broadest combination out there as well as CPU), projects which specifically are GPU only (like GPUGrid), as well projects which are CPU only (like Climate, POEM, Spinhenge, Malaria and a number of others. The thing is, where a project supports multiple hardware configurations, the user can configure the account for GPU or CPU or GPU and CPU. And for those with a broad range of hardware they can configure Home, Work, School -- for different combinations.

I suppose on the project side, CUDA or ATI might be an additional choice that could help things there as well -- but ONLY if the client has the capability to do the account/local hardware check BEFORE it goes out to the project and asks. It just seems that while all the extra 'stuff' is going into the Client that some means to let the installed client glean that information and use it, thus reducing user observational frustration and project I/O traffic.

But as I said, I'm probably just simply too stupid to see things the right way here.

*************

I posted this over on the BOINC client message board in response to Richard's comment of "the only thing you gain by degrading to v6.6.33 or earlier is ignorance (lack of information in the logs). And the only thing you gain by degrading to v6.4.5 is the inability to run both CPU and GPU tasks for the same project/application."

I'd note that he ignores that the other thing I gain by moving back to say 6.4.5 is not only do I ready GET work from projects like POEM or Spinhenge since they only support CPU work and will fail a 'too quick' work fetch (which you generate when you ask for non-existent GPU work), but also, I don't extraneously ping the servers (as Paul noted). He's also ignoring that the current work fetch routine FAILS way too often.

But as Paul noted, this no doubt is a losing effort regarding the client, and since the multi-project concept of BOINC (hello BOINC developers) means it makes sense to have multiple GPU and multiple CPU projects attached, I find myself compelled to use the later troublesome, noisy client unless I am either CPU only (5.10.45 is lovely there), or GPUGrid as a single CUDA project (6.4.5) is OK here UNLESS GPUGrid forces CUDA 2.3).

That might be what you want to do with 'default users' -- those who install, attach and don't do anything else. There used to be a LOT of those folks back in the old Seti@home days. To the extent that many of them are running BOINC today, I suspect they are using legacy clients and haven't changed much since they set up BOINC on their computers.

A follow up and my response -- from Richard (note his passing comment about the great DA at the end of his post)


OK -- and sorry about the testiness of my replies as well -- it seems there is that classic 80% of agreement.

With POEM -- it isn't so much the back off cycle (theirs is quite short - a couple of minutes and not progressive), but rather that subsequent requests by the client are STILL GPU only. POEM does not support GPU and like a number of projects does not appear to have the inclination or resources to develop a GPU application. With Spinhenge, the backoff cycle is a non-progressive 15 minutes. Curiously enough, the 6.10.x client doesn't appear to be repetitive about GPU requests there, just once and it reverts to CPU. Spinhenge is similarly not supporting or likely to support GPU.

With GPUGrid, I found it curious that the request was for CPU -- again, the project is a 'single mode' project -- GPU and for that matter CUDA GPU only. I have seen queries for ATI GPU and CPU work in the client messages on the workstation -- that's just wrong to my way of looking at things.

With the implementation of ATI GPU support (YES -- a GOOD thing), the matter gets a bit more complicated.

In my view, ideally, at the account/preferences/resource share and graphics settings one should have the capability (for the default and by the three available groups) to control use to cover all the options -- instead of the current use GPU if available (Yes/No), Use CPU (Yes/no), there should be a USE ATI GPU (yes/no), USE CUDA GPU (yes/no), Use CPU (Yes/no).

Different settings could be configured by the user for each group should they so wish (for example on Collatz which has the broadest support -- I'd have a use ATI GPU group and a use CUDA GPU group and so on and set my workstations to be part of the specific group which matches the hardware).

These preferences should then get downloaded to the specific workstation to the account_project file and read by the client as a control for the type of work fetch it should use. When first adding a computer to a project, it would pull the settings off the default configuration which then could be changes by the user by switching the computer to the appropriate group. (It might be a nice 'advanced' feature when joining a new computer to a project where you are an existing user to specify which group the computer belongs in at the outset.

The idea behind this is to have the client work fetch be targeted to getting work which matches the workstation configuration and not to waste time and cycles pinging the project servers -- many of which are currently stressed out with I/O traffic (SETI is not the only one running at (or over) the edge regarding I/O traffic). It would also calm the noise level of troublemakers like me (and Paul for that matter) <smile>.

A portion of Richard's reply
****************************

I don't know how long POEM makes you wait between requests, or why they've chosen to introduce the delay: are the delays following the twice-daily GPU ping (actually, presumably now four times a day, twice for CUDA and twice for ATI) sufficient to explain your work drought with v6.10.7 on their own? Or could their be other mechanisms at play, like the changing definitions of long term debt and 'overworked'? You'll probably need to get deep down and dirty with "work fetch debug" logging flags before you can explain exactly where the current mechanism is breaking down, and that's a necessary first step before fixing it.

Overall, I agree with your general thrust that use/don't use resource switches should operate at the client level, project by project and under user control (I'm a great believer in giving users choice over how the resources they're donating are used), but it will take a concerted and well-documented effort to persuade David Anderson that this is the way forward.

*******************************************************

OK -- and sorry about the testiness of my replies as well -- it seems there is that classic 80% of agreement.

Paul, I copied that message over from another message board - that 'testy' comment was to Richard -- his post riled me up and he apologized for its tone so I completed the loop and apoligised for my tone -- over there.

Um, did I give you the impression I thought you were being testy?

My fault as that was not intended.

Paul -- no, you and I agree on this issue almost completely -- that 80% message was to Richard.

I really don't understand why an installed client can't read the user controlled settings on the local system regarding GPU or CPU for each project as part of the fetch. The user can change those settings at the project site and can control for differing workstation settings by using different groups for different workstation configurations.

As to WHY DA can't/won't understand that -- well, my wife is the psychoanalyst, not me.

I was just trying to amplify and clarify some points. So I am sorry you think I only agree with 80% of what you are saying ... heck, read my latest on the mailing list ...

As to that last point ... Richard is dreaming ... it was a bad design choice, but because UCB never makes mistakes and they slapped in the change to the back-off it is unlikely that this "feature" is going to change ... ever ...

Paul, here is an example of just how brain dead the current fetch routine isn note, this particular workstation has a 9800GT, and Collatz is configured for GPU only at the project level:

9/25/2009 9:34:21 PM Collatz Conjecture Sending scheduler request: To fetch work.
9/25/2009 9:34:21 PM Collatz Conjecture Requesting new tasks for CPU
9/25/2009 9:34:26 PM Collatz Conjecture Scheduler request completed: got 0 new tasks
9/25/2009 9:34:26 PM Collatz Conjecture Message from server: No work sent
9/25/2009 9:34:26 PM Collatz Conjecture Message from server: Your computer has no ATI GPU
9/25/2009 9:34:31 PM GPUGRID Sending scheduler request: To fetch work.
9/25/2009 9:34:31 PM GPUGRID Requesting new tasks for CPU
9/25/2009 9:34:36 PM GPUGRID Scheduler request completed: got 0 new tasks
9/25/2009 9:34:36 PM GPUGRID Message from server: No work sent
9/25/2009 9:34:36 PM GPUGRID Message from server: ACEMD beta version is not available for your type of computer.
9/25/2009 9:34:36 PM GPUGRID Message from server: Full-atom molecular dynamics on Cell processor is not available for your type of computer.

Yeah I noticed -- but a .8 then .9 bump within 24 hours doesn't give rise to confidence. The thing is, the condition causing the problem I posted here isn't considered a bug that should be fixed. It appears that DA LIKES that sort of situation.

It didn't last very long. Superceeded by 6.10.9. See seperate message thread for details.

It didn't last very long. Superceeded by 6.10.9. See seperate message thread for details.

Further, and I have seen this in other non BOINC technical situations, so I know the IT <> User interaction can be 'suboptimal', I get the sense often enough that any problems active users have with the ever changing client iterations are because the users are not using the client the 'right' way (the 'right' way being the small mini-lab environment the developers apparently are using).

Like I've said before, my increased 'noise level' on this has been that in the past I was insulated from much of the 'improvements' foisted on folks with newer client development policy. I didn't have GPU supported workstations -- so I went with the 5.10.45 client -- which works fine for Win2K and XP environments, work fetch is as expected there.

When I added a couple of Vista workstations, I first went to the 6.18/6.19 client since they incorporated a change to allow the client to start with boot up and not fight the Vista 'protection scheme'. When I started adding some GPU support (9400GT, 9600GT, 9800GT, 250GS) and GPUGrid, I went to the 6.4.5 client -- it had some work fetch quirks, but generally handled things well enough. I tried the 6.6.36 client and got out of that quickly finding its work fetch schema deeply flawed, notwithstanding the gospel of Dave.

I would have stayed 'dumb and happy' (the way developers often like to keep users) except for the changes over in Collatz -- with them marrying up support for low end video processors including ATI, along with a requirement for CUDA 2.3, I've been compelled to diddle with the 6.10.x series on a number of workstations in mixed project environments (I typically have 6 to 9 projects on a workstation with 4 to 6 of them being configured as CPU only -- or CPU only at the project level, and 2 to 3 configured as GPU only (or like GPUGrid GPU at the project level). This clearly is an environment with which the developers have very scarce experience or awareness.

So, being forced to work with (or against) the 6.10.x client and it 'from above the developers directed force', I've take to 'railing against the machine' and joining you in a number of venues.

But I'll not get in the additional channels -- from your comments, I already know the type of response I'd get. I do figure by posting in more open areas, I can seek to increase awareness of the issues amongst the rest of us hoi poloi. Sometimes the journey of a thousand miles begins with a couple of noisy posters <smile>.

As I pointed out in one of my list posts in the last day or so one of the problems is that neither Rom nor Dr. Anderson are heavy users of BOINC ... it is obvious from their comments about issues that this is still true and I know that at least as of last month or so ago (I forget exactly when I had the conversation with someone who is in a position to know) that there is no UCB "lab" where they actually run various versions of BOINC to see what it does ... and does not do ...

I mean how am I supposed to take seriously a software development effort that does not appear to use the product that they are developing except casually?

Further, and I have seen this in other non BOINC technical situations, so I know the IT <> User interaction can be 'suboptimal', I get the sense often enough that any problems active users have with the ever changing client iterations are because the users are not using the client the 'right' way (the 'right' way being the small mini-lab environment the developers apparently are using).

Like I've said before, my increased 'noise level' on this has been that in the past I was insulated from much of the 'improvements' foisted on folks with newer client development policy. I didn't have GPU supported workstations -- so I went with the 5.10.45 client -- which works fine for Win2K and XP environments, work fetch is as expected there.

When I added a couple of Vista workstations, I first went to the 6.18/6.19 client since they incorporated a change to allow the client to start with boot up and not fight the Vista 'protection scheme'. When I started adding some GPU support (9400GT, 9600GT, 9800GT, 250GS) and GPUGrid, I went to the 6.4.5 client -- it had some work fetch quirks, but generally handled things well enough. I tried the 6.6.36 client and got out of that quickly finding its work fetch schema deeply flawed, notwithstanding the gospel of Dave.

I would have stayed 'dumb and happy' (the way developers often like to keep users) except for the changes over in Collatz -- with them marrying up support for low end video processors including ATI, along with a requirement for CUDA 2.3, I've been compelled to diddle with the 6.10.x series on a number of workstations in mixed project environments (I typically have 6 to 9 projects on a workstation with 4 to 6 of them being configured as CPU only -- or CPU only at the project level, and 2 to 3 configured as GPU only (or like GPUGrid GPU at the project level). This clearly is an environment with which the developers have very scarce experience or awareness.

So, being forced to work with (or against) the 6.10.x client and it 'from above the developers directed force', I've take to 'railing against the machine' and joining you in a number of venues.

But I'll not get in the additional channels -- from your comments, I already know the type of response I'd get. I do figure by posting in more open areas, I can seek to increase awareness of the issues amongst the rest of us hoi poloi. Sometimes the journey of a thousand miles begins with a couple of noisy posters <smile>.

I really don't understand why an installed client can't read the user controlled settings on the local system regarding GPU or CPU for each project as part of the fetch. The user can change those settings at the project site and can control for differing workstation settings by using different groups for different workstation configurations.

I really don't understand why an installed client can't read the user controlled settings on the local system regarding GPU or CPU for each project as part of the fetch. The user can change those settings at the project site and can control for differing workstation settings by using different groups for different workstation configurations.

Barry,

Check out the BOINC message board again. We have progress: it'll need server updates as well as a new client build, and I can already see some fine tuning needed during testing, but the direction of movement is positive. Berkeley is not deaf, merely hard of hearing!