Panic Mode On (81) Server Problems?

Haven't been able to connect for 3 days now, and get the same messages every time:

2/7/2013 10:25:47 AM | SETI@home | Reporting 81 completed tasks, requesting new tasks for CPU and ATI
2/7/2013 10:26:11 AM | SETI@home | Scheduler request failed: Couldn't connect to server
2/7/2013 10:26:15 AM | | Project communication failed: attempting access to reference site
2/7/2013 10:26:16 AM | | Internet access OK - project servers may be temporarily down.

____________

Don't know what happened, just woke up from dozing off for about an hour and noticed that the scheduler has dumped almost a full fuel load into my fastest rig, finishing as I opened my eyes. Now if it would only bless my other rig, both machines will quit bitc(&^$$^%%$inhg.

Sure would be nice to have a place to get some information as to what is being done to correct this issue. Or is there and I just don't know where to look?

Sure would be nice to have a place to get some information as to what is being done to correct this issue. Or is there and I just don't know where to look?

Sure would be nice to have a place to get some information as to what is being done to correct this issue. Or is there and I just don't know where to look?

This is the place.
Welcome to Room 101.

I had been running NNT to trim out the existing work units. I don't run GPU work units from SETI for a number of reasons so I suppose my frustration level is lower than many. These days, as the project repeatedly bounces its collective head against the AP mass traffic tie up - something which has happened many times over the past few months without a resolution -- when I encounter the 'Dead SETI scenaria, I simply suspend the project on the handful of workstations still running SETI and feed projects that don't suffer from this sort of persistent reliability problem.

Perhaps at some point the folks back at the project will figure out that running the high traffic volume AP work units along with the worthless less than one minute CPU work units only serves to reduce the projects effective work and thus might be best avoided.

Until then, I figure to watch closely, run and report in remaining work during the increasingly rare full functionality periods and once that clears, simply watch to see if a project learning process is demonstrated.

Alternatively, it might be part of a grand plan at the project to reduce problems by pushing away users until the traffic levels are low enough to be sustained.

Woke up this morning to find both systems rapidly running out of work. Large backoffs due to not being able to connect to the Scheduler when it tries to do so.
____________
Grant
Darwin NT.

Woke up this morning to find both systems rapidly running out of work. Large backoffs due to not being able to connect to the Scheduler when it tries to do so.

Can't report tasks, scheduler not responding. Anyone sees the same now ?

Now here is a possible cause that super crunchers won't likely realize. Because of the 100 unit max limit is less than what I would normally have based on queue size, the client is requesting more units every five minutes only to be (when I get through) rebuffed due to the 100 unit limit. Now super crunchers are likely to actually have completed units to report every five minutes but for me, maybe only 2-3 units per hour on average. So 9 or 10 pointless requests than are required are sent to the server. Now multiply that by all the hosts that are crunching as "slow" or slower than me (daily RAC ranks my host in the top 4,500-5,000 range) and that adds up to a lot of meaningless requests to the server.

Could that be causing a problem?
____________
"Life is just nature's way of keeping meat fresh." - The Doctor

Could that be causing a problem?

Given the evidence of the past many months, it seems that there is no solution envisioned or affordable for the clear bandwidth choke point, so perhaps instead some software filtering solution might be a reasonable approach to mitigating the obvious problem.

Of course, there is another approach, which takes no effort at all, as people realize that the project reliability has in fact been seriously compromised due to traffic levels, they may do as Greeley suggested -- 'go elsewhere dear user' -- there are in fact many of other more reliable and interesting projects out there.

sometime this afternoon the server "granted" my main rig with 200 WU's ... Soon to discover that all GPU were shorties... increasing the server load even more :S

I hate it when I get tons of shorties. Too much bandwidth for too little credit.

Could that be causing a problem?

It wouldn't be helping with the bandwidth issues, but it wouldn't be causing a problem in it's own right.
We've had Scheduler issues on & off for months now, but the current one began about 4 days ago.
Prior to that, for a while at least, Scheduler repsonses were nice & quick. Now they take forever, if you can connect & if you don't get an error once you've done so.