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).

Weird thing today - I've been noticing intermittent problems connecting to the science database to make the most trivial queries. We thought this, and the assimilator queue backing up, were probably due to Bob's recent configuration changes to the informix database engine perhaps not helping so much. But then I noticed one of assimilators was inserting thousands and thousands of signals as fast as it possibly could from a single result file... since 7:40am yesterday morning!

This is not normal. Result files usually contain a handful of signals, maybe a few dozen tops. If they reach 30K in size they are automatically "cut off" and sent back to us. I tracked down the result file with all the signals - it was 1.6 gigabytes in size! Not sure how this happened, nor how it passed validation (though I have my theories), but it sure contained a lot of signals repeated over and over and over again. I moved that out of the way and hopefully that'll improve performance in general around here.

- 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

You remember the movie 'Contact'?

Hey, maybe we got now an instructions for to make a machine for to visit extraterrestrial intelligence?

;-D


BTW.
Thanks for the daily TNews.

---

Someone !AND! their wingman sent back a 1.6 gig result file? wow.

(Not that you can fit 1.6 gig into either a 366k WU or 8meg AP, at least not without a loop bug)

For the ones who missed the movie..

[http://en.wikipedia.org/wiki/Contact_(film)]

:-)

---

Someone !AND! their wingman sent back a 1.6 gig result file? wow.

(Not that you can fit 1.6 gig into either a 366k WU or 8meg AP, at least not without a loop bug)

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

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

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

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?

Yes, time to run fsck as a preventative measure.

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.

---

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.

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.

is there going to be much work units left? im kind of wondering how long it's going to be that we are super low on seti work. thanks !

Matt-

This is not the result of a pattern is it?

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 :)

Hi everyone,

I know this might be the wrong place for my query.

But I have been wondering. A couple of days ago I installed BOINC and got a few packages of data to analyze. But the last few days e.g. friday, saturday and sunday. I cant get any more data. It says that the project has no jobs available.

Is SETI@home ending??

cheers

Erik

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).

---

I ran empty for 2 days!! Now I got someting from Astropulse. Really glad, thought SETI forgot about me:(
Does this happen a lot? Next time I don't have to worry then. just wanna be useful:)

---

rOZZ
Music
Pictures

I ran empty for 2 days!! Now I got someting from Astropulse. Really glad, thought SETI forgot about me:(
Does this happen a lot? Next time I don't have to worry then. just wanna be useful:)

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:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I ran empty for 2 days!! Now I got someting from Astropulse. Really glad, thought SETI forgot about me:(
Does this happen a lot? Next time I don't have to worry then. just wanna be useful:)

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.

Thankx, that was some useful information:)