Lots of processes on the Server Status Page are presently not running/disabled (Validators, assimilators & AP splitters).
And those that say they are running, aren't. There are supposedly 6 PFB splitters running, but output has dropped to barely 10/s; that many splitters should be producing 30/s. Ready-to-send buffer is less than half full, so there should be no work to send in a hour or 3.
Hope they can sort it out soon, or it will be a weekend without any work.

Basically, every process that has to do with AP shows as disabled.

The AP science database is showing as running again. The rest of the AP processes still show disabled. Still, this is a good sign.

Maybe it will take overnight for marvin to get all synced up again?

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

So I surmise that APs are not being sent out into the wild yet.

---

Okay, it's after 6pm in Berkeley. I'm assuming Beta won't be back for the weekend. I let my tablet have some Main work and will do the same with my phone in a few minutes.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Something is realy wrong with the servers, AP split is stuck for days and now the MB spliting seems to work very wierd too (15 channels in progress!).

Does anyone realy knows what is happening? I see the msg about bruno but that was days ago.

---

Something is realy wrong with the servers, AP split is stuck for days and now the MB spliting seems to work very wierd too (15 channels in progress!).

Does anyone realy knows what is happening? I see the msg about bruno but that was days ago.

Are you still seeing to many AP channels in progress? It has been showing 7 for me since they took all of the AP services down the other day. Currently all of the AP services are still disabled so there are really 0 active.
However I do see 14 in progress MB. Which is interesting considering there are only 8 MB splitters. With 7 of then running.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Something is realy wrong with the servers, AP split is stuck for days and now the MB spliting seems to work very wierd too (15 channels in progress!).

Does anyone realy knows what is happening? I see the msg about bruno but that was days ago.

Are you still seeing to many AP channels in progress? It has been showing 7 for me since they took all of the AP services down the other day. Currently all of the AP services are still disabled so there are really 0 active.
However I do see 14 in progress MB. Which is interesting considering there are only 8 MB splitters. With 7 of then running.

I'm pretty certain that 'in progress' can mean 'started, but not completed'. In the same way, the BOINC clients running on our own computers can switch from project to project, leaving unfinished tasks 'waiting to run', and return to them later.

If you stop your local BOINC client, and start it again later, it won't necessarily restart exactly the same set of projects and tasks that were active before you shut it down. I think the splitters work the same way: if they are shut down for weekly maintenance, and restarted afterwards, they might start on a different batch from the ones which were active before the outrage. The cricket graph suggests that the server daemons were shut down for about an hour yesterday morning (Pacific time): I suspect the new tapes were added then, and the splitter tape selection algorithm saw the new batch of tapes and picked them when the daemons started back up.

Something is realy wrong with the servers, AP split is stuck for days and now the MB spliting seems to work very wierd too (15 channels in progress!).

Does anyone realy knows what is happening? I see the msg about bruno but that was days ago.

Are you still seeing to many AP channels in progress? It has been showing 7 for me since they took all of the AP services down the other day. Currently all of the AP services are still disabled so there are really 0 active.
However I do see 14 in progress MB. Which is interesting considering there are only 8 MB splitters. With 7 of then running.

I'm pretty certain that 'in progress' can mean 'started, but not completed'. In the same way, the BOINC clients running on our own computers can switch from project to project, leaving unfinished tasks 'waiting to run', and return to them later.

If you stop your local BOINC client, and start it again later, it won't necessarily restart exactly the same set of projects and tasks that were active before you shut it down. I think the splitters work the same way: if they are shut down for weekly maintenance, and restarted afterwards, they might start on a different batch from the ones which were active before the outrage. The cricket graph suggests that the server daemons were shut down for about an hour yesterday morning (Pacific time): I suspect the new tapes were added then, and the splitter tape selection algorithm saw the new batch of tapes and picked them when the daemons started back up.

That does make sense, but I was thinking that during maintenance it typically showed 0 in progress. That may be due to specific things being offline at the time I suppose.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I'm going 0.25 on my work buffer (BOINC 6.10.58), in preparation for when AP splitting starts again. I don't want a big cache of MB's when and if AP is available again.

I wrote a Python script to do that automatically. I'm giving up on it though, things are just so chaotic it's pointless. I set SAH it to accept only AP and added Einstein, 3,333 credits for a wu is ok by me.

Well, at least we're being told the reason for the problems (AP drought for example), as well as the approximate date for when it should be fixed...

I'm starting to think part of the Project is to elicit speculation from people who can only observe ;-)

Well, I've observed file 28mr11ab has already made it through one Tuesday session and remained stuck. So, expecting another Tuesday session to unstick it, and the others, may be optimistic. I've also observed that my 3 hosts have many more APv7 listings than APv6. We can only observe the APv6 numbers and speculate on the APv7 numbers. Looking at my 3 main hosts I see;
AstroPulse v6 (53) · AstroPulse v7 (990)
AstroPulse v6 (67) · AstroPulse v7 (1281)
AstroPulse v6 (177) · AstroPulse v7 (3696)
All we can observe are the APv6 numbers, Workunits waiting for assimilation: 41,963
We can speculate on the APv7 numbers.

I'm not really thrilled about using the same technology that has failed to find ET after 15 years and covering the entire observable sky at least once, maybe twice. I thought the newer technology might produce different results. Right now it appears I'm doing the same thing over again and expecting different results. Someone once said something about that scenario...

Someone once said something about that scenario...

Yes, it's called insanity

Doesn't seem likely, given that the servers run on UTC, but as Ford said to Arthur on Fintlewoodlwix, in an infinite universe, anything is possible.

Answer is 42

What do you get if you multiply six by nine?

Rather more than you get if you multiply six by seven? ;)

6 times 9 = 42 (base 13)

07/11/2014 19:45:07 SETI@home Message from server: Project is temporarily shut down for maintenance

Are we getting AP work for the weekend?

Guess not.

The project always intended to review the results it received, and Nitpicker was designed to take a second sift through the results already returned. For various reasons it is only running in Beta mode in the background. The algorithms used today are quite different to those used in Seti Classic, therefore it is reasonable to re-run certain results to get even more information.

There is also the time dimension. That means looking in the same direction at multiple points in time. Signals can be time varying. Wouldn't it be nice to catch the next WOW signal? As far as we know that happened only once.

SETI might have to keep looking for the next 100 years to hit on something like that. I hope they do. Keep looking for that long, I mean.

Whatever the issue with the PFB splitters was, it seems to have sorted itself out. They're now keeping ahead of demand & able to rebuild the ready-to-send buffer & shut down when it is full & restart when it drops, as per normal.

However the AP validators, assimilators & splitters still all remain offline.

---

Grant
Darwin NT

However the AP validators, assimilators & splitters still all remain offline.

Also MB results waiting DB purging is over 1.8 million results it has been hovering between 1.7 and 1.8 for a few days now. I think this is to do with some services still not running on the up load server

---

However the AP validators, assimilators & splitters still all remain offline.

Also MB results waiting DB purging is over 1.8 million results it has been hovering between 1.7 and 1.8 for a few days now. I think this is to do with some services still not running on the up load server

MB results waiting DB purging has averaged 1.55 million for the last year.

sah_purge

Eric has posted in technical news.

http://setiathome.berkeley.edu/forum_thread.php?id=76068

---

Eric's post clears up a lot of questions.

Basically, expect it to be at least another 7 days before AP gets split.


Speaking of splitters, when I checked a few minutes ago, MB was breezing along at nearly 40/sec and the RTS buffer was over 300k. Looks like AP is going to have a bit of catching up to do once that can be split again, but it will not take long for it to quickly go back into waiting for MB to catch up.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

However the AP validators, assimilators & splitters still all remain offline.

Also MB results waiting DB purging is over 1.8 million results it has been hovering between 1.7 and 1.8 for a few days now. I think this is to do with some services still not running on the up load server

MB results waiting DB purging has averaged 1.55 million for the last year.

sah_purge

Thanks Richard, I was unaware it had been a round 1.5 million for a year

---

However the AP validators, assimilators & splitters still all remain offline.

Also MB results waiting DB purging is over 1.8 million results it has been hovering between 1.7 and 1.8 for a few days now. I think this is to do with some services still not running on the up load server

MB results waiting DB purging has averaged 1.55 million for the last year.

sah_purge

Thanks Richard, I was unaware it had been a round 1.5 million for a year

Since results are purged about 24 hours after validation, I suspect that multiplying the "Results received in last hour" number by 24 will usually give a rough approximation of the "Results waiting for db purging" figure. Of course, server outages would screw that up a bit.