Things You Would Like To See In SETI@Home 2?

[ShotgunSteven]

I was thinking about it, and I would like to see the implementation of actual MiniTeams in SETI@Home 2. Have it so that members of Team AnandTech SETI could join a MiniTeam within the larger team, track its stats, then leave that MiniTeam if needed.

I would also like to see a "Hot Alien Babe Of The Month" feature on their site. Of course, they have to discover some hot alien babes, first.

 

[soni]

And a client, that runs on priority 1, can install as a service and run 10x Seti1

 

[JWMiddleton]

I would like to see WUs stay with a team if a person leaves. Their personal stats would not change, but each time they moved to another team the count would restart on that team as it does with RC5.

 

[Baldy18]

LAN installation and uninstallation made easier. Built in LAN client monitoring. Team Anandtech in the #1 position.

 

[lane42]

Ditto what JW said

 

[Confused]

The ability to merge 2 or more accounts into one, to create mini-teams.

Also, WUs you crunched with a Team/Mini-Team stay with that team/mini-team no matter where the user goes.

 

[networkman]

Without a doubt the single biggest improvement they could make would be for the client to be SMP compliant!!! Look to the RC5 client to see what I mean - there doesn't appear to be any limitations there, or at least none that I've been able test. I mean, heck, it even worked fine with the 6-way PPro ALR server I had. :Q

Dual CPU rigs are much more common now and native SMP compliance should be built into the client - in fact, if the client that is eventually released does not sport this feature, I would likely not bother with work-arounds to make the client work with multipled CPUs - I'd use my multi-processor machines for other projects.

I also agree with Confused, you crunch with a team, your units stay with the team.. move somewhere else, the units still stay put. It would significantly cut down on the dramatic fluctuations amoungst teams, and also nearly eliminate auctions of work units on eBay and the like.

 

[seaquake]

Much longer work units. Say about 10 to 15 hours per unit on the high end systems? Sound good to y'all? Just joking, but I imagine we are going to see it happen.

 

[Ken g6]

I don't want bigger WUs, and I'm hoping it will have a statically compiled Linux version. Otherwise, I don't know what to run on the Wildnet other than OGR.

It would also be nice if they had a Java version, and maybe even an applet.

 

[Spleenus]

maybe the ability to also use the GPU for extra processing power

 

[Rattledagger]

Well, looks like BOINC will have smp-support, caching, web-based registration/preferences -- propagated to all clients...

A little note about Result Validation...

The core client assigns credit for a completed work unit as a function of the CPU time used, and the performance metrics of the CPU (discussed later). This is sent back to the scheduling server; of course, the number can't be trusted in general.
.....
The back end then marks correct results as "validated", finds the minimum reported credit for the correct results of a given workunit, and assigns this amount of credit to all the correct results. This ensures that as long as a reasonable majority of participants don't falsify credit, almost all credit accounting will be correct.