Estimate on How Long We're Going to be Out of CurieDock WUs :)

Message boards : Number crunching : Estimate on How Long We're Going to be Out of CurieDock WUs :)
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Steve Dodd

Send message
Joined: 24 Oct 20
Posts: 5
Credit: 6,335,145
RAC: 0
Message 328 - Posted: 23 Dec 2020, 4:43:18 UTC

Title says it all.
ID: 328 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Natalia
Volunteer moderator
Project administrator
Project developer
Project scientist

Send message
Joined: 9 Oct 20
Posts: 185
Credit: 2,782,517
RAC: 142
Message 329 - Posted: 23 Dec 2020, 7:15:42 UTC - in response to Message 328.  

We are creating new WUs in half an hour. We are sorry for inconveniences. It will take a while to adapt to the growing number of participants/computers, while server's disc capacity is limited.
ID: 329 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
[SG] Felix

Send message
Joined: 5 Dec 20
Posts: 8
Credit: 2,973,433
RAC: 4,172
Message 330 - Posted: 23 Dec 2020, 10:55:05 UTC

it would help, if everybody would load just the amount of wus, which he can calculate at once + maybe the same amount for buffer.
ID: 330 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Jim1348

Send message
Joined: 30 Oct 20
Posts: 57
Credit: 9,112,528
RAC: 0
Message 332 - Posted: 23 Dec 2020, 14:50:08 UTC - in response to Message 330.  

it would help, if everybody would load just the amount of wus, which he can calculate at once + maybe the same amount for buffer.

Yes. Keeping a large buffer just delays the project for everyone. I normally use the default of 0.1 + 0.5 days for work units of normal length.
That works fine with this project.
ID: 332 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
[SG] Felix

Send message
Joined: 5 Dec 20
Posts: 8
Credit: 2,973,433
RAC: 4,172
Message 333 - Posted: 23 Dec 2020, 16:26:36 UTC - in response to Message 332.  

Yes. Keeping a large buffer just delays the project for everyone. I normally use the default of 0.1 + 0.5 days for work units of normal length.
That works fine with this project.


I usually have 0 + 0 days and a backup project with ressource share 0, works fine
ID: 333 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Jim1348

Send message
Joined: 30 Oct 20
Posts: 57
Credit: 9,112,528
RAC: 0
Message 336 - Posted: 24 Dec 2020, 0:16:32 UTC - in response to Message 333.  
Last modified: 24 Dec 2020, 0:21:32 UTC

I usually have 0 + 0 days and a backup project with ressource share 0, works fine

That certainly minimizes the work units to the minimum possible. But the reason for a buffer is to also reduce the load on the server so that it does not have to be accessed for each work unit.
I don't know if that is an important consideration for the servers on this project or not, but that was the original idea I believe, in addition to giving you some cushion in case of a server outage of course.
ID: 336 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Crystal Pellet

Send message
Joined: 26 Oct 20
Posts: 53
Credit: 2,520,836
RAC: 0
Message 337 - Posted: 24 Dec 2020, 7:40:52 UTC - in response to Message 336.  
Last modified: 24 Dec 2020, 7:41:35 UTC

I don't know if that is an important consideration for the servers on this project or not, but that was the original idea I believe, in addition to giving you some cushion in case of a server outage of course.
The workunits are sent with the flag <report_immediately/>, so the project wants them back asap.
When reported you'll get new tasks up to the server limit 2/thread.
ID: 337 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : Estimate on How Long We're Going to be Out of CurieDock WUs :)

©2024 SiDock@home Team