Blitzed Again (Jul 02 2009)

There's still a cost issue there. SETI@Home leases space from the University, and has to work within the constraints set forth by the University's dictates, which include power requirements for both the servers and the air conditioning to cool the servers. Then there's the issue of staff wages (they do try to get paid for their work).

I mention this because if the plan is to get other universities involved, you are effectively doubling the financial strain on the project. Other scientists at other universities will have to purchase servers (or look for donations), lease space, pay for their power usage, pay for the connection to the internet, etc. And of course those scientists will want to get paid as well.

How about rather than getting other uni's involved you get Nvidia involved. The deciding factor for me between an ATI card and an Nvidia card was the CUDA. Both cards play the games I want to play but only one will crunch. Amp up CUDA support messages in the SETI website and I'm sure that Nvidia would find hosting *all* the SETI boxes with a monster pipe a very profitable move. Win Win Win all round. Berkeley getts the boxes and their associated costs off site, we get WU to crunch, Nvidia gets advertising worth millions, the SETI team spends money on research rather than airconditioning and leasing space. Cheers Jason =:)

... Shifting from a text encoding to binary (the way AP does it) could save 15% or more, save storage on disk, etc.

Of course, the science application would have to understand more than one encoding method.

The code is already there as used in AP...

Just add an "if" statement? (And someone to code it.)

Happy crunchin',
Martin

... and test it, and then time to deploy, and it'd be nice to give the optimized apps a chance to add it to their apps.

The actual coding is probably the easiest part.

as we are talking about the beta side ftm, the iup/down ld. server is down.....

i guess someone is playing with it...
____________

I recommend Secunia PSI: http://secunia.com/vulnerability_scanning/personal/
Go Georgia Tech.

I'm assuming we don't already us compression so if we are I guess we can disregard.

If we compressed with 7-Zip we can get about a 27% savings in bandwidth - which is huge. I took a bunch of seti files and compressed them at default settings to get that 27%

First I did the files individually, then I did a batch in 1 finished file of 7-Zip. This ended up being more or less the same so there seems to be no benefit in compressing a batch of seti files into 1 compressed file.

2nd I set 7-Zip to Ultra compress with produced more or less the same results as the default setting which either means default compression is Ultra mode or compression maxes out.

Lastly, I compressed all my seti at home files on my 2nd machine to test a different sent of work units and got a compression rate of 28%. So as we can see there is variation depending on how compressible the work units are.

Personally I'm all for uncompressing the files at my end if it means a 27% bandwidth savings for the Seti team. I didn't test the compression that's built into Boinc but the point is there are savings to be had.

Of course the other side of this is the time it takes to compress the files in the first place. Now for me it didn't take that much time but we're only talking about 60 megs of files not the gigs and gigs Seti@home has. This would tie up cpu time at there end as well as hard drive access time. I guess they would have to weight what is more important but bandwidth seems to be a major factor for them.

Country Waring
____________

Umm, reporting is on the fritz again, getting "couldn't connect to server" on the messages. It's been this way since 0700 Berkeley time...
____________
.

I, as well, attempted to compress several AP and MB workunits. Using the Windows XP built in zip compressor (compressed folders), I got 27 - 28% for MB and 1 - 3% for AP.

Does anyone read this thread?

It was mentioned earlier that that results from the already used "compressing" algorithm for MB, namely UUencode or similar (effectively expanding 4 or 5 bytes to 6) while AP uses binary transfer.

Gruß,
Gundolf

Yes I did read this thread, and the point is that compressing a MB workunit in .zip format gives you 27% better compression than whatever method is currently being used.

I have a question - When seti sends me the files through the internet are they compressed and then I expand them to the text files that are on my computer? OR does seti@home compress the info into the text files and these text files are sent as is to my home and I can use them right away with no expanding them?

If I don't have to expand them and they send the text files as they appear in my seti data directory then clearly there is a more effective way to compress them with 7-Zip which could save bandwidth.

Country
____________

well, hey you know that people on, in the western hemisphere jump to the end and don't read what has been said........
____________

I recommend Secunia PSI: http://secunia.com/vulnerability_scanning/personal/
Go Georgia Tech.

Yes I did read this thread, and the point is that compressing a MB workunit in .zip format gives you 27% better compression than whatever method is currently being used.

The point is then after that compression you have to uncompress it by 27% to transmit it as text!

Actually I did read the whole post but didn't fully understand it apparently but thank you for just implying I'm too lazy to read. Your new explanation makes more sense and I thank you for that, perhaps you should consider that next time.

Country
____________

Yes I did read this thread, and the point is that compressing a MB workunit in .zip format gives you 27% better compression than whatever method is currently being used.

The point is then after that compression you have to uncompress it by 27% to transmit it as text!

HTTP is 8 bit, you can transmit binary.

The SETI@HOME logo on this page was not sent as encoded text, it was sent binary.

HTTP is 8 bit, you can transmit binary.

The SETI@HOME logo on this page was not sent as encoded text, it was sent binary.

And a considerable number of corporate gateways/virus/firewalls won't transmit binary through them if it isn't a jpeg. Or at least wouldn't when the original Seti@home was released. Today many more do and I agree that the MB work units would be much better transmitted as binary.

As to compression of random noise, that is after all what every work unit is unless ET is out there, if you understand the math behind compression, you will know that the result is likely to be bigger than what you started with. True I'm sure there is some non-random noise in the work unit, like the time, frequency, and location of the work unit, but it is such a small fraction of the data it won't make a difference.

theoretically speaking, if we were to get another server that only compressed and uncompressed the data, would that help?.....
____________

I recommend Secunia PSI: http://secunia.com/vulnerability_scanning/personal/
Go Georgia Tech.