many times the biggest hurdle with farming out core processes is that the data "owners" have to be assured or data security and validity. formal SLAs have to be hammered out so that the "contractor" is held to a certain level of performance so that the "contracting entity" (BOINC) can know that their data is handles iow their standards and expectations and that the "farmed out tasks" will be there (day and night) at the same level as if it were on their hardware, in their buildings and managed by their employees.

these SLAs are often as difficult (or troublesome) as the technology side of things. people offering up "donated services" think twice about not being able to pull back resources when their own demands change.

I trust files that came directly from servers run by Berkeley.

When the files start passing through other sites, especially things like the science applications, we get a whole bunch of issues with viruses and trojans, malicious or otherwise.

I'd probably stop crunching because of the security issues.

---

The donation page says we can give a monetary gift or choose a piece of hardware that they have on the list. So, why can I not contribute by donating a piece of hardware from said list? I found a good 3com switch that you quoted as needed. I was about to get it....

I have no idea why you can't donate. The easiest/best way to donate hardware is to contact Pappa -- a private message would do fine.

One of the ways Pappa "donates" is to coordinate hardware donations -- his time instead of Matt's or Eric's.

If you've got hardware to donate, I'm sure Pappa can make sure that it gets to the right place, and that you get the proper credit.

---

There are a million machines at SETI's disposal, all crunching.
The SETI project is centrally based with distributed crunching, but still a star network dependent on the core.

I have a couple of web servers on backbones that are spending 98% of their power on SETI, while not interfering with their primary purpose.
They could also be employed splitting and/or handling up/downloads, batch up the results and feed to the MSDB a few times a day.
Many of us have machines we can donate (virtually) to the project, and many would live topologically close to Berkeley.

Perhaps it's time for a fresh rethink on project architecture and considering maximising on the p2p resources available - ie a million machines!?

Andy.

There are a couple of basic problems with farming out splitting. I believe that the data comes as a single large file. One computer has to do the whole thing, and there is a very small CPU time to bandwidth required ratio (it would probably take you less time to process than the upload and download would take).

Distributing the upload/download across the internet also does not make any sense. The data has to start from Berkeley and make it back to Berkeley eventually. The distributed upload/download would be for new executables and such - this would save a great deal of bandwidth if/when implemented.

---

BOINC WIKI

Distributing the upload/download across the internet also does not make any sense. The data has to start from Berkeley and make it back to Berkeley eventually. The distributed upload/download would be for new executables and such - this would save a great deal of bandwidth if/when implemented.

If splitting meant just cutting up files, then I would agree.
I think that rather more is involved in band pass fft filtering, in which case distributed processing would help. It only takes me a minute or two to download 100Mb.