As you read through the hundreds of both critical and supportive posts regarding SETI/BOINC it seems everyone is in agreement in wanting the project to work and be a success. The polarization seems to be centered around two main camps: (1) the be patient, support the project by giving them time to work out the kinks, and don't be critical camp, and (2) try to help, point out the bugs, air some frustrations, and try to understand details of the future plans camp.


This project is funded, at least in part, by the National Science Foundation. The abstract and the names of those responsible for the project may be found at this link (when the NSF computer is working): http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0221529

There is nothing in the abstract that addresses how the project will be managed as an effort involving the public. This might be part of the reason why those publicly participating in the project are forming into factions.

In my opionion, it is too bad this project isn't being run like many software projects that have a large, diverse user base and multiple systems that must be integrated.

Instead of having a project plan that includes stress testing, load testing, hardware testing, etc. the SETI/BOINC project management puts equipment and code into production and waits to see what happens. Of course Murphy's Law kicks in. What would one expect if you don't do full system testing? No one writes perfect code, that's why it is essential to have a stabilization and performance tuning phase as part of any rollout of a system before it goes into production. Otherwise, you force your end users, in this case the public, into being the testers, and most end users aren't equipped to deal with a test environment or have the desire or skills to do software testing. On top of that the "News" communication to the public from the project is awkward, terse, and seldom accurate. The "News" announcements are generally made late and seldom reflect what will happen. There is no way to report "bugs" directly to the developers coupled with the status and resolution of the bug fixes.

This project is in need of publicly focused project management if the public is to stay involved. The technical side is probably excellent. The project planning, rollout criteria, test criteria, performance criteria etc. leave a lot to be desired to work with a broad base of the general public.

So back to the grant and the funding. Given the funding and staffing the project seems to be run more like a "lab" experience rather than a commercial software solution. It looks like the funding was minimal for a "lab" environment and not sufficient for a rollout that involves a broad segment of the general public. The funding from the NSF totals less than $1M to date - not a lot for what they are trying to accomplish even if UC Berkeley and other sponsors match this funding.

Those SETI/BOINC users that are content to wait patiently as the developers refine their project are one camp. Those that wish to know what is going on and participate actively through communication are another camp. I hope there is room for both camps without one feeling they need to criticize and judge the other.

Maybe we should try to spend some of that energy we all have posting to this forum and send letters to Sherwood Boehlert, R-NY, chairman for the US House Committee on Science. They provide the major funding recommendations for the NSF. If you would rather lobby with a Democrat, Bart Gordon from TN is the ranking committee member.

One of the assumptions that seems to be made over and over again is that alot of this stuff __can__ be tested in the lab.

I don't think that's true....

You can try to simulate 30,000 users uploading 1,000,000 work-units, but it'll be a simulation, it won't be real world.

... and you can try to simulate hardware failures, you can try to plan for them, but you can't know until you get there.

Ultimately, you have to turn the whole thing loose in the real world and see what happens. What they found was that some hardware failed, directories got really full, and the project came down.

At that point, you either update the live code quickly and hope you got all of it, or you tell the participants that the project will be down for a few weeks while you try to validate the new code.

Or, as Sun Tsu said, "No plan of battle ever survives contact with the enemy."

If it makes you feel better to think that this needs to be tested in a lab, well, then, welcome to the lab!

As for the whole P.R. question, that seems pretty simple. You hire a weasel with a degree in marketing, he takes everything and spins it to the point that we're so dizzy that we can't tell that we're getting spun, and we're all happy.

Frankly, I'd rather see them spend his salary on some additional (spare) hardware instead of some useless marketing person.

As for all of the anger and vitriol, I'm just amazed that so many people have so little going on in their lives that they can devote this much energy to something that is ultimately this unimportant. Fun, yes, exciting, yes, but given the fact that the amount of computing available dramatically outstrips the amount of available work from the telescopes, yeah, if they lost half, they'd still probably have too many computers and not enough work.

Hi Ned & Paul

Not trying to be critical here but please bear in mind this is not a project being run by a major commercial corporation.
This is a University with limited resources and a staffing for the project of 4/5/6 people. This is cutting edge software development technology which would not be entertained by a commercial company but belongs in a research establishment like Berkley. It is a lab experiment and cannot afford the luxury of all the normal project management procedures.

In addition only about half the volunteer participants are American citizens. The others are from the rest of the world and lobbying your Senate/Congress?? (I have no idea how American government works) will have no bearing on the project. (All politicians are only in it for the votes).

I also assume that CPDN, Predictor etc. are providing some money to the SETI team, who I think are also the developers of BOINC, for the software for their distributed systems software and so the main development effort went to these projects.

The development plan is to now bring BOINC for Seti into line with the version running the other distributed computing projects.

When you consider that the Classic Seti@Home system supported over 5,000,000 clients I have every faith the the new system can support 40,000.

Sorry if I sound like i'm ranting.

Kind regards from the UK

(ps We won the men's 4x100 relay Olympic final - YES!!)


S@h Berkeley's Staff Friends Club ©

> As you read through the hundreds of both critical and supportive posts
> regarding SETI/BOINC it seems everyone is in agreement in wanting the project
> to work and be a success. The polarization seems to be centered around two
> main camps: (1) the be patient, support the project by giving them time to
> work out the kinks, and don't be critical camp, and (2) try to help, point out
> the bugs, air some frustrations, and try to understand details of the future
> plans camp.
>
>
> This project is funded, at least in part, by the National Science Foundation.
> The abstract and the names of those responsible for the project may be found
> at this link (when the NSF computer is working):
> http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0221529
>
> There is nothing in the abstract that addresses how the project will be
> managed as an effort involving the public. This might be part of the reason
> why those publicly participating in the project are forming into factions.
>
> In my opionion, it is too bad this project isn't being run like many software
> projects that have a large, diverse user base and multiple systems that must
> be integrated.

Hell, B. Gates can not do it perfectly with all his Billions, and he has a heavy load of ONE.
>
> Instead of having a project plan that includes stress testing, load testing,
> hardware testing, etc. the SETI/BOINC project management puts equipment and
> code into production and waits to see what happens. Of course Murphy's Law
> kicks in. What would one expect if you don't do full system testing? No one
> writes perfect code, that's why it is essential to have a stabilization and
> performance tuning phase as part of any rollout of a system before it goes
> into production. Otherwise, you force your end users, in this case the public,
> into being the testers, and most end users aren't equipped to deal with a
> test environment or have the desire or skills to do software testing. On top
> of that the "News" communication to the public from the project is awkward,
> terse, and seldom accurate. The "News" announcements are generally made late
> and seldom reflect what will happen. There is no way to report "bugs" directly
> to the developers coupled with the status and resolution of the bug fixes.
>
> This project is in need of publicly focused project management if the public
> is to stay involved. The technical side is probably excellent. The project
> planning, rollout criteria, test criteria, performance criteria etc. leave a
> lot to be desired to work with a broad base of the general public.
>
> So back to the grant and the funding. Given the funding and staffing the
> project seems to be run more like a "lab" experience rather than a commercial
> software solution. It looks like the funding was minimal for a "lab"
> environment and not sufficient for a rollout that involves a broad segment of
> the general public. The funding from the NSF totals less than $1M to date -
> not a lot for what they are trying to accomplish even if UC Berkeley and other
> sponsors match this funding.
>
> Those SETI/BOINC users that are content to wait patiently as the developers
> refine their project are one camp. Those that wish to know what is going on
> and participate actively through communication are another camp. I hope there
> is room for both camps without one feeling they need to criticize and judge
> the other.
>
> Maybe we should try to spend some of that energy we all have posting to this
> forum and send letters to Sherwood Boehlert, R-NY, chairman for the US House
> Committee on Science. They provide the major funding recommendations for the
> NSF. If you would rather lobby with a Democrat, Bart Gordon from TN is the
> ranking committee member.
>
>
>





This 'SPACE' Rented.

The anonymity of the Internet, brings
forth, yet another EXPERT.

M7 Seti@h Berkeley's Staff Friends Club ©

> One of the assumptions that seems to be made over and over again is that alot
> of this stuff __can__ be tested in the lab.
>
> I don't think that's true....
>
> You can try to simulate 30,000 users uploading 1,000,000 work-units, but it'll
> be a simulation, it won't be real world.

Yep, as was very adequately proven by the public launch. Beta was running fairly stable with around 20,000 users.

There are 1,000's of differnet computer systems out there, yes they are basicly made up the same, abut alot of us bulid and tweak them to what we want. How do you expect the staff in the lab to account for all these different systems when running test in a lab.

> There are 1,000's of differnet computer systems out there, yes they are
> basicly made up the same, abut alot of us bulid and tweak them to what we
> want. How do you expect the staff in the lab to account for all these
> different systems when running test in a lab.


WIth IP client/server systems you don't have to verify 1,000's of systems. In my work we use tools like those sold by IBM Rational and Mercury Interactive to provide the IP client traffic stream to the server software. It is fairly straightforward to simulate as many machines for IP intereactions of the clients to the server with scripts. We do it all the time for large banking systems and brokerage systems that probably have significantly more transactions per second than the SETI/BOINC situation.

All you are simulating is the client/server transaction...not the entire client machine. You simulate to the number of connections you allow the server to accept.

I'm not sure what the comment about B. Gates has to do with anything related to BOINC/SETI.

My point about the funding was that since SETI/BOINC touches a large general population it should be run like a major commercial corporation would run large scale deployed client/server software and should be funded to include the testing and tools used to deploy this type of software. This isn't a luxury, but a necessity unless you want to upset a lot of users...which has happened.

There are plenty of Americans in this project that can apply pressure to those that fund these projects in the congressional committees if they want to. A few hundred letters will definitely get attention. A couple of things need to happen: the Berkeley folks need to ask for what they need to get the job done including funding to do load testing and stabilization. The NSF needs to work between the congressional staff and Berkeley to cause the funding to happen.

I don't think anyone is advocating putting a marketing weasel in the mix. A good, experienced project manager with experience in real world large scale deployment of client/server systems would be an excellent addition.

> > One of the assumptions that seems to be made over and over again is that
> alot
> > of this stuff __can__ be tested in the lab.
> >
> > I don't think that's true....
> >
> > You can try to simulate 30,000 users uploading 1,000,000 work-units, but
> it'll
> > be a simulation, it won't be real world.
>
> Yep, as was very adequately proven by the public launch. Beta was running
> fairly stable with around 20,000 users.

Beta isn't exactly a lab environment either.

> Beta isn't exactly a lab environment either.

I'm sorry Ned, I wasn't implying it was. I was simply expanding the concept a bit to show that even scaling estimates can turn out different than expected.

Just as real world implementation is different than lab testing, (like you mentioned) so can mass public release be to beta testing.

Sorry for the confusion. :(

> I don't think anyone is advocating putting a marketing weasel in the mix. A
> good, experienced project manager with experience in real world large scale
> deployment of client/server systems would be an excellent addition.

This isn't a commercial project, it is a research project at a University.

... and the main problem is that too may people expect it to be something other than a research project at a University.

It isn't a product, or a "project" in a business sense. It's an experiment.

If you are holding BOINC to a commercial standard, then you're right, it's not well run, but that is the wrong standard.

Bring in a "project manager" with commercial experience and a "commercial" way of doing things and you wind up doing things the same commercial way.

Finding other ways to get there is part of the project.

The grant abstract, by the way, is pretty interesting: It isn't a grant for SETI, but a grant do develop BOINC into a platform that can deliver 3.5 million computers to a number of projects at a net cost of about 26 cents apiece.

Pretty damned impressive when you look at it that way.

The majority of negative posts I've seen (and made) do not pertain to the hardware, software, budget, lack of personnel problems the project has encountered. Most of us "whiners" just want to be informed of what to do, without wading through the community messages, when there's known (by the project personnel) problems.

Something like a simple "stop crunching Boinc Seti until further notice" on the news page when there's a scheduled incompatible version update is what I'm referring to. I have Seti Classic on my machines and will happily switch over if I know it's the thing to do.

Also, I don't expect 24/7 news coverage. The project personnel must live their lives like the rest of us. I'm a volunteer; not paying for a service.

I'm not going to complain about hardware or software problems. I think the team has done a great job and even with the growing pains, to me, Boinc Seti is a success, and will get better.

As a hardware/software engineer and a project manager in the USA aerospace industry, I've experienced my share of the "down side" of reporting project status. I had to keep my boss informed, the government (civil service) and user's (US Navy and Air Force personnel) informed. I spent most of my week "reporting" instead of helping the team get the real work done. Reports are not fun.

I know a lot of you have been there. I don't expect that type of reporting on this volunteer project. Simple honest, up front statements (like Rom makes here in the message board) are fine. Why they can't be on the news page escapes me.

>
> This isn't a commercial project, it is a research project at a University.
>
> ... and the main problem is that too may people expect it to be something
> other than a research project at a University.
>
> It isn't a product, or a "project" in a business sense. It's an experiment.
>
> If you are holding BOINC to a commercial standard, then you're right, it's not
> well run, but that is the wrong standard.
>
> Bring in a "project manager" with commercial experience and a "commercial" way
> of doing things and you wind up doing things the same commercial way.
>
> Finding other ways to get there is part of the project.
>
> The grant abstract, by the way, is pretty interesting: It isn't a grant for
> SETI, but a grant do develop BOINC into a platform that can deliver 3.5
> million computers to a number of projects at a net cost of about 26 cents
> apiece.
>
> Pretty damned impressive when you look at it that way.
>
>

Ned,

I guess we come from different perspectives on the differences between research projects and commercial best practices. I've always viewed software engineering and the process of releasing software to end users as a discipline that is done pretty much the same way whether in the academic world or commercial world. Both situations, in my experience of working on grant funded projects as a computer science faculty member and as a member of commercial software development teams, need good developers, good people to do tuning and stabilization and good project management.

I agree that when the BOINC approach is mature and working well it will be of tremendous value for large scale parallel processing. That's why I'm following this project. My organization has 1.6 million desktop machines on a high bandwidth intranet. We would love to use something like BOINC to solve our problems using the off-time of our machines.

> Ned,
>
> I guess we come from different perspectives on the differences between
> research projects and commercial best practices. I've always viewed software
> engineering and the process of releasing software to end users as a discipline
> that is done pretty much the same way whether in the academic world or
> commercial world. Both situations, in my experience of working on grant
> funded projects as a computer science faculty member and as a member of
> commercial software development teams, need good developers, good people to do
> tuning and stabilization and good project management.
>
> I agree that when the BOINC approach is mature and working well it will be of
> tremendous value for large scale parallel processing. That's why I'm
> following this project. My organization has 1.6 million desktop machines on a
> high bandwidth intranet. We would love to use something like BOINC to solve
> our problems using the off-time of our machines.

It really depends on the goal. When you really think about it, part of this is research in sociology.

I think we've also seen some spectacularly bad luck -- bad memory, broken RAID, communications problems. In a better funded project they might have had more hardware, redundant connections to the net, and probably even more space.

But, it looks to me like the BOINC client is designed to keep the project going around server outages, and the failures may be part of the experiment. (Note: I did not say that the failures were planned, just that the failures would be a learning experiment).

Commerical business model will not work for Seti@H, just think about it!!!!!and you will figure it out.......for about the same reasons that government will not work under one lolol........



Documentation Menu
Release Notes
BOINC FAQ
BOINC Owner's Manual
SETI@Home Web Site Owner's Manual
SETI FAQ

This 'SPACE' Rented.

The anonymity of the Internet, brings
forth, yet another EXPERT.

M7 Seti@h Berkeley's Staff Friends Club ©

> There are 1,000's of differnet computer systems out there, yes they are
> basicly made up the same, abut alot of us bulid and tweak them to what we
> want. How do you expect the staff in the lab to account for all these
> different systems when running test in a lab.
>

> As you read through the hundreds of both critical and supportive posts
> regarding SETI/BOINC it seems everyone is in agreement in wanting the project
> to work and be a success. The polarization seems to be centered around two
> main camps: (1) the be patient, support the project by giving them time to
> work out the kinks, and don't be critical camp, and (2) try to help, point out
> the bugs, air some frustrations, and try to understand details of the future
> plans camp.

The real problem is those who (3) use personal attacks against the developers.

There is such a thing as constructive criticism. Report the problem without attacking.

A large number of people attack without reporting a problem.

Indeed in some cases patience is required. Hardware problems need some time to be fixed. Software problems that are reported also need osme time to fix. Once a problem has been reported, patience is required to wait for the very limited staff at BOINC/S@H to be able to fix it. Since there is a large backlog of work to be done, that work has to be prioritized, and your favorite task may not affect as many people, or have as bad an effect as some other problem.

Yes the project has problems. It is alos open source. If you know of a bug, and want to try to fix it, you can download the source, and see if you can get it fixed.