... 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.
Just try to connect more frequently or tell the BOINC to maintain additional cache of workunits for about 2 or 3 days. It will collect the volume you need for a while. Just trust me. I did it on Core Quad and it works. The cache grows slowly, but it grows.
Just try to connect more frequently or tell the BOINC to maintain additional cache of workunits for about 2 or 3 days. It will collect the volume you need for a while. Just trust me. I did it on Core Quad and it works. The cache grows slowly, but it grows.
For people on dial-up, changing the frequency is not always an option. Also, with an 8-way, it will go no more than 1.5 days with the current limit.
Just try to connect more frequently or tell the BOINC to maintain additional cache of workunits for about 2 or 3 days. It will collect the volume you need for a while. Just trust me. I did it on Core Quad and it works. The cache grows slowly, but it grows.
For people on dial-up, changing the frequency is not always an option. Also, with an 8-way, it will go no more than 1.5 days with the current limit.
I think that the best option would be to increase the 4-core limit up to 8, but keep the per-core at 16. This will take care of those of you with top end machines, allowing you to get 3 days worth in one shot, but still keeping the current cap in place for single/dual/quad, which is what the bulk of the users have... This would still preserve the project's need of reducing the amount of damage that bad hosts can cause... I know you still won't be able to "tank up" a large cache all at once, but I think that given the way the workunits are distributed here, it is better to err on the side of caution...
I think top machines will have wide enough connection to maintain full WU cache, and dial-up users usually have slower machines that can be happy even with 16 WU daily quota. Aren't them?
I think top machines will have wide enough connection to maintain full WU cache, and dial-up users usually have slower machines that can be happy even with 16 WU daily quota. Aren't them?
The quota is not related to network issues, at least not on the user side. The main rationale for limiting the quota is to prevent machines that have high failure rates (or worse: keep downloading lots of tasks but never sent back anything) from trashing lots of tasks and annoying wingmen who will have to wait for a second wingman to finish the re-sent tasks. It's kind of self-protection of the servers.
RE: ... We also have a
)
Maybe diskless without LAN folder : http://boincpe.schreiter.info/
.en version http://blog.schreiter.info/boincpe-livecd-for-boinc/lang/en/
RE: We lowered the daily
)
Now that the optimized apps are out, and reducing crunch time to almost 4 hours (YES!), can this please be increased a bit?
For example, my 8-way mac crunches a task in ~4.3 hours.
4.3 * 64 = 258
24 hrs * 8 CPUs = 192
That allows a queue of only 1.5 days max. Some folks want or need more than that.
Reno, NV Team: SETI.USA
Just try to connect more
)
Just try to connect more frequently or tell the BOINC to maintain additional cache of workunits for about 2 or 3 days. It will collect the volume you need for a while. Just trust me. I did it on Core Quad and it works. The cache grows slowly, but it grows.
RE: Just try to connect
)
For people on dial-up, changing the frequency is not always an option. Also, with an 8-way, it will go no more than 1.5 days with the current limit.
Reno, NV Team: SETI.USA
RE: RE: Just try to
)
I think that the best option would be to increase the 4-core limit up to 8, but keep the per-core at 16. This will take care of those of you with top end machines, allowing you to get 3 days worth in one shot, but still keeping the current cap in place for single/dual/quad, which is what the bulk of the users have... This would still preserve the project's need of reducing the amount of damage that bad hosts can cause... I know you still won't be able to "tank up" a large cache all at once, but I think that given the way the workunits are distributed here, it is better to err on the side of caution...
See, I can be agreeable sometimes... ;-P
RE: I think that the best
)
I agree. But I think the server version here is too old to go above the 4-core limit.
Reno, NV Team: SETI.USA
I think an overclocked 45nm
)
I think an overclocked 45nm CPU core is able to reach the 16WU/day limit.
I think top machines will
)
I think top machines will have wide enough connection to maintain full WU cache, and dial-up users usually have slower machines that can be happy even with 16 WU daily quota. Aren't them?
RE: I think top machines
)
The quota is not related to network issues, at least not on the user side. The main rationale for limiting the quota is to prevent machines that have high failure rates (or worse: keep downloading lots of tasks but never sent back anything) from trashing lots of tasks and annoying wingmen who will have to wait for a second wingman to finish the re-sent tasks. It's kind of self-protection of the servers.
CU
Bikeman