I wonder why Berkeley is not getting an SP sponsor. With the visibility associated to the project, I am sure several reliable service providers could sponsor them and collocate their servers in a bullet proof data center.

We actually discussed this internally last week. It's a long story, but basically it's an all-or-nothing problem. Since there are so many server dependencies, we'd have to bring everything down to such a facility and then spend a lot of time transfering data tapes back and forth to make it work.

This is a problem that will time out, anyway. Once SETI@home classic is off, this removes half the servers from the equation. Of course, we'll probably use some of these servers for BOINC, but we'll still be under our maximums for cooling, power, etc. I personally can't wait for this to happen..

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

The issue is not so much about the number of servers involved as how and where they are located. They can be distributed around the campus effectively but it is only necessary to take WU tapes backwards and forwards to allow clients to connect and operate 24hr per day instead of trying to squeeze it into an 8hr window. Even better distribute servers around via the network! These few client servicing machines are the only ones that absolutely need to be available continuously so the effort should be concentrated on keeping your processors processing as that is the limiting factor on effectiveness and the prime rationale behind distributed processing.

There are still issues around classic and while it can continue to provide effective work then it is a case of chucking the baby away with the bath water. It seems to be doing things that BOINC can't at present.

Systemic issues surrounding timing, connectivity, accounting work allocations and so on seem to generate a lot of legitimate concern. There are enough people around expressing this so it needs to be looked at. Perhaps it is horses for course and BOINC suits one set of needs while classic does another.

While BOINC is set up to do other projects as well which may be an advantage, many people have put so much effort into SETI that they do not wish to detract from what they have achieved by diverting processing power. Therefore the question comes down to what is the real reason for moving away, and why is there a specific deadline? There certainly appears to be far more people on classic than BOINC. Or is it a case that classic has (or will have) achieved its goals?


> We actually discussed this internally last week. It's a long story, but
> basically it's an all-or-nothing problem. Since there are so many server
> dependencies, we'd have to bring everything down to such a facility and then
> spend a lot of time transfering data tapes back and forth to make it work.
>
> This is a problem that will time out, anyway. Once SETI@home classic is off,
> this removes half the servers from the equation. Of course, we'll probably use
> some of these servers for BOINC, but we'll still be under our maximums for
> cooling, power, etc. I personally can't wait for this to happen..
>
> - Matt
>

---

While BOINC is set up to do other projects as well which may be an advantage,
> many people have put so much effort into SETI that they do not wish to detract
> from what they have achieved by diverting processing power. Therefore the
> question comes down to what is the real reason for moving away, and why is
> there a specific deadline? There certainly appears to be far more people on
> classic than BOINC. Or is it a case that classic has (or will have) achieved
> its goals?
> > - Matt
> >
>
Maybe a part of the answer why so many people are still at classic, is information and language. A lot of people,in european countries, don´t speak english very well. A long text is a torture. As long as Seti classic did not make a lot of trouble, they just use it as an screensaver, pay the bill, and don`t care much about new inventions. There ist just not enough information about boinc in the media or by email from Seti. I also run into boinc by fortune. If Seti would inform their participants by email and maybe in the appropriate language about boinc and encourage them to change, this thing will be done in weeks.

---

Es grüßt:

<img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=744" />

> While BOINC is set up to do other projects as well which may be an advantage,
> > many people have put so much effort into SETI that they do not wish to
> detract
> > from what they have achieved by diverting processing power. Therefore
> the
> > question comes down to what is the real reason for moving away, and why
> is
> > there a specific deadline? There certainly appears to be far more people
> on
> > classic than BOINC. Or is it a case that classic has (or will have)
> achieved
> > its goals?
> > > - Matt
> > >
> >
> Maybe a part of the answer why so many people are still at classic, is
> information and language. A lot of people,in european countries, don´t speak
> english very well. A long text is a torture. As long as Seti classic did not
> make a lot of trouble, they just use it as an screensaver, pay the bill, and
> don`t care much about new inventions. There ist just not enough information
> about boinc in the media or by email from Seti. I also run into boinc by
> fortune. If Seti would inform their participants by email and maybe in the
> appropriate language about boinc and encourage them to change, this thing will
> be done in weeks.
>
Well said Oliver. Though I am sad to say my German is way behind your English. The lack of information and response from the project team is at the heart of the problem. Clearly they want people to move but have lost track of what people want to get out of it and have failed to provide a visibly viable alternative. Classic works well and meets us client's requirements. Instead of trying to enforce a change (remembering that Bill Gates comes fom the same country as the team!) they should work with their users and not expect them to follow like sheep. Why they couldn't create a replacement for the core SETI executable that crunched their numbers and was a one for one replacement or upgrade I don't know. Especially when the central infrastructure was proven and most importantly understood. Perhaps they were overcome by the success of classic and didn't think the replacement through?

---

> ...
> Maybe a part of the answer why so many people are still at classic, is
> information and language. ...

"Part of the answer" is correct, there are several reasons not to switch or at least to switch as late as possible :


- Classic can be controlled better. With those few options and the trigger file I can completely control it with a few shell scripts and FTP, not even terminal access needed.

- BOINC: Local override for the global XML settings, I prefer local control over the web based stuff. Easy to implement, several people asking for it but it isn't there.

- Classic : No installation needed, you can just copy it to any computer, let it crunch a few work units there, flush them and remove it. PC builders and PC magazines used it for tests.

- BOINC : Registry entries - I think they are only necessary for interaction between different programs, a single program should not have them, it could use INI files instead on Windows.

- Classic : Easily transportable workunits - I cannot use BOINC on company PCs although I would be allowed to use a few, just because only one PC there can use my proxy permissions within a given time. Currently I'm crunching classic @work on network drives with batch control or feed the classic client with fresh WUs by FTP. Not possible with BOINC.

- BOINC benchmark results are random on some machines but the benchmarks influence the credit system - not good for competitions like the S@H Gaunlets

- Classic is reliable whereas BOINC still suffers from bugs in process control and error handling. BOINC needs more time before it can replace Classic fully. Classic seldom destroyed workunits, BOINC is way too picky about a few things that can happen easily, like a killed project client, power outage, file open for reading ...


The architecture of BOINC is way better than the one of Classic - but I would not want to have it on all computers yet, as long as at least the worst bugs are not fixed. Problem is, that those bugs do not occur or do not matter so much with the S@H client but waste a lot of CPU time with CPDN models.


I'm absolutely not against BOINC although it now might sound so - I would not use it at all or have the sources on my HD if I was against it - I just think it has not reached the quality of Classic yet. Too many restrictions and lack of reliability with compound projects.

So I currently use it as a test drive to find out when it has reached a state that allows me to jump on the train with all my stuff without having to be forced - just with beeing asked nicely ;-)

If I would be forced now, it would feel like someone took away my favourite toy :´(

Volker

I believe that once they set a date for closig seti classic , then an email shot will be done (not sure if it is possible to do the "correct" language).
At present they wont to get boinc stable before that is done.

My understanding of the reasons for the replacement of the old classic seti with boinc is that.

1) The amount of computing power available to seti classic was more than the work available that needed to be done. To ensure that all users were able to get work , each workunit was often distributed more times than strictly required. Whilst this kept all the users happy it is a waste of computing resources that could be better utilised on other projects.Because boinc is not project specific users can participate in many projects at the same time , which means that each project should only have to send each work unit out the minimium of times (the actualy number of times will vary on the project and whether each one is returned within the projects deadlines and whether each returned result is validated correctly or has to be resubmitted ).

You could also argue that the old system also used more bandwith and server resources than was required , because each duplicate has to be downloaded,uploaded and compared.

2)The original seti classic client was hard coded to the original data receivers at Arecibo. The Boinc client is not hard coded as the workunits contain the old hard coded info. This means that newer data recorders can be used and in theory alternative telescopes could be used as well.

3)Under the Boinc system if any projects client is updated , then the server will automatically issue it to a pc when it requests more work , under the classic system a user would have to manually request the new client. This obviously means that it is much easier for any project to make updates to their clients without the need for users to do anything.

At present the boinc core client does keep changing and has to be manually downloaded and installed , but this is to be expected because boinc is still a young project that is trying to cater for many different scientific projects. Eventually (at least hopefully) the boinc core client will stabilise and updates should be much less frequent.

I know that a lot of people shout that they only wont to crunch seti and are not interested in any other project , but if you ask yourself the question of is it really benefical for my machines to be crunching a work unit that has allready been crunched by X number of other machines just so that I can get credits in my prefered project whilst not being neccesary for the science , OR is it more beneficial for my machines to crunch work units that are necessary for the science for many projects ? I believe that the later is the more sensible option.

Seti will always be my favourite project and it is what sparked my interest in distributed processing in the first place , but nobody asked me to build a (stupidly large :) ) home farm , I did that by choice. I am sure that if most people remove the emotional attachment to seti clasic and consider what they are actually trying to achieve , then they will find that boinc is a sensible way forward and not something to be feared. There are issues with benchmarks and thus credits claimed , but these can be altered in the future. Once people get used to the credits system , they will find its not realy that different and still holds the important competitive element that drives people to continue with a project and find or but extra machines to run it on , just like it was under seti classic.

Yes I do miss the old instant update of credits and the ease of allocating work units between machines , but I also miss other things in life that have now gone or changed ,you get used to it as everything in life changes , if it did not then neither seti or any other DC project would be possible in the first place.

---

<img src='http://www.boincsynergy.com/images/stats/comb-1527.jpg'>

> We actually discussed this internally last week. It's a long story, but
> basically it's an all-or-nothing problem. Since there are so many server
> dependencies, we'd have to bring everything down to such a facility and then
> spend a lot of time transfering data tapes back and forth to make it work.
>
> This is a problem that will time out, anyway. Once SETI@home classic is off,
> this removes half the servers from the equation. Of course, we'll probably use
> some of these servers for BOINC, but we'll still be under our maximums for
> cooling, power, etc. I personally can't wait for this to happen..
>
> - Matt
>

thanks Matt and all the Dev Team for their Hard work

just getting new WUs here

Greetings from Germany NRW
Ulli S@h Berkeley's Staff Friends Club m7 ©

> Why they couldn't create a replacement for the core SETI executable that crunched their numbers and was a one for one replacement or upgrade I don't know.

Um, thay have.
It's Seti@home BOINC, now just know as Seti@home as the old Seti@home is now known as Seti classic.

---

Grant
Darwin NT

> I wonder why Berkeley is not getting an SP sponsor...
>

[rant mode on]
Because no SP concerned about money (who not?) would like to be associated with a project, that's down 20% of the time ;)
[rant mode off]

---

Aloha, Uli

> > I wonder why Berkeley is not getting an SP sponsor...
> >
>
> [rant mode on]
> Because no SP concerned about money (who not?) would like to be associated
> with a project, that's down 20% of the time ;)
> [rant mode off]

[rant mode on]
... because users get bent when the project is down, but the software doesn't really care. Think E-Mail -- 99.999% uptime is not required.
[rant mode off]

---

> > Why they couldn't create a replacement for the core SETI executable that
> crunched their numbers and was a one for one replacement or upgrade I don't
> know.
>
> Um, thay have.
> It's Seti@home BOINC, now just know as Seti@home as the old Seti@home is now
> known as Seti classic.
>

BOINC is not a one-for-one replacement. It requires different installation settings, appars to be less controllable, gives dubious and varying 'credits'. Clearly the core calculation routine needs to be adapted to do other jobs but why destroy the relatively reliable, known, understood and even more improtant management capability of classic?

I do not want a GUI interface. I am happy with GUI control add-ons but the core calculation routines do not need to interact with the video display as a screen saver or whatever. I have yet to see any documentation, when I tried BOINC (several times over the last year) I have always ended up taking it off as it is not as useful as classic. On the last occasion it told me that my 4gb of free disk space was not enough for any work units! Yet is there any explanation or help available? - no.

When first asked for a CLI version, the answer was to download the source and complile it myself! Not exactly user friendly or inspiring is it? And what about the sophisticated add-ons for classic I haven't seen any of that replicated in BOINC.

What people have with classic is a background friendly and muliple instance capable CLI.

So the argument is not about the programme's calculations being distributed but about the tools we are expected to use.

The simplest answer by far is to have a plug in to the classic package that changes the calculation routines. Nothing else needs to be changed other than the location of the upload/download server addresses. If there is no need for a fancy graphical display of progress then the whole thing can be extremely simple. The adage K.I.S.S is extremely pertinent.

My PC is not left switched on all the time, but my servers are. Since they have significant spare capacity and have muliple processors then they are very effective for these distributed processing projects. I have yet to see anything written down or marketed that suggests that I can run BOINC anything like as effectively as classic. Because when my PC is on it is busy doing other things there is almost no spare capacity so I could not provide much throughput but the servers are something else. Give us the tools that provide an effective replacement then we will be happy to move, dismiss our concerns, comments, or wish lists and you'll lose so much goodwill and capacity.

If SETI is running out of work to keep us fed then change the core as stated above and carry on with the proven architecture in use for the last 6 years.

---

> > > Why they couldn't create a replacement for the core SETI executable
> that
> > crunched their numbers and was a one for one replacement or upgrade I
> don't
> > know.
> >
> > Um, thay have.
> > It's Seti@home BOINC, now just know as Seti@home as the old Seti@home is
> now
> > known as Seti classic.
> >
>
> BOINC is not a one-for-one replacement. It requires different installation
> settings, appars to be less controllable, gives dubious and varying 'credits'.
> Clearly the core calculation routine needs to be adapted to do other jobs but
> why destroy the relatively reliable, known, understood and even more improtant
> management capability of classic?
>
You are right BOINC is a 2 for 1 replacement not 1 for 1. You get rid of the uncontrolable seti client and all the other crap you have to also download to manage the seti client.

> I do not want a GUI interface. I am happy with GUI control add-ons but the
> core calculation routines do not need to interact with the video display as a
> screen saver or whatever. I have yet to see any documentation, when I tried
> BOINC (several times over the last year) I have always ended up taking it off
> as it is not as useful as classic. On the last occasion it told me that my
> 4gb of free disk space was not enough for any work units! Yet is there any
> explanation or help available? - no.
>
There is no requirement that you run the graphics, you can use the manager and core client. The official documentation is a bit lacking but there is an exelent manual compiled by Paul Buck at http://boinc-doc.net/index.php and lots of people will answer your questions in the forums. The disk space preferences are on the web site under general settings.

> When first asked for a CLI version, the answer was to download the source and
> complile it myself! Not exactly user friendly or inspiring is it? And what
> about the sophisticated add-ons for classic I haven't seen any of that
> replicated in BOINC.
>
As of 4.25 the cli is the standard install. BOINC does not have the need for all the add-ons like classic did. There has also been less time to create them.

> What people have with classic is a background friendly and muliple instance
> capable CLI.
>
Umm last time I checked the cli only would run one workunit and caused a dos window to be displayed, so I don't know where this statement comes from.

> So the argument is not about the programme's calculations being distributed
> but about the tools we are expected to use.
>
> The simplest answer by far is to have a plug in to the classic package that
> changes the calculation routines. Nothing else needs to be changed other than
> the location of the upload/download server addresses. If there is no need for
> a fancy graphical display of progress then the whole thing can be extremely
> simple. The adage K.I.S.S is extremely pertinent.
>
> My PC is not left switched on all the time, but my servers are. Since they
> have significant spare capacity and have muliple processors then they are very
> effective for these distributed processing projects. I have yet to see
> anything written down or marketed that suggests that I can run BOINC anything
> like as effectively as classic. Because when my PC is on it is busy doing
> other things there is almost no spare capacity so I could not provide much
> throughput but the servers are something else. Give us the tools that provide
> an effective replacement then we will be happy to move, dismiss our concerns,
> comments, or wish lists and you'll lose so much goodwill and capacity.
>
BOINC is so much more effective than classic I have trouble finding a reply for this.

> If SETI is running out of work to keep us fed then change the core as stated
> above and carry on with the proven architecture in use for the last 6 years.
>


Sorry if I was ranting a bit here but I sometimes get frustrated when people talk about how much worse BOINC is than seti. Then list all kinds of complaints that have nothing to do with either of them, but rather the specific add-on programs that they are used to using.

---

BOINC WIKI

BOINCing since 2002/12/8

> > > > Why they couldn't create a replacement for the core SETI
> executable
> > that
> > > crunched their numbers and was a one for one replacement or upgrade
> I
> > don't
> > > know.
> > >
> > > Um, thay have.
> > > It's Seti@home BOINC, now just know as Seti@home as the old
> Seti@home is
> > now
> > > known as Seti classic.
> > >
> >
> > BOINC is not a one-for-one replacement. It requires different
> installation
> > settings, appars to be less controllable, gives dubious and varying
> 'credits'.
> > Clearly the core calculation routine needs to be adapted to do other
> jobs but
> > why destroy the relatively reliable, known, understood and even more
> improtant
> > management capability of classic?
> >
> You are right BOINC is a 2 for 1 replacement not 1 for 1. You get rid of the
> uncontrolable seti client and all the other crap you have to also download to
> manage the seti client.
>
> > I do not want a GUI interface. I am happy with GUI control add-ons but
> the
> > core calculation routines do not need to interact with the video display
> as a
> > screen saver or whatever. I have yet to see any documentation, when I
> tried
> > BOINC (several times over the last year) I have always ended up taking it
> off
> > as it is not as useful as classic. On the last occasion it told me that
> my
> > 4gb of free disk space was not enough for any work units! Yet is there
> any
> > explanation or help available? - no.
> >
> There is no requirement that you run the graphics, you can use the manager and
> core client. The official documentation is a bit lacking but there is an
> exelent manual compiled by Paul Buck at http://boinc-doc.net/index.php and
> lots of people will answer your questions in the forums. The disk space
> preferences are on the web site under general settings.
>
> > When first asked for a CLI version, the answer was to download the source
> and
> > complile it myself! Not exactly user friendly or inspiring is it? And
> what
> > about the sophisticated add-ons for classic I haven't seen any of that
> > replicated in BOINC.
> >
> As of 4.25 the cli is the standard install. BOINC does not have the need for
> all the add-ons like classic did. There has also been less time to create
> them.
>
> > What people have with classic is a background friendly and muliple
> instance
> > capable CLI.
> >
> Umm last time I checked the cli only would run one workunit and caused a dos
> window to be displayed, so I don't know where this statement comes from.
>
> > So the argument is not about the programme's calculations being
> distributed
> > but about the tools we are expected to use.
> >
> > The simplest answer by far is to have a plug in to the classic package
> that
> > changes the calculation routines. Nothing else needs to be changed other
> than
> > the location of the upload/download server addresses. If there is no
> need for
> > a fancy graphical display of progress then the whole thing can be
> extremely
> > simple. The adage K.I.S.S is extremely pertinent.
> >
> > My PC is not left switched on all the time, but my servers are. Since
> they
> > have significant spare capacity and have muliple processors then they are
> very
> > effective for these distributed processing projects. I have yet to see
> > anything written down or marketed that suggests that I can run BOINC
> anything
> > like as effectively as classic. Because when my PC is on it is busy
> doing
> > other things there is almost no spare capacity so I could not provide
> much
> > throughput but the servers are something else. Give us the tools that
> provide
> > an effective replacement then we will be happy to move, dismiss our
> concerns,
> > comments, or wish lists and you'll lose so much goodwill and capacity.
> >
> BOINC is so much more effective than classic I have trouble finding a reply
> for this.
>
> > If SETI is running out of work to keep us fed then change the core as
> stated
> > above and carry on with the proven architecture in use for the last 6
> years.
> >
>
>
> Sorry if I was ranting a bit here but I sometimes get frustrated when people
> talk about how much worse BOINC is than seti. Then list all kinds of
> complaints that have nothing to do with either of them, but rather the
> specific add-on programs that they are used to using.
>

Well perhaps it appears worse because it is new and the team have failed to market it properly and that there is no documentation and that the crediting system appears to be awful (not granting credits for work seems to be common) I don't mind people ranting but the project team need to look at the rants and work out what they are not doing to get people on their side.

If BOINC tells me that 4gb of disk space is not enough for any downloading then what is anyone to do? And putting disk space parameters on a remote web is NOT a very sensible idea and why are they there and no on the local machine as is utterly conventional? I am not having remote access to my disk space run half way round the world. And the management of BOINC does not appear as simple as classic with the add-ons despite what you say, and the CLI can runb as multiple independent instances (as many as your processors can sustain with very little resource overhead. And the command line options cater for almost every eventuality and it is fault tolerant not losing data.

And nobody has answered why the whole mechanism had to be altered to something that appears not to suit the 400000+ classic users but focussing on the 80,000 BOINC advocates only, especially when as already stated the add-ons had been developed as very effective tools and were freely available and it was only the fourier analysis and binary tree structure routines that had to be exchangeable with whatever the other processing requirments were and leaving the rest of the package alone in order to K.I.S ( I have left off the Simple as it is not intended personally). This development would have been very (very short) and woudl not have required this extended beta testing which has to trial the whole infrastructure and it woudl have allowed the team to allocate more time to reliability, mirroring or distribution of servers (and the UPSes) as well.

Seti classic is STILL very much a tried and tested and valid distribution mechanism that is being thrown away merely because its maths routines needed to be changed.

I did have an interest in looking at other projects whish is where BOINC currently scores, BUT there is no reason (apart from the time now spent on BOINC) why different math could have been added to a different classic client to allow these multiple instances to run as well.

Regarding the non-GUI, today is the first mention I have found looking at the paltry documentation on the 4.25 download. But there is no documentation and there is no reason apart from intransigence why whatever there is is not included to allow the concerned majority to view it.

---

Having the preferences on the web makes more sense the more computers you have to manage. You make one change and they all change.

I also did not make one point clear apparently: classic needs all the add-ons because it is flawed and doesn't run well. BOINC needs no add-ons or extra work to run as many instances as needed, it will automatically run one per processor up to user specified limits.

As far as just changing the classic code to allow other data sources think about how many people are still running 3.03 and consider if you still think this is a good idea. With BOINC it is normally less of a problem when people refuse to upgrade to the latest version because the BOINC client does not do the work and will download a new worker app automatically as needed. The servers can also be set to refuse to send work to outdated clients if one is found to have a serious enough flaw.

Reasons why the old client had to go:
Data from different sources could be analized without intravention from the user.

Better security for the projects (eliminating cheats).

Better security for the users. There are people that do not agree with this, but I think on average there is less risk with BOINC than with the classic client.

Limiting redundancy and ensuring that all workunits were crunched. The old system this was random and problematic some work might not ever be returned and other units would be returned as many as 40 times.

---

BOINC WIKI

BOINCing since 2002/12/8

> Having the preferences on the web makes more sense the more computers you have
> to manage. You make one change and they all change.
>

Only if you want those preferences to be common. The normal convention is for an ini or cfg file for each running process. In any event there are significant user based security issues with having disk quota controls or whatever located somewhere out of your control. I am NOT doing that, controls and allocations of what happens on my machinery will remain under my direct control.

> I also did not make one point clear apparently: classic needs all the add-ons
> because it is flawed and doesn't run well. BOINC needs no add-ons or extra
> work to run as many instances as needed, it will automatically run one per
> processor up to user specified limits.
>

Classic does not appear to be flawed, and the client side works very well, it'll process whatever has been sent to it. The add-ons were natural evolving requirements, which were never included in any updates. They have presumably been incorporated in BOINC on the basis of hindsight (though I have yet to see any remotely comparable means of control or monitoring).

> As far as just changing the classic code to allow other data sources think
> about how many people are still running 3.03 and consider if you still think
> this is a good idea. With BOINC it is normally less of a problem when people
> refuse to upgrade to the latest version because the BOINC client does not do
> the work and will download a new worker app automatically as needed. The
> servers can also be set to refuse to send work to outdated clients if one is
> found to have a serious enough flaw.

The point of changing the math is to allow different projects to run using the same existing tested client-v-server architecture. The architecture of the server farm is independent of the client which only connects via the WU allocators and result collectors.

If people only wanted to crunch seti then they could retain the existing cli version, if they wanted to run einstein or climate or whatever they would download (as BOINC does) the math component. So what essentially is the difference?

>
> Reasons why the old client had to go:
> Data from different sources could be analized without intravention from the
> user.

See comment above.

>
> Better security for the projects (eliminating cheats).

How, why? If it was possible to cheat with classic then it will only be a matter of time before BOINC suffers the same fate. The process of peer validation which is a good idea could easily be implemented on the old system and does not require any change at the client end.


>
> Better security for the users. There are people that do not agree with this,
> but I think on average there is less risk with BOINC than with the classic
> client.

Risk of what? Apparently BOINC loses wus and results quite often. Classic never did (by itself).

>
> Limiting redundancy and ensuring that all workunits were crunched. The old
> system this was random and problematic some work might not ever be returned
> and other units would be returned as many as 40 times.
>

This is a function of the server farm architecture not the client side. Some wus are not returned by BOINC. This is a function of the user rather than the system. And if 40 copies of the wu are sent out then eventually 40 will (subject to people deleting them) get sent back. BOINC will be no better. Users of either system have no control over which wus are sent out to them. just because elements of the back-office architecture needed to be updated to prevent these 'random' occurences did not mean that users had to be messed about.

I haven't seen any rational arguments for the new BOINC architecture. I wrote a very long time ago a general purpose calculation utility in pascal(!) occupying significantly less than 64KB (yes K) which allowed for changes of math to be incorporated very simply without changing the basic programme structure. This would allow for project specific variations of the wu processor and using hyper threading controls or Xeon multi processing or whatever would allow for independent multiple instances of these to be run whcih need not be all the same. The enveloping management, control and communication elements could remain the same utilising the project specific parts (as now) without changing the whole ethos of the system. BOINC is not backward compatible, again part of the main complaint (apart from reliability and unknown workload crediting).

But the main issue is probably that there is no logical carry through of statistics for the users and therefore they have 'lost' the value of the last 6 years of effort. Quite significant in carrying users forward with the project, and if they only have a real interest in SETI rather than all the others (even if they are worthwhile). People like to see the value of their investment retained, having it taken away in whatever fashion does not keep them on-side.

---

> I also did not make one point clear apparently: classic needs all the add-ons
> because it is flawed and doesn't run well. BOINC needs no add-ons or extra
> work to run as many instances as needed, it will automatically run one per
> processor up to user specified limits.

John,

All of your points are good. Our friend Nick hasn't returned a single WU and doesn't appear to be disposed to returning work in the future.

I'm trying to figure out if we should call him "woody" or "guido" -- or just ask him to crunch work for a month, gain some real-life experience with BOINC and see if his opinions change.

-- Ned

---

> [rant mode on]
> ... because users get bent when the project is down, but the software doesn't
> really care. Think E-Mail -- 99.999% uptime is not required.
> [rant mode off]
>

Maybe, but i get pissed if i want to send an email and the mail server says: Oops, no mail today...
Do you like waiting for the server to come back to life? Ok, that's your choice to waste your life.

---

Aloha, Uli

> Maybe, but i get pissed if i want to send an email and the mail server says:
> Oops, no mail today...
>
> Do you like waiting for the server to come back to life? Ok, that's your
> choice to waste your life.

Actually, I was thinking of the server to server interaction, where no users are directly involved.

So, you click "send" in your MUA, it gives it to your local MTA, and it tries to connect to the destination MTA. If it's down, your MTA waits a while and tries again, and the odds are that you don't even know that the other MTA was down.

For BOINC, the BOINC manager is the mail client (MUA) and BOINC represents your local mail server (MTA). Once you've handed BOINC your instructions, it will carry them out as best it can, and doesn't really need additional fiddling.

---

> So, you click "send" in your MUA, it gives it to your local MTA, and it tries
> to connect to the destination MTA. If it's down, your MTA waits a while and
> tries again, and the odds are that you don't even know that the other MTA was
> down.

And what, if my local MTA is down?

> For BOINC, the BOINC manager is the mail client (MUA) and BOINC represents
> your local mail server (MTA). Once you've handed BOINC your instructions, it
> will carry them out as best it can, and doesn't really need additional
> fiddling.

In reality i can't say my client anything without the server. I have to wait for the server to get up, so i can change the settings on the server web side of my preferences and then i have to be the lucky one again and my client is finally able to get a connection to server(sic!) to get my settings transferred. Ever thought of that?

---

Aloha, Uli