Might you be talking about user "disturbthepeace"? I noticed that host had some trouble on the 24th.
Many download errors.
I myself have goofed before and caused 8 tasks to error out with one mouse click. So the occasional goof might be expected. It is a good move to limit the damages possible.
It might sort of limit some of the fast computers with 16 & greater cpus like xPod and someothers.
It might sort of limit some of the fast computers with 16 & greater cpus like xPod and someothers.
The quota is per CPU/core, physical or virtual (P4 with HT will have a total quota of 72). About xPod, his 16 core rigs will have quotas of 576, thats just enough. =)
It might sort of limit some of the fast computers with 16 & greater cpus like xPod and someothers.
The quota is per CPU/core, physical or virtual (P4 with HT will have a total quota of 72). About xPod, his 16 core rigs will have quotas of 576, thats just enough. =)
With the runtimes such as they are, I can only chug through 2/day on my system (Athlon 64 3700+ that's overclocked to approximately an FX-57), so even if I had 8 times the horsepower (or smaller units), I'd still only be churning through 16/day. When you think of it that way, 36/core/day is still quite generous...
I never new exactly what that quota meant : per machine or per core/cpu. Now I know; thx. 36 is definitely more than generous (or even possible to get anywhere near now).
It might sort of limit some of the fast computers with 16 & greater cpus like xPod and someothers.
The quota is per CPU/core, physical or virtual (P4 with HT will have a total quota of 72). About xPod, his 16 core rigs will have quotas of 576, thats just enough. =)
Unless they've changed something server side here, it's up to a max of 4 cores. So the daily quota for quad cores and bigger is 144.
We lowered the daily quota again to 16. Kathryn is right, it's per core with a limit of 4 cores, so the maximum quota (per day) is 64.
BM
Out of curiosity, why did you lower it again? Does this mean that you're not expecting any further optimization for the Macs? Peanut's system can do 32-40/day as it is right now...
Out of curiosity, why did you lower it again? Does this mean that you're not expecting any further optimization for the Macs? Peanut's system can do 32-40/day as it is right now...
The reason is given in the existence of this parameter; se my initial post on this thread. Currently a rather small amount of machines is responsible for the relatively high failure rates we are facing.
I don't expect optimization beyond what's in the current MacOS Intel App for the next months. I'll be busy fixing bugs and getting this code to work on other architectures.
Currently a rather small amount of machines is responsible for the relatively high failure rates we are facing.
I knew the initial reason that you moved from 72 to 36. My question was in regards to the second reduction from 36 to 16.
Anyway, shouldn't the individual host's daily quota back down on its' own due to error results? The only thing I can see that would be a problem with that is if a host has a string of error results, then one or two good results, then another string of error results. Is that what is happening?
Edit: Hmmm... thinking about this more, due to the way you're distributing the data packs, high failure rates are more of an issue because then there is the need to wait for another host with the same data set to get to it. So, I can see the reduction to 16 (64 total) then as a good thing.
Quote:
I don't expect optimization beyond what's in the current MacOS Intel App for the next months. I'll be busy fixing bugs and getting this code to work on other architectures.
Anyway, shouldn't the individual host's daily quota back down on its' own due to error results? The only thing I can see that would be a problem with that is if a host has a string of error results, then one or two good results, then another string of error results. Is that what is happening?
Sometimes.
Another thing is that hosts that have problems e.g. with their filesystems tend to forget their hostid, so they get a new one assigned. We also have a number of hosts that run in a kind of batch mode where BOINC is installed, runs a few tasks, and then is removed completely from the machine for a while.
Changed daily quota
)
Might you be talking about user "disturbthepeace"? I noticed that host had some trouble on the 24th.
Many download errors.
I myself have goofed before and caused 8 tasks to error out with one mouse click. So the occasional goof might be expected. It is a good move to limit the damages possible.
It might sort of limit some of the fast computers with 16 & greater cpus like xPod and someothers.
RE: It might sort of limit
)
The quota is per CPU/core, physical or virtual (P4 with HT will have a total quota of 72). About xPod, his 16 core rigs will have quotas of 576, thats just enough. =)
Team Philippines
RE: RE: It might sort of
)
With the runtimes such as they are, I can only chug through 2/day on my system (Athlon 64 3700+ that's overclocked to approximately an FX-57), so even if I had 8 times the horsepower (or smaller units), I'd still only be churning through 16/day. When you think of it that way, 36/core/day is still quite generous...
I never new exactly what that
)
I never new exactly what that quota meant : per machine or per core/cpu. Now I know; thx. 36 is definitely more than generous (or even possible to get anywhere near now).
RE: RE: It might sort of
)
Unless they've changed something server side here, it's up to a max of 4 cores. So the daily quota for quad cores and bigger is 144.
Kathryn :o)
Einstein@Home Moderator
We lowered the daily quota
)
We lowered the daily quota again to 16. Kathryn is right, it's per core with a limit of 4 cores, so the maximum quota (per day) is 64.
BM
BM
RE: We lowered the daily
)
Out of curiosity, why did you lower it again? Does this mean that you're not expecting any further optimization for the Macs? Peanut's system can do 32-40/day as it is right now...
RE: Out of curiosity, why
)
The reason is given in the existence of this parameter; se my initial post on this thread. Currently a rather small amount of machines is responsible for the relatively high failure rates we are facing.
I don't expect optimization beyond what's in the current MacOS Intel App for the next months. I'll be busy fixing bugs and getting this code to work on other architectures.
BM
BM
RE: Currently a rather
)
I knew the initial reason that you moved from 72 to 36. My question was in regards to the second reduction from 36 to 16.
Anyway, shouldn't the individual host's daily quota back down on its' own due to error results? The only thing I can see that would be a problem with that is if a host has a string of error results, then one or two good results, then another string of error results. Is that what is happening?
Edit: Hmmm... thinking about this more, due to the way you're distributing the data packs, high failure rates are more of an issue because then there is the need to wait for another host with the same data set to get to it. So, I can see the reduction to 16 (64 total) then as a good thing.
Sounds like a plan...
RE: Anyway, shouldn't the
)
Sometimes.
Another thing is that hosts that have problems e.g. with their filesystems tend to forget their hostid, so they get a new one assigned. We also have a number of hosts that run in a kind of batch mode where BOINC is installed, runs a few tasks, and then is removed completely from the machine for a while.
BM
BM