Slashdot Mirror
Team Slashdot leads SETI@Home
Rowag writes "Team Slashdot leads all the groups in SETI@Home data evaluation, with over 500 members and more than 6000 result packets chewed up so far. If it helps your team spirit, that's more than 2x the amount from 'Microsoft'. Those of you already signed up, let's keep those packets coming! For those that missed it before, if you've got clock cycles to spare, check it out!
" I hear there is is still a split and a redundant
Slashdot.org team- I suggest we just make this one official
so we can get more of a lead...
The update engine at setiathome has not been working correctly for at least a week. You'll find that individual totals don't come close to team totals. So, although Slashdot may be listed as number one, it's entirely possible that it is not.
Indeed, there are far more people participating than there is data to be processed. The site has already announced that they are re-sending data from a two or three day period to be processed again.
This is an interesting project, and I was involved early on with the Linux client. I don't believe that the organizers had any idea of how explosive the participation was going to be. I suppose that some people may perceive that as a bad thing (from a planning point of view), but I'm encouraged by it...besides, the Windows-based application has a cool looking screen saver!
No, I have completed a bunch of data blocks and as far as I can remember every single one has been from Jan 8. Is it a good idea to have 500,000 people doing the work of 50? It's absurd and SETI should tell us what's going on.
They mention on their web site that multiple clients may be working on the same chunk of data in order to cooberate results. If you keep shutting down the client and restarting it, it's no wonder it will assign you one you may have seen before - but aborted. SETI@home realizes that with the number of computers working on the process, they'll end up out of fresh data to give out, which is why they're duplicating it. I personally think it's a good idea.
I've reluctantly come to the conclusion that SETI@home's half million participants are currently being assigned the same 115 work units over and over again, all from three different sky locations collected on January 7 and 8. If anyone has seen any other work units recently -- especially from January 9 or later -- please speak up.
According to their web page, they are having problems with their "data pipeline" and that they hope to have it "fixed shortly".
O.K.,
Go to their web site and click on Groups. Then click on clubs and then Team Slashdot and then Join this group.
Better yet, just click HERE
Unfortunately it seems that the SETI@home team should've done a bit more testing before starting the project.
Posted on sci.astro:
Greetings!
My name is Jeff Thomas. I am volunteering as a liaison between the SETI@Home Team and the community of users. I live near Berkeley. My goal is to try to improve information flow both ways. I will try to ensure that information is posted on their web pages, and here, in a more timely fashion than has been the case. (It took me some time before I discovered the blank screen, and I worked on 9 subbands in 10 32 45 RA, +20 12 35 dec...) Let me pass along what I have learned:
1. The duplicate work units problem has been fixed. It resulted from disk-space limitations (how many WU's will fit on a floppy?....), which have been dealt with. The new servers will doubtless help even more. This was not a scam or a conn job or whatever. They fixed the problem as quickly as they could. They should certainly have let people know more prominently about the problem. They have been a bit clueless about the importance of communication. My goal is to help with that.
2. Server-connection problems have been greatly reduced, and should also be helped by the new servers.
3. When a WU is at a very small percentage complete, and then jumps to 100%, it is because large amounts of Earth-based radio-frequency interference (RFI) have been detected in the work unit.
4. The 97.x or 98.x percent complete is a result of the algorithm and roundin errors. When the client is done, it is 100% done.
5. Regarding lost work units, and lost credit for work units, yes this has occurred. The 1.0 client deletes its results when it thinks the server has gotten them, and there have been server crashes, so some stuff went into the bit bucket. Server and client improvements should eliminate this problem.
6. What will be fixed in the next client, due out next week, includes:
o The proxy bug (partial or full fix), to allow use of ports other than 80.
o CPU time can be incorrectly calculated on Windows. This will be fixed.
o There will be better messages.
o The "Click OK" problem will be fixed.
7. Regarding stats problems, let me first say that I hope the guys who programmed this did not write the science code! I do not understand the full story here, but the following tidbits of information might help. I know that they are working on getting this right.
o The client sends stats to the server, but it also gets them from the server.
o The server updates the stats on the web page on an hourly basis, except for the domain and team stats, which are updated daily.
8. Regarding the 99999 power spikes, these are the maximum because of a cut-off at 100000. The spikes just under 100000 are outliers as well. All for now. I hope that I can help improve the flow of information. I will be writing things up for the web pages, and sharing information with this and other groups.
-- Jeff Thomas
Instead of each project having to setup their own central servers, recruit people, work out authentication, stats etc... Why not create a generic client program that downloads plugins? You could have a SETI plugin, a primes plugin, RC5 plugin, and so on.
The generic client would install and validate each plugin and handle/encrypt the data traffic to a central server.
There would be a server component to this also, handling the web interface for stats and validating/receiving completed work from the clients.
Projects that wanted access to the distributed super computer would register with someone who had setup a server and distributed generic clients already. The project team would provide a plugin written to a specific API. The plugin actually does the work, it gets new work and transmits completed work through the API.
The generic client could notify you when new projects have been registered and give you the choice to download and prioritize the new project's plugin. (this way you could contribute effectively to multiple projects concurrently)
An extension of this would be to take it commercial as a way of selling your spare CPU cycles. The maker of a generic (commercial) distributed client could sell access to all the computers that run their client. Then you would get web goodies, points, discounts, etc based on how many total CPU cycles your machine(s) had contributed.
-josh
> Tell me, just how does varying the load of your CPU reduce the KWPH that your computer consumes?
> Last time I checked, never on a conventional PC.
Actually, real OSes (e.g., Linux) issue HLT instructions when the CPU is idle, which basically shut the CPU down. Windows (9x, anyway... not sure about NT) doesn't do this, so if by "conventional PC", you mean "Windows PC", you're correct. Otherwise, reducing CPU load will reduce power consumption and waste heat (which is why there are overclocking utilities for Windows... they do the HLT thing to reduce the heat produced by the CPU).
Technical points aside, I think the original poster has failed to multiply his "calculated" odds of a planet having intelligent life by the sheer number of planets in the galaxy... I find it inconceivable that only one planet in a mindboggling big universe would have life. Whether we have any nearby neighbors radiating on a frequency we're watching strongly enough for us to detect it and for long enough for the signals to have reached us is another question, and one we can't know the answer to until we look - which is what SETI is supposed to do.
These people are doing a scientific experiment. They need to know what code people are running so the programs don't give false results. Think of the uproar if they announced the discovery of alien intelligence and it turned out to be some dufus's "custom" client.
Subject: [RC5] seti@home fraud!
Date: Sat, 05 Jun 1999 11:45:44 -0400
From: Paul Cuni
500,000 users working on 115
work units?
Bob_Kanefsky
(M/California)
Jun
5 1999
2:28AM EDT
I've reluctantly come to the conclusion that SETI@home's half million
participants are currently being
assigned the same 115 work units over and over again, all from three
different sky locations collected
on January 7 and 8. If anyone has seen any other work units recently --
especially from January 9 or
later -- please speak up.
After seeing a few duplications of work units a machine at work had
already processed (same headers,
same content), I ran a test. I instructed my computer to repeatedly
start the SETI@home client and
download a work unit, but then just kill it, record the name, and start
again. The result: Out of 2500
work units, the same 115 kept showing up.
Two of the 115 work units are slices of different coordinates and have
the following names (as shown
on the fourth line of the work_unit.txt file):
name=07ja99aa.10912.26555.213914.156 [got this one 6 times out of 2500]
name=08ja99aa.16286.4081.917340.30 [got this one 4 times out of 2500]
The others are all subband slices from one location (but only 113 of them).
They all say
name=08ja99aa.12769.4418.68748.*
where * is one of these subband numbers:
0 2 3 4 5 6 9 10 11 12 13 14 15 16 17 18 19 21 22 23 24 26 27 28 29 31
32 33 35 36 37 38 39 41 43 44
45 47 50 52 54 55 56 60 61 62 64 65 66 67 70 72 74 76 78 79 80 85 86 87
88 89 90 91 92 94 95 96 97
98 99 100 102 103 104 109 110 112 113 114 115 116 117 118 119 122 123
124 125 127 131 132 133 134
135 138 139 140 142 143 145 148 149 150 151 152 154 158 160 161 163
The only other data unit I've seen was one I downloaded on May 27 and
then had to release the
machine that was working on it.
I hope the SETI@home project will fix this problem soon, or at least
acknowledge it and promise that
they're working on it.
P.S. Kris, you may be right about the cause, but I doubt it. Web browser
clients may be configured to
use caching proxies, but there's no reason that the SETI@home
client/server connection would be built
only anything that complicated when a direct connection is easier to do.
But not having seen the
implementation, anything is possible.
END OF MAIL
--
Weasel
The FAQ claims no source code is available "for security reasons". Hasn't the whole "security through obscurity" thing been discredited?
If you are such a believer in "security through openness" then why don't you get rid of your firewall and unshadow your passwords?
Let's face it, "openness" isn't the solution to every problem. A binary-only client is a good way to prevent cheating.
I know I will get moderated out of everyone's sight for posting this message, but I'm doing it anyway. Fuck moderation.