Welcome to MilkyWay@home

Posts by Honza

21) Message boards : Number crunching : 8 Workunit limit (Message 4715)
Posted 15 Aug 2008 by Honza
Post:
ok i've changed the deadline to 2 days.
This is bad - it makes the project suitable only for hosts running 24/7. Imagine office boxes being turned off over the weekend - all WUs downloaded (and some partially computed) on Friday will be lost and wasted. Even those finished on Friday and not reported immediately will be lost.

Sorry if I missed some part of discussion as I wasn't on discussion lately but that's my point.

(I'm running some boxes 24/7 but for other 20 office boxes it is not a good choice.)
22) Message boards : Number crunching : More Work !!! Please :) (Message 2533)
Posted 23 Mar 2008 by Honza
Post:
But we're working on this! As i said Travis is implementing a line search and I'm trying to link one of the other servers on our network to the current one to run a second assimilator. Since the assimilator is a disk bound process it basically needs a fast hard drive. So either we're going to have to move the sql server to a separate machine or start one just to run a second feeder, deleter, assimilator...etc.

Can you give us a bit more info on what ahrdware is Milky running?
I have had a question on how close we are to limit of the server before...so now I had answer - it's close.
23) Message boards : Number crunching : GECCO2008 paper accepted (Message 2400)
Posted 19 Mar 2008 by Honza
Post:
Thanks for the answers, Travis, much appreciated.
24) Message boards : Number crunching : Smooth sailing-Quiet board (Message 2398)
Posted 19 Mar 2008 by Honza
Post:
I agree Cori, I've been getting a steady stream of work the last day or so.

Spoken too soon - no work to download and my machines are getting dry on Milky.
25) Message boards : Number crunching : 20 workunit limit (Message 2380)
Posted 19 Mar 2008 by Honza
Post:
As has been said above, the project needs to set it's parameters according to science.

Not every project is for every computer - and should not be.
Finishing 200-years Spin-up model on CPDN will take me about 4 months of C2Q running 24/7. Or it would have been a year+ on C2D office machine. Or 3-5 years on laptop.
Not every machine is up to the job that a particular project requires and that's OK.
26) Message boards : Number crunching : 20 workunit limit (Message 2370)
Posted 18 Mar 2008 by Honza
Post:
My quads (stock speed) are doing 0.03 days of turn-around time. If there were no down times and 20 minutes limit for another scheduler connection, turn-around time would be ~8 minutes. That's it - 8 minutes or 0.006 days.

I've raised question of several islands in GECCO2008 paper accepted, so far without answer.
27) Message boards : Number crunching : 20 workunit limit (Message 2344)
Posted 18 Mar 2008 by Honza
Post:
Perhaps wasting work, or even the lax deadlines aren't that much of a problem. The server could send out WUs in progress again to new users if it hasn't gotten results after a certain amount of time. The result that arrives later will simply be ignored, but credit still granted. Since computers are fickle and the WUs are short, this could mean the difference between a few hours and a few days...

BOINC has feature to abort task that are no longer needed (quorum met for example). It is a server side feature, not client (like cancel those beyond deadline).

A smart way would be to feed fast hosts with more work a slow onces with less amount. A fast host is the one with low turn-around time, slow one is the one that sents results back late.
Note that slow one may a be quad that gets turned off or is overworked with other tasks meeting deadline. It is not only about FLOPs.

EDIT: What is a general turn-around time per Wu?
28) Message boards : Number crunching : GECCO2008 paper accepted (Message 2316)
Posted 17 Mar 2008 by Honza
Post:
I would think a minimum "work unit crunch time" suggestion pointing out the "real time" model updating as a qualifier for computers for this project so people with slow units do not waste their time and your server space with outdated results would be needed.
Well, turn-around time would be best figure to use.
One may have fast host, finish WUs quickly but doesn't report back.

So people with fast machines and Report Result Immediately feature in Boinc core would be most effective.
29) Message boards : Number crunching : GECCO2008 paper accepted (Message 2274)
Posted 15 Mar 2008 by Honza
Post:
Thanks for the paper made available.

From reading it, I got the feeling that returning results ASAP is essential for both effectivity and quality of results as a project.

There are also couple of question arised from the reading.
If you find them interseting/meaningful and have time to answer...

It may be considered of benefit by users if their results shows fitness (alike Rosetta).

Another consideration: would it be possible that application itself generates double shot it's children from parents? This would reduce db size and server load. Client would report only results of a better fitness. Or we are not to use double shot but rather probabilistic simplex operator which is more effective?

Is there any data that evaulate return time and quality? I know it only takes more iteration to get the quality (as in the case of BlueGene vs. BOINC) but anyway...
EDIT: OK, I guess the question should have been rather number of evaulation rather then return time...so find the answer in paper.

How far/close are we to the limit of a single server. How close are we to the point where more island would be needed?
30) Message boards : Number crunching : More Work !!! Please :) (Message 2211)
Posted 13 Mar 2008 by Honza
Post:
Yeah, something like 5.000+ WUs a day would be enough for my machines.
31) Message boards : Number crunching : application v1.21/v1.22 errors/memory leaks/crashes here (Message 2022)
Posted 7 Mar 2008 by Honza
Post:
Dave compiled the 1.21 windows apps, so i'll have him take a look into these.

Running one quad on Win XP, other two are Win 2003 x64. Both 1.21 apps fine, no significant speed difference on 32-bit vs. 64-bit.



Previous 20

©2019 Astroinformatics Group