We have just fired off the first 144,000 docking runs.
If you'd like to see the details behind the 1,000,000,000 docking runs planned, please go to the 'Idea' page on our website:
http://www.fight-malaria.org/index.php?option=com_content&view=article&id=99&Itemid=108
After the first 94 million docking runs, we'll have achieved our first major milestone.
We may have a small delay next week between experiments, then it's all systems go.
Thanks again for your your help with this.
ciao,
Ant
/ 
Reply
Quote
Fantastic. It's always great to see a new medical project to crunch for. I wish you much success!
/ Reply
Quote
OMFG!
2 of my hosts got flooded with wu's - and i mean flooded. i had to abort hundreds of wu's. :(
set a limit for task in progress on a host!
oh, and btw.: estimated flops is way too low.
/ Reply
Quote
We have just fired off the first 144,000 docking runs...
Outstanding...Crunching on, well, a LOT of new tasks! :D
oh, and btw.: estimated flops is way too low.
@frank: Perhaps I misunderstand, but the estimated time for WU completion on my hosts is actually too *long* right now. Isn't that the opposite of what you seem to be experiencing?
Gruss,
MarkR
/ Reply
Quote
Project developer
Project tester
Project scientist
Send message
Joined: 4 Feb 12
Posts: 103
Credit: 1,003,053
RAC: 780
Thanks for your comments. We will reduce the number of tasks per host for the second batch of tasks. This will be launched next week.
Our current flops estimate is the average of a sample of workunits. However, the runtime for each workunit is highly variable. This is influenced by several factors such as number of rotatable bonds and size of the ligand.
Thanks,
Kevin
/ Reply
Quote
I don't know what the number of tasks is that a host can have but as they are all have very short run times and over a week to do them I can't see it being a real problem.
I have been able to download over 1,200 jobs across 4 machines today and nearly half of them are already done even as I also process 3 other projects.
So What is the limit of tasks per host?
Conan
/ Reply
Quote
I have to agree with Conan on this... With a week to run such short tasks, I want more instead of less.... I downloaded close to 20k worth of work and except for some slower quad core computers most of the work is already gone...
/ Reply
Quote
Hi Conan et al,
I'm a newbie to the BOINC world, as this is our first project. On one of the other forums a user complained about too many tasks flooding his system, so he aborted them. This then caused problems for Kevin, who had to clean up the mess. We then reduced the number of jobs per CPU (it's now at max 20 per CPU) which will hopefully reduce the bandwidth chatter between our server and yours (as in a fewer, larger workloads), but also not cause other users to freak out and abort everything that arrives on their machines. Another issue was that 30,000 jobs fired off over the weekend, but the results may take much longer to return. Slower computers then 'hog' the large list of jobs, while faster PCs were waiting for new work. So it seems to make more sense to me to have smaller packets of work go out more often, as these can then be directed towards faster computers more often.
Any advise here would be greatly appreciated.
ciao,
Ant
ps: Fear not - there are a ton of jobs to get through! We're just trying to get this right before cranking it up a notch.
/ Reply
Quote
On one of the other forums a user complained about too many tasks flooding his system, so he aborted them. This then caused problems for Kevin, who had to clean up the mess.
Hmmm. BOINC should handle that automatically and just add another replication. One thing it might be worth doing is setting the option that sends out aborted/failed WUs immediately to trusted hosts, so that they don't hang about until the queue runs dry. Can't remember where to set the flag ATM, but someone will be able to help. Actually, I think they turned that option on over at the asteroids@home project recently, you could look over there.
Oh, and with loads of small WUs flying about, keep and eye on your disc space as the results database will grow quickly :)
Cheers,
Al.
/ Reply
Quote
Thanks Al.
Will do.
ciao,
Ant
/ Reply
Quote
I'm a newbie to the BOINC world, as this is our first project. On one of the other forums a user complained about too many tasks flooding his system, so he aborted them. This then caused problems for Kevin, who had to clean up the mess.
it's not a mess produced by the users, but the way how work-distribution works.
you got a quad-core setup and a work-buffer of only half a day.
you hit a bunch of very short WU's, so the host keeps asking for more and more work. phase 1 finished, the host is sitting on 80 WU's.
then it suddenly steps on a real long one which takes 8 hours.
so now the host thinks he has a huge bunch of 160 hours of work to do and enters panic-mode juggling around WU's like mad. (bright design!)
but there is a way to prevent drama like this and several other projects took that step.
setup different queues for short, medium and long jobs and the problem is no longer there - unless a user decides to request work from more than one.
/ Reply
Quote
Thanks Ant,
That is working fine for me at the moment.
I have plenty of work as I also do other projects as well so I don't burn through all the shortish work units in a flash, they get done in between other jobs.
Conan
/ Reply
Quote