Bernd, Bruce, Gary, Mike, a question for you!

J Langley
J Langley
Joined: 30 Dec 05
Posts: 50
Credit: 58338
RAC: 0

RE: Unfortunately we found

Message 40797 in response to message 40796

Quote:

Unfortunately we found we need to (at least the largest tables), to keep the server responsive. Having not much experience with DBs of this size I'm inclined to push the blame to MySQL

That MySQL is not lightning fast sounds reasonable. I work with DB2, but that costs $$$.

Quote:

We already modified the scheduler to give shorter Tasks to slower machines. However our modifications only shift proababilities, you can't completely avoid to give a long Task to a slow machine or vice versa.

Thanks for the response. It appears (I haven't checked the BOINC code) that the scheduler only takes into consideration the speed of the CPU, (and maybe the % time BOINC is running when the computer is switched on?), and not how many hours per day the computer is on, nor how many of those hours the computer is crunching for other projects; which means its efforts to match WUs to hosts are better than nothing, but not as good they might be.

I'll be staying with E@H, but I don't think I'll be downloading any more E@H WUs until I've finished my current Seasonal Attribution WUs, or the app gets optimized and reduces teh crunch time (it's just too much effort for me to ensure no WU misses the deadline otherwise).

Quote:

at the end of the LSC S5 science run we'll hopefully have more data to analyze than the intermediate set we are using now, so the data files for the next run will rather become larger.

Hopefully by then I'll have a new PC, and so the problem will be reduced.

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9352143
RAC: 0

RE: Unfortunately we found

Message 40798 in response to message 40796

Quote:

Unfortunately we found we need to (at least the largest tables),

Doubelling the deadline also roughy doubles the size of the DB - we did this once about a year ago.

Yes, this has been discussed over at SAH several times in the past, and the bottom line was that extending the deadline seems like an easy out, but can bring the backend to it's knees in a hurry! ;-)

Quote:


We already modified the scheduler to give shorter Tasks to slower machines. However our modifications only shift proababilities, you can't completely avoid to give a long Task to a slow machine or vice versa.

We might be able to bind the datafile to the hosts download rate in a similar way, but I'm afraid that might also require to change e.g. the Workunit Generator. I'll take a look at that, but I doubt that I come to that in the next few weeks. However, in the longer term - volunteer computing is a great concept, and the number of BOINC projects is continously growing. It might be that with a dialup connection Einstein@Home is not the best way to contribute your computing power to bleeding-edge science. My crystal ball is not very clear, but at the end of the LSC S5 science run we'll hopefully have more data to analyze than the intermediate set we are using now, so the data files for the next run will rather become larger.

BM

With regard to slower hosts, my experience is ~500 MHz class K6-2 and P-III's will make the 2 week deadline, but you should plan on having to run them at least 17-18 hours a day minimum to do it for the long results.

As far as bigger data packs go, no problem there for me. Mine may be slow, but they have big drives with plenty of free space! :-)

Alinator

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.