Well Well (Oct 29 2009) |
![]() |
| log in |
Message boards : Technical News : Well Well (Oct 29 2009)
| Author | Message |
|---|---|
|
As predicted the data well temporarily ran dry overnight, but I'm trying my best to keep up with demand today (and set it up for over the weekend). | |
| ID: 943690 · | |
|
| |
| ID: 943697 · | |
|
Someone !AND! their wingman sent back a 1.6 gig result file? wow. | |
| ID: 943699 · | |
|
| |
| ID: 943700 · | |
Someone !AND! their wingman sent back a 1.6 gig result file? wow. The way the data is analyzed involves going through it many times at different chirp rates and FFT lengths, or dedispersions for AP, so it is definitely possible a task could generate billions of signals. But as Matt noted the signals were duplicates, and that also explains why the result could validate against a normal result since the validator simply checks whether there's a matching signal in the wingmate result. IOW, the validator doesn't do sanity checks, simply signal comparison. How that many duplicates were generated without the overflow limit of 31 for MB or 60 for AP being tripped remains a puzzle, as is the failure of BOINC to refuse to upload the file since it exceeded both the 64 KB Enhanced size limit and the 640 KB AP size limit. It almost seems like the file system looped while writing a signal to the outfile, rather than any problem with BOINC or the S@H application. Joe | |
| ID: 943804 · | |
Someone !AND! their wingman sent back a 1.6 gig result file? wow. ... I very much doubt that. Much more likely is that locally a s@h backend spasm magically made the 1.6GB 'appear'. Time to run a fsck?... Regards, Martin ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
| ID: 943834 · | |
|
That would be really funny if the instructions for a machine to visit ET were in that WU. Do you have a link to this WU in question? | |
| ID: 943886 · | |
|
Change that 1.6GB file's extension to .pdf and see if Acrobat Reader will open it. Should be about the right size for a set of blueprints. | |
| ID: 943962 · | |
Change that 1.6GB file's extension to .pdf and see if Acrobat Reader will open it. Should be about the right size for a set of blueprints. or make it a powerpoint. instructions to the Enterprise-E... LOL! ____________ I recommend Secunia PSI: http://secunia.com/vulnerability_scanning/personal/ Go Georgia Tech. | |
| ID: 943988 · | |
|
thanks for the update matt. i am glad i decided to queue up a few thousand workunits. i had a feeling we would be running out before halloween. | |
| ID: 943997 · | |
|
Matt- | |
| ID: 944037 · | |
|
Hi, | |
| ID: 944121 · | |
Change that 1.6GB file's extension to .pdf and see if Acrobat Reader will open it. Should be about the right size for a set of blueprints. Just had to say... lol :D Cheers :) | |
| ID: 944465 · | |
|
Hi everyone, | |
| ID: 944510 · | |
Is SETI@home ending?? No, it is not ending. Most projects, including SETI@Home, do not promise that they will always have enough work. It's a combination of maintenance being done at the telescope and the fact that it takes longer than they'd like to radar-blank some of the old recordings. It's sunday afternoon in Berkeley. I suspect they'll be working hard on this tomorrow (if they haven't had machines blanking radar all weekend). ____________ | |
| ID: 944514 · | |
|
I ran empty for 2 days!! Now I got someting from Astropulse. Really glad, thought SETI forgot about me:( | |
| ID: 944660 · | |
I ran empty for 2 days!! Now I got someting from Astropulse. Really glad, thought SETI forgot about me:( Some would argue that this sort of thing happens more frequently in the relative "recent past" than before. There have been some work availability issues over the past 6-12 months where there are either dry spells or the bandwidth is fully saturated and therefore, hardly anyone gets new work. The current issue is that the telescope shut down for the entire month of October for maintenance, and the recorded data from September did not last the entire duration. There is some old data in off-site storage, but it needed a new piece of in-house software for it to be pre-processed and then split into WUs. I believe the pre-processing software is not able to go anywhere near real-time, and takes ~5 times longer to pre-process than it takes to split into WUs, so new tasks do come along every couple of hours, but it's a slow process. ____________ Linux laptop uptime: 1484d 22h 42m Ended due to UPS failure, found 14 hours after the fact | |
| ID: 944665 · | |
I ran empty for 2 days!! Now I got someting from Astropulse. Really glad, thought SETI forgot about me:( Thankx, that was some useful information:) | |
| ID: 944675 · | |
Message boards : Technical News : Well Well (Oct 29 2009)
| Copyright © 2013 University of California |