FM@H up and running
log in

Advanced search

Message boards : News : FM@H up and running

Author Message
Ant Chubb
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 18 Jul 12
Posts: 118
Credit: 1,019,875
RAC: 0
Message 17 - Posted: 20 Jul 2012, 18:08:58 UTC

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

Chris Granger
Send message
Joined: 19 Jul 12
Posts: 21
Credit: 726,988
RAC: 0
Message 18 - Posted: 20 Jul 2012, 18:27:13 UTC

Fantastic. It's always great to see a new medical project to crunch for. I wish you much success!

frankhagen
Send message
Joined: 15 Jul 12
Posts: 48
Credit: 400,146
RAC: 0
Message 19 - Posted: 20 Jul 2012, 20:01:19 UTC - in response to Message 18.

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.

Profile ritterm
Avatar
Send message
Joined: 18 Jul 12
Posts: 13
Credit: 138,526
RAC: 0
Message 20 - Posted: 21 Jul 2012, 1:54:45 UTC - in response to Message 17.

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

Kevin
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 4 Feb 12
Posts: 147
Credit: 2,427,829
RAC: 0
Message 23 - Posted: 21 Jul 2012, 13:35:01 UTC

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

Conan
Avatar
Send message
Joined: 20 Jul 12
Posts: 31
Credit: 451,033
RAC: 0
Message 27 - Posted: 21 Jul 2012, 15:59:39 UTC
Last modified: 21 Jul 2012, 16:00:56 UTC

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

Pwrguru [TeaM]
Send message
Joined: 18 Jul 12
Posts: 3
Credit: 1,119,881
RAC: 0
Message 29 - Posted: 22 Jul 2012, 15:49:49 UTC

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...

Ant Chubb
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 18 Jul 12
Posts: 118
Credit: 1,019,875
RAC: 0
Message 47 - Posted: 25 Jul 2012, 11:01:10 UTC - in response to Message 29.

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.

ChertseyAl
Send message
Joined: 12 Jul 12
Posts: 20
Credit: 100,448
RAC: 0
Message 49 - Posted: 25 Jul 2012, 12:12:01 UTC - in response to Message 47.

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.

Ant Chubb
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 18 Jul 12
Posts: 118
Credit: 1,019,875
RAC: 0
Message 50 - Posted: 25 Jul 2012, 13:07:35 UTC - in response to Message 49.

Thanks Al.

Will do.

ciao,
Ant

frankhagen
Send message
Joined: 15 Jul 12
Posts: 48
Credit: 400,146
RAC: 0
Message 51 - Posted: 25 Jul 2012, 13:17:39 UTC - in response to Message 47.

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.

Conan
Avatar
Send message
Joined: 20 Jul 12
Posts: 31
Credit: 451,033
RAC: 0
Message 52 - Posted: 25 Jul 2012, 13:39:47 UTC

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

Message boards : News : FM@H up and running


Main page · Your account · Message boards


Copyright © 2017 Dr Anthony Chubb