1) Forums : General Topics : Suggestions, Concerns, and Requests (Message 10084)
Posted 12 Feb 2012 by Profile Cosmo Joe
robertmiles said,
In short, Leave application to memory...

I agree. If you run a windows machine, you are best leaving it in memory, but if you run a linux/mac/BSD/unix machine, you can run the CPU crunching 100% of the time and use the "nice" command to ensure everything else has priority over BOINC, this way, your computer is always responsive when you need it.

One thing I'd like to point out is that repeatedly, I see in many projects low-hanging fruit that is easy to fix and should be taken care of right at the beginning when you code a routine or anything.

1) For every open of one sort or another, you should have a matching close somewhere down the line. If you are opening files, you should also do a flush before you close since you can't guarantee a close will close, but with a flush, you can do some alternate work, like wait a moment, or place the file somewhere else or something.

2) A lot of commands return error codes, and you should make use of them. frequently, I see blind calls being done with the expectation of 100% completion. I noted a simple check for an error can help reduce the number of complaints about bug X or bug Y if you simply check for an error, and do something about it, for example, people with smaller machines will get errors when a program does malloc() (returns zero), but the program blindly assumes there is a valid result, which isn't always the case. If you check for errors, you'll be a bit more solid, with fewer bug reports.

Sometimes seeing what I mean may help explain this better, so if you need an example, you could use this (you'll note matched opens/flush/closes, and checks for possible errors everywhere that it could happen:

It's just some things I've noted over and over again, and hopefully you find the advice helpful.
2) Forums : Technical Support : 17 hour WU for 420 credits.............. (Message 8680)
Posted 4 Nov 2009 by Profile Cosmo Joe
Wow! 266 MhZ Celeron is quite a workhorse. I still got mine around now, but ever since moving my last important program from it to my normal computer now. That machine has rarely been turned on ( Sempron ).
I read several threads and, well, although boinc is supposed to make use of idle CPU time, seems some people are all about the credits - it's got to have more GPUs now - hehehe.

Like yourself, I've also noted that the checkpoints are far apart and had to re adjust my switch time from default to now 3 hours per application, otherwise Cosmo spends most of it's time restarting from the last checkpoint or something which appears to look like starting over again each time it starts. I'm only watching periodically right now since switching to the latest BOINC and was puzzled at lack of completing WUs in the past, otherwise, just let it run unattended.

If anyone has trouble, I suggest longer times between switching appears to help.
3) Forums : Technical Support : Errors and white screens bad files (Message 8660)
Posted 26 Oct 2009 by Profile Cosmo Joe
Spoke too soon. Looks like I got bitten by this bug as well.

I looked at BOINC while doing a download from Cosmology, 0 bytes arrived.

Observing the problem here, there are at minimum 2 bugs in BOINC.

1st, the BOINC manager is running into a problem with a file holding 0 bytes, so it is probably a divide by zero error happening somewhere while trying to show graphics.

2nd, the BOINC client ran for a while steadily crunching numbers on einstein and now refuses to run further, so I'm assuming it switched to the cosmology project now, and is having problems with 0 bytes as well.

These 2 problems need to be figured-out regardless of cosmology because you don't want BOINC to break regardless of if the client project is broken or not.

Anyone interested in looking at BOINC, it's here: BOINC SVN

I don't know if Cosmology source code is available.
4) Forums : Technical Support : Errors and white screens bad files (Message 8656)
Posted 25 Oct 2009 by Profile Cosmo Joe
There have been consistent improvements made to BOINC, however, checking for errors is something easily forgotten and therefore there are bugs opened and reopened to fix bugs when found.
For example, I posted this bug: BOINC bug#921
however this bug is far more important: BOINC bug#240

In summary, if you are running an older version of BOINC, please think of upgrading to the latest version. You get new features, but more importantly, more bugs are fixed.

Cosmology may have similar problems where calls should be checked for possible errors. Anyone interested at looking at the source code should report bugs if they find them, and eventually later crunching software will make it's way to your computer when updates happen.
5) Forums : Technical Support : Memory workload (Message 8651)
Posted 21 Oct 2009 by Profile Cosmo Joe

So far I have found that the board claims to support only DDR2 667/800, not 1066. I would guess that if you put in faster memory it would only run at the maximum supported speed, but don't know for sure...

Also, I found a review that stated that 8GB is supported with 667, but only 4GB with 800.

I do recall from electronics that desktop and laptop computers use dynamic RAM which is cheaper and denser to produce than static RAM. Unfortunately, the trade-off is that dynamic RAM needs to be periodically refreshed, so using the values above it tends to make some sense as well.

With the 800 built for faster computers, the RAM needs to be refreshed quicker otherwise it loses it's charge and therefore the values in RAM, that should help explain why you need 667 for 8GB (slower to use but also slower to discharge), while the 800 is only useful for 4GB (faster, but also faster to discharge into random values ...and I would suspect that 1066 will even discharge quicker).

In summary, faster isn't always better, so try to choose the right RAM for the motherboard in question.

Other things to consider is another article I just read today... counterfeiters are getting more adept at inserting counterfeit parts parts into distribution, so you may not necessarily get what you asked for - so check carefully.

In terms of the MSI motherboards, check if you have the latest BIOS updates. I've managed to get a few people from motherboard hell by getting them to update their BIOS. I think operating systems may be beginning to trust BIOS a bit more, therefore might not necessarily be doing checks as rigidly as in the past, however, there are going to be plenty of motherboards which still fit in this time frame that need their motherboards updated. See this article (which created quite a bit of a stir/shakeup with BIOS manufacturers to put them more on the "honest" path of their own specs) here if you're not sure what I mean update your BIOS!
Slashdot article = MoBo Manufacturer Foxconn Refuses To Support Linux
6) Forums : General Topics : Why do you participate in Cosmology@Home? Who is the \"most surprising\" participant? (Message 8637)
Posted 18 Oct 2009 by Profile Cosmo Joe
Some projects seem related to medicines but when you look at the eventual results, they aren't benefitting everybody, they only benefit shareholders and stake-holders for where that medicine will get produced. In summary they can be supported and financed by big-medicine since it only benefits them and their shareholders. No point in me volunteering my time or resources for someone else's benefit and profit.

Projects like SETI, Einstien, Cosmology, Milkyway are the types of projects that are not resulting in money(profit) but are always struggling along on a shoestring budget, yet it benefits everybody. This makes sense for me to volunteer my time or resources because "Everybody" benefits in the results.

BOINC is a worthwhile project making use of "spare" CPU cycles, and projects like BOINC require little effort on the part of us volunteers to donate what would otherwise be wasted CPU heat running idle computers waiting for the next mouse click or keyboard tap.
7) Forums : Wish list : Optimized Applications (Message 8636)
Posted 17 Oct 2009 by Profile Cosmo Joe
I suggest looking at the gcc optimization flags so that you can optimize based on CPU.
This would mean that specific parts of your code would need to be separated-out where 99% of your crunching happens, so instead of:

Let's call it a file called "crunch.c"

it would break-up into...

crunch_AMD.c (set gcc flags to optimize for AMD)
crunch_Intel.c (set gcc flags to optimize for Intel)
if someone decides to do these other processors...

and you would need a CPU indentify routine like:
[color=green]if (recognize CPU as AMD)
  do stuff in crunch_AMD.c
  if (recognize CPU as Intel)
    do stuff in crunch_Intel.c
    do generic crunch.c stuff

8) Forums : Technical Support : Memory workload (Message 8635)
Posted 17 Oct 2009 by Profile Cosmo Joe
I'm also another old PC user (by today's standards for Cosmo) at 768MB of RAM minus what's needed for screen display. I've been hitting a couple of zeros on Cosmo lately so I've been watching this last work unit.

Memory requirements keep bouncing up and down as it processes the work. Sometimes it,s 90MBx3, other times 216MBx3, right now it's stopped at 697MB required which puts it way beyond my RAM memory. KDE system monitor reports 3 sets of cosmology units at a time (when it ran), so I'm guessing one in RAM and 2 in swap if they didn't fit in RAM. Like someone else mentioned on an earlier post, when you begin using swap, the computer becomes sluggish, and I've had a couple of crashes from X which I first thought was X but now suspect may be caused by Cosmology needing a lot of memory (plus X not being smart enough to verify alloc() before use).

Is there any way to break these work units into smaller packages?
I've noted that since the current work unit jumps through various memory requirements, if it's possible to leave the smaller mem required crunching for older machines and let the computers with large RAM crunch the rest of the unit.
This may be a bit harsher on your server - and it may make sense if you don't get enough volunteers due to the memory requirements - however if you have more than enough volunteers for the work available, probably just leave the limits as they are now.

---------------(other topic in this thread).
In message 8424
There's some mention of gcc and Intel's compilers.
I recall in the past where you could compile different *.c files to different options. I would suggest compiling some files to generic optimizations, files associated to AMD to use AMD optimizations, and files optimized for Intel to Intel optimizations, then link the whole thing together and let the program branch to the Intel/AMD optimized sections. This could keep your boinc program generic and avoid the problem of people with other processors having to use optimized packages based on their CPUs.