Workload size is too small

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,208
Credit: 43,368,076,364
RAC: 44,693,428

RE: Well right under

Message 49920 in response to message 49919

Quote:
Well right under 'Computer is connected to the Internet about every' is 'Maintain enough work for an additional.'


Did you check how old the message is that you are responding to??

Back in those days that second preference you mention probably was not available in the versions of BOINC that existed at that time. The option suggested by the original responder was the correct answer for the conditions of the day.

Quote:
I have mine set to 0 and 10 respectively so should it connect every day and maintain 10 days of work.


With the greatest of respect, that combination is rather crazy for your situation. You seem to be supporting 4 projects so please realise that it's possible for BOINC to over fetch on several of them and then have to go into panic mode in order to deal with the excess. You are actually setting up BOINC to possibly fail to meet deadlines from time to time.

In that combination you quote, the '0' is fine as this actually means there is no restriction on when BOINC can connect to the servers. This is the best option for an 'always on' internet connection. The problem is the 10 extra days you want BOINC to keep. It's possible that BOINC might try to get 10 extra days worth for several of the projects you are supporting so it is quite unnecessary and counter productive to set the extra days to be that large. With 4 projects, even 3 extra days is probably starting to be excessive. You would make it much easier for BOINC to honour your resource shares for each project and keep things on an even keel without risking running out of work if you reduced the 10 to 3.

Quote:
I just set 'connect to' to 2 days as suggested above but it seems that now it will only maintain 2 days of work when I would like it to maintain 10 days.


That is not surprising if you think it through. You have actually crippled BOINC even further by telling it that it may not be able to connect when it needs to for periods as long as 2 days. BOINC's natural response will be to keep less work because of the danger that it might not be able to connect for up to 2 days when it needs to and so it might not be able to return completed work before the deadline. It's obviously up to you but I'd be setting that pref back to zero and considerably reducing the extra days pref as well. With 4 projects all supplying work and some with deadlines less than 10 days, BOINC is probably refusing to get the full complement anyway :-).

Quote:
This is also under the computer summary:
Maximum daily WU quota per CPU 3/day


The normal value for E@H should be 16. If you are down to 3, this is a sign that tasks have been erroring out or have been missing the deadline. Your computers are hidden so I can't check to see why your quota has been so drastically reduced.

Cheers,
Gary.

Carl Johnson[SETI.USA]
Carl Johnson[SE...
Joined: 27 Jan 06
Posts: 5
Credit: 7,545,838
RAC: 0

No, I didn't look to see how

No, I didn't look to see how old that post was.
I changed connect back to 0.
I'm running SETI on CUDA to it grabs about 7 tasks between einstein, rosetta and cpn and then about 300 seti tasks. All projects have the same settings.

I changed it to show my computers on einstein so you might be able to tell me why that's so low. I noticed a few had comp errors. I don't know how common this is so I pretty much ignore it.


Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,208
Credit: 43,368,076,364
RAC: 44,693,428

RE: I'm running SETI on

Message 49922 in response to message 49921

Quote:
I'm running SETI on CUDA to it grabs about 7 tasks between einstein, rosetta and cpn and then about 300 seti tasks. All projects have the same settings.


You have 4 hosts on E@H and three of them seem to be doing fine. Your AMD Phenom is having lots of problems and I guess this is the host on which you are doing the GPU crunching at Seti? If you take a look at the task list for that host, you will see that many of the tasks are erroring out. I have no experience with GPU crunching but it seems likely that your problems here are related to your use of GPU crunching at Seti. You might like to ask for the assistance of people over at Seti who may have the relevant experience. I have no idea what hoops you have to jump through in order to get multiple projects cooperating with the Seti CUDA app.

Quote:
I changed it to show my computers on einstein so you might be able to tell me why that's so low.


Your daily quota should only be low on the one host. You've returned a couple of successful tasks recently otherwise you would be limited to one task per cpu per day on that host because of all the previous errors.

Quote:
I noticed a few had comp errors. I don't know how common this is so I pretty much ignore it.


It's not normal to have these errors and you certainly shouldn't ignore them. Assuming that the Phenom host is indeed your CUDA host, you need to resolve how to get the CUDA app to play nicely with the CPU tasks and there are probably pointers on how to do this over at Seti. I have no experience of how to configure things to work properly.

Cheers,
Gary.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 1,935
Credit: 270,311,800
RAC: 300,867

RE: Well right under

Message 49923 in response to message 49919

Quote:
Well right under 'Computer is connected to the Internet about every' is 'Maintain enough work for an additional.' I have mine set to 0 and 10 respectively so should it connect every day and maintain 10 days of work. I just set 'connect to' to 2 days as suggested above but it seems that now it will only maintain 2 days of work when I would like it to maintain 10 days.


@ Gary

We have identified a bug in the BOINC core client which grossly over-estimated the length of time BOINC would take to process cached tasks - if you have access to the boinc_alpha mailing list, look for messages about [rr-sim] errors. A partial fix has been applied at changeset [trac]changeset:17625[/trac] (I think there are possibly still more bugs to be discovered), and will be included in the forthcoming BOINC v6.6.17 (not yet available for public download). People like Carl who have set a 10-day cache may, after the release of v6.6.17, suddently start getting what they wished for - which could be a bit of a shock to the system! Just reinforcing your very sensible advice to turn down those massive cache settings.

Gundolf Jahn
Gundolf Jahn
Joined: 1 Mar 05
Posts: 1,079
Credit: 341,280
RAC: 0

RE: RE: I noticed a few

Message 49924 in response to message 49922

Quote:
Quote:
I noticed a few had comp errors. I don't know how common this is so I pretty much ignore it.

It's not normal to have these errors and you certainly shouldn't ignore them. Assuming that the Phenom host is indeed your CUDA host, you need to resolve how to get the CUDA app to play nicely with the CPU tasks and there are probably pointers on how to do this over at Seti. I have no experience of how to configure things to work properly.


It's not necessarily a CUDA problem, since most of the tasks errered out while downloading:

app_version download error: couldn't get input files:

einstein_S5R5_3.01_windows_intelx86_0.exe
-200

Though that might be solved, as Carl Johnson seems to have reset the project (one Client detached error on 19 Mar 2009 2:54:46 UTC).

Gruß,
Gundolf

Computer sind nicht alles im Leben. (Kleiner Scherz)

Carl Johnson[SETI.USA]
Carl Johnson[SE...
Joined: 27 Jan 06
Posts: 5
Credit: 7,545,838
RAC: 0

RE: ...Just reinforcing

Message 49925 in response to message 49923

Quote:
...Just reinforcing your very sensible advice to turn down those massive cache settings.

I have scaled this back, but it is probably because it starts low and since I can complete the work in a day or two it would up the setting, and it would never get that much so it kept rising. If it actually works as it is intended to, then I would notice a lot of WUs not being completed and scale it back.


Carl Johnson[SETI.USA]
Carl Johnson[SE...
Joined: 27 Jan 06
Posts: 5
Credit: 7,545,838
RAC: 0

RE: It's not necessarily a

Message 49926 in response to message 49924

Quote:

It's not necessarily a CUDA problem, since most of the tasks errered out while downloading:
app_version download error: couldn't get input files:

einstein_S5R5_3.01_windows_intelx86_0.exe
-200

Though that might be solved, as Carl Johnson seems to have reset the project (one Client detached error on 19 Mar 2009 2:54:46 UTC).

Gruß,
Gundolf

I see this too, how do you detach from a task?


Gundolf Jahn
Gundolf Jahn
Joined: 1 Mar 05
Posts: 1,079
Credit: 341,280
RAC: 0

RE: I see this too, how do

Message 49927 in response to message 49926

Quote:
I see this too, how do you detach from a task?


You don't detach from a task, you can abort them, if something isn't okay with it (deadline trouble for instance).

You can detach from a project (or reset it). If you do so, all related files including unfinished/unreported tasks, are deleted. If you reattach, all executables and data files must be downloaded again. So, the main purpose of detaching is to get rid of defective such files.

Gruß,
Gundolf

Computer sind nicht alles im Leben. (Kleiner Scherz)

Carl Johnson[SETI.USA]
Carl Johnson[SE...
Joined: 27 Jan 06
Posts: 5
Credit: 7,545,838
RAC: 0

http://einstein.phys.uwm.edu/

http://einsteinathome.org/host/1857862/tasks

It says client detached. I never detached or reset, but I did reinstall version 6.4.7.


Comment viewing options

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