Message boards :
Technical News :
Blitzed Again (Jul 02 2009)
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · Next
Author | Message |
---|---|
zpm Send message Joined: 25 Apr 08 Posts: 284 Credit: 1,659,024 RAC: 0 |
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. |
Cameron Send message Joined: 27 Nov 02 Posts: 110 Credit: 5,082,471 RAC: 17 |
Why are there two entrys for SPARC/Solaris and Linux/x86_64 in the Enhanced Table? It doesn't change the fact of the statement and the Linux/x86_64 show two versions (5.12 and 5.28). It gives no indication as to the reason for this unlike the windows/x86 entries with CUDA support. |
Country Send message Joined: 13 Jun 99 Posts: 5 Credit: 12,339,917 RAC: 0 |
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 |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
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. You will be assimilated...bunghole! |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
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 Computer sind nicht alles im Leben. (Kleiner Scherz) SETI@home classic workunits 3,758 SETI@home classic CPU time 66,520 hours |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
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. 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. You will be assimilated...bunghole! |
KWSN THE Holy Hand Grenade! Send message Joined: 20 Dec 05 Posts: 3187 Credit: 57,163,290 RAC: 0 |
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... . Hello, from Albany, CA!... |
Gary Charpentier Send message Joined: 25 Dec 00 Posts: 30593 Credit: 53,134,872 RAC: 32 |
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. The point is then after that compression you have to uncompress it by 27% to transmit it as text! |
Country Send message Joined: 13 Jun 99 Posts: 5 Credit: 12,339,917 RAC: 0 |
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 |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
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? When SETI sends you the files through the Internet, they are expanded (to x-setiathome) and then you compress them (to binary). So, the way to save bandwidth would be to transfer them in binary format (like the AP tasks). And since that has been said several times in this thread, I did ask if anyone reads it at all before posting. Gruß, Gundolf Computer sind nicht alles im Leben. (Kleiner Scherz) SETI@home classic workunits 3,758 SETI@home classic CPU time 66,520 hours |
zpm Send message Joined: 25 Apr 08 Posts: 284 Credit: 1,659,024 RAC: 0 |
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. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
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. |
Country Send message Joined: 13 Jun 99 Posts: 5 Credit: 12,339,917 RAC: 0 |
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 |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
So...don't transmit it as text then? Transmit as .zip and have it be uncompressed when it is returned to the Seti servers? You will be assimilated...bunghole! |
Gary Charpentier Send message Joined: 25 Dec 00 Posts: 30593 Credit: 53,134,872 RAC: 32 |
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. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
Not only do I understand that random binary does not compress, you'll probably find a post on this thread where I point that out. ... and there is the (server) CPU time to do the compression, which probably isn't worth it. I wouldn't be surprised to find corporate firewalls that block .zip files as well, because they can be used to mask trojans coming in to the network. Matt commented in a related post that work was being sent with a strange MIME type (suitable for MAN pages and that's about all) and he changed to to application/text, which is pretty harmless. It seems to follow that BOINC doesn't use the (HTTP) MIME type at all, and they could just as easily tag .gif or .jpg on the end, send the right MIME type for an image, and that'd be that. |
zpm Send message Joined: 25 Apr 08 Posts: 284 Credit: 1,659,024 RAC: 0 |
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. |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
But there is nothing to compress... |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
theoretically speaking, if we were to get another server that only compressed and uncompressed the data, would that help?..... It doesn't make sense to me to take uncompressed, mostly-random binary data, encode it to text (six bits per character) and then compress that. It makes more sense to see if we can eliminate the text encoding. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
... and it suddenly dawned on me that if Astropulse can send work in raw binary, multibeam should be able to as well. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.