Panic Mode On (79) Server Problems?

I've only got 42 ghost work units on my new laptop, and none on my other slower machines. But I've stopped crunching for a little while here. I know it doesn't matter much, since most machines are set it-forget it setups, but I just hate when my computers can't get work. So working on other projects for now. Gotta keep those processors warm somehow. LOL
____________

Proxy server working perfectly - data rate hitting the scheduler from individual hosts is too high.
This 200 WU has only made it worse I would think - my system keeps asking for tasks about every 5 minutes. Thinking, why not open up the queue and have a mandatory backoff after wus are sent. After all - if you just filled your queue up with 3 or 4 days worth of data - you don't need to talk to the project for AT LEAST a day.
Just anyway that the load can be taken off of the scheduler - not letting the systems ask for data all the time when they don't have to would help.

I have 200 wu queue - I contact the project and it advises it has 2 units to report and is requesting more work....when...I still have 198 in my queue....
Maybe...set project to where it does not contact until half the queue remains (when the project is up and running well)?
____________

Basically a victim of their own success....

With all the new high powered CUDA crunchers that have been coming online the amount of work in progress has become too much for the database to handle in a reliable way. This led to the recent timeout issues as the database gradually got more sluggish, then to ghost work units, which further compound the database issues. Downward spiral until eventually the database broke completely...

I guess once it's fixed the short term fix will be to stop splitting for a while, clear the ghosts and get the work units in progress back to a number the database can handle. Then restrict the new work units to keep a sensible number in progress.

So expect some ongoing issues over the short term.

I see the plan is to make bigger work units, which should help a lot by making the database only 25% the size, but then that puts more pressure on the internet connection???

I assume there will be some gnashing of teeth, tearing of hair and threats to leave, like there usually is when problems occur. The other 99.9% of us will just sigh, select some other projects, and wait it out...

Ian

Personally I an happy that Eric has taken time to explain the problem. Whatever they decide to do is up to them. If it increases crunching time and lowers RAC so be it. I have always been here for the science.

I have actually stopped most of my crunching here just leaving one machine to "fly the flag". I will not restart at SETI@Home, I will give them time to sort it out. As should we all.
____________

Possibly - but - if the problem is what they stated it is - then my proxy server that I am using wouldn't make a difference at all. It doesn't change the timeout - it only changes the RATE of data that is hitting seti.
When I use a proxy server - it's basically flawless. Turn off the proxy - and..once in a great while will I get to the scheduler.

I think what we are seeing is another form of an old computer hack - flood the system with data and eventually it will do something wrong (used to be used to break into systems) - think the same thing is happening here.

When I am on my proxy - the data flow to seti is moderated - after all, the proxy is sending who knows how much data to multiple places - and it works great. When not on the proxy - seti basically gets my full upload speed - sure - a small amount of data - but at full speed.
An analogy - we used to have to interleave hard drives because the system wasn't fast enough to read data straight from the drive.

____________

[...]I see the plan is to make bigger work units, which should help a lot by making the database only 25% the size, but then that puts more pressure on the internet connection???[...]

If they do it like they doubled MB a while back, the WUs will stay the same size, they just increase the FFT resolution and make you do four times more work on the same data file. That change in the resolution is just something that gets changed in the XML-type header for the WU itself, but as always, it requires testing to see if it is going to work like it is expected. There's always that possibility that by increasing the precision, you may end up with many more false positives than you would expect.

It's kind of like looking at some of the satellite photos for things like the surface of another planet. It used to be something like 10-meter resolution, which meant that every pixel represented 100 square meters, and the particular color of that pixel was determined by what color was the most abundant in that 100 meter square.

As technology increased, I believe we've gotten it down to less than 5 square meters per pixel, so you end up with a huge increase in detail, and now instead of "this 100 meter square is roughly brown and flat" you have "okay, so there's probably a tree there, and oh look, a huge boulder, and it turns out this tree is on the edge of a cliff" because you now have 20 pixels to describe what you only saw in one before.

But increased detail can also be a burden, because it might be possible to end up with more signals in one WU, so -9 overflows may become much more likely, unless the limit gets increased for that, as well.

One of the red flags that a site has been hacked or spoofed is that you find grammatical or spelling errors that are out of the ordinary, and that make a message hard to read. Did anyone else notice the most recent message on the front page seems to have such errors? For example, "the lookup of result in process", "hosts being assigned large number or [of?] results to compute", and "The host. think it received", among others. These are not normal for the seti@home front page or any technical message one usually finds on the site.

One of the red flags that a site has been hacked or spoofed is that you find grammatical or spelling errors that are out of the ordinary, and that make a message hard to read. Did anyone else notice the most recent message on the front page seems to have such errors? For example, "the lookup of result in process", "hosts being assigned large number or [of?] results to compute", and "The host. think it received", among others. These are not normal for the seti@home front page or any technical message one usually finds on the site.

Belive in the kittyman... The kitties are allways right!
____________

Exactly Mark. We all know Qui-Gon of old, about par for the course :-)

One of the red flags that a site has been hacked or spoofed is that you find grammatical or spelling errors that are out of the ordinary, and that make a message hard to read. Did anyone else notice the most recent message on the front page seems to have such errors? For example, "the lookup of result in process", "hosts being assigned large number or [of?] results to compute", and "The host. think it received", among others. These are not normal for the seti@home front page or any technical message one usually finds on the site.

OR it could have simply been that Eric was tired on a Sunday when he composed that posting and was more concerned with getting the info out than worrying about being grammatically correct..........

If I have mistakes made yous maybe see them and wondering you are.

The roads are rolling.
____________

One of the red flags that a site has been hacked or spoofed is that you find grammatical or spelling errors that are out of the ordinary, and that make a message hard to read. Did anyone else notice the most recent message on the front page seems to have such errors? For example, "the lookup of result in process", "hosts being assigned large number or [of?] results to compute", and "The host. think it received", among others. These are not normal for the seti@home front page or any technical message one usually finds on the site.

After a short break the servers are getting back on their feet, but are still somewhat unstable - latest request was greeted thus:

19/11/2012 21:30:30 SETI@home Sending scheduler request: To fetch work.
19/11/2012 21:30:30 SETI@home Reporting 142 completed tasks, requesting new tasks for GPU
19/11/2012 21:30:32 SETI@home Scheduler request failed: Server returned nothing (no headers, no data)