Panic Mode On (81) Server Problems?

Add that to the disruptive effect on those not in the AP land...

It is a bit troublesome that this problem seems to be re-enacted without much in the way of a learning process....

Perhaps since there seems to be this compulsion to revisit this operational problem what folks could do is announce in advance something along these lines:

AP disruptive release anticipated -- consider shifting over to another project until we realize it is disruptive and back off the process

Insert rueful smile/shrug here.

The production rate of AP "splitting" is probably heavily influenced by the amount of server-side blanking. The reason the AP splitters were going so slowly might possibly have been a lot of detected RADAR RFI, in which case splitting those tapes might be considered less worthwhile than cleaner data.

Joe

I thought the server-side stuff was supposed to be detecting APs that would be 100% blanked and not even send them out in the first place.

If they know what sections to inject random noise into.. they know what sections need to be blanked. A simple byte-map would handle that, plus some tiny bit of splitter logic.

Basically if your list of byte offsets and byte lengths are defined, then the splitter can then look at the list and say "oh, this WU that I'm splitting starts and finishes inside one length of blanked data, tell the science DB this one is bad and I'm moving on to the next start point."

Saves 16 MiB of data transfer right there. Do that a couple thousand times... and it adds up real fast.
____________

Linux laptop uptime: 1484d 22h 42m
Ended due to UPS failure, found 14 hours after the fact

Still struggling to get work, "Couldn't connect to server" is still the standard response to a Scheduler request.
Very, very few requests result in contact, and then "Failure when receiving data from the peer" tends to be the response.
____________
Grant
Darwin NT.

Still struggling to get work, "Couldn't connect to server" is still the standard response to a Scheduler request.
Very, very few requests result in contact, and then "Failure when receiving data from the peer" tends to be the response.

Boinc Stats say Seti is offline since yesterday, see below, while the Server Status page seems showing it´s OK, or at least, there should be something available to crunch. What gives?

SETI@Home Production offline
since 2013-02-04 17:45:21 0 2262910 39 5:40
SETI@Home Beta Beta offline
since 2013-02-04 19:45:50 0 46753 1 3:00

Does anyone have an idea of when this might become a bit more stable?
I cannot even report completed tasks.

Does anyone have an idea of when this might become a bit more stable?

When they get more bandwidth, split the projects by ussing two separate connection one for MB and one for AP or stop/slow the production of WU on one of them. Nothing in the near future as noticed.