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.
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.
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.
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.
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)
...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.
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)
RE: Well right under
)
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.
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.
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 :-).
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.
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.
RE: I'm running SETI on
)
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.
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.
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.
RE: Well right under
)
@ 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.
RE: RE: I noticed a few
)
It's not necessarily a CUDA problem, since most of the tasks errered out while downloading:
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)
RE: ...Just reinforcing
)
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.
RE: It's not necessarily a
)
I see this too, how do you detach from a task?
RE: I see this too, how do
)
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)
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.