Posts by Mentor397

The workunits people are receiving are re-sends of timed out workunits from other user's accounts. They are not fresh workunits.

i find it somewhat ironic that a guy with less than 2 million credits
can tell a guy with over 31 million off like that.

Can you imagine that some folk that really bust their butts to keep stuff running most of their time also have a LIFE at a weekend that enables them to wind down and put up with the other stuff which happens when they are not there?

Matt, tks for the information,

But in fact, there are U/D load problems !

I have about 2000 WU to report each week ! And this only into 1 hour time due to the Intranet security. I reveive from the RDM 1 hour, once a week , open gateway to Seti. But when Seti is very slow, or offline it became problems ! I want to help the research.
Perhaps is it better to close Seti for a few days or weeks to solve all the problems.
All what it sended during server problems are into " fixing missing results ". But this server is out since the big crash in august.
I have now about 8.000 WU waiting for assimilation !!!
Each WU about 50 credits, it become about 400,000 credits !!!

And of course , when I connect and can receive new WU, they are also calculated. The final result is when i start the U / D load, your server receive much more information than it is capable to proceed. Weare more than 1,000,000 with the same problem !!! Of course when the server receive at the same time so much request, it can not proceed because the overload !!!

It is a snowball effect !!! Only Seti team can solve it. Then DO IT !!!!!
Instead of trying to repair "broken arrows " !

I was going to get some programming done today but Dave needed php upgraded on the BOINC server, which was running Fedora Core 6. FC6 didn't have a sufficiently advanced php in its repositories, so this was as good a time as any to yum the system up to Fedora Core 7. This was slow, but worked like a charm.

Except I then realized the trac system (used for BOINC's web based public software development) was toasted due to the upgrade. It took over two hours of hair pulling, scouring log files, removing/reinstalling various software packages, poring through barely informative pages only found in Google's cache.. I don't really understand how what we ultimately did fixed the problem, but we seem to be out of the woods, more or less.

I hate to say it, but trac is written in python, and I've never had any positive experiences with this programming language. Every six months some random python program explodes as it is utterly sensitive to version upgrades, and tracing the problems is impossible as the code is difficult to read and scoured all over the system in vaguely named files. Others keep trying to convince me python is the bee's knees, but I just can't see it. I started out writing raw machine code on my Apple II+, so to me C is the pinnacle of programming languages (not C++). I'll shut up now before I further offend python programmers/developers.

- Matt

You can set a very low resource share for a backup project, i.e. Seti 100:1 backup, or even 100,000:1. The BOINC manager will ensure the initial backup units are crunched on time, at the expense of making the Long Term Credit (LTD) a large -ve number, so that under normal circumstances BOINC will not download from the backup project unless Seti is down and BOINC decides you need more work.

I like what Seti@home is doing, No other project is doing anything like this with so many people.

But sometimes i wonder if we're doing anything helpful..seems like Seti@home is ALWAYS having server problems, and thus people going to a more stable project like Folding@home.

I know nothing is always 100% uptime in the computer world, but wow so many problems..


Anyways, i still cant attach to the project, says its not available.

Having a short/zero cache doesn't seem to imply an increase in the loading on the servers. People may fear that the user base would make repeated wu requests and clobber the servers that way. However, a request/download cycle should be considerable faster than a wu compute time, and sequential mulitple downloads should be faster than a repeated request/download cycle. So perhaps the servers should determine an optimal number of wu's to download for each request, based on recent loading and the client's recent performance.

Lastly, would someone kindly tell me, without delivering a doctoral dissertation on the subject, the name of one BOINC physics project and one BOINC biology project that will work well with SETI@home without wasting too much time, power, and wear and tear to complete work units whose shelf life expires during outages?