For a good part of this afternoon and evening there has been sort of an explosion of AP tasks getting split and sent out to the Seti universe. The question -- is this just a figmentation of my imagination or are we finally going the get APs split on a consistent basis? And before somebody hits me upside the head, I know that both MB & AP work are the same tape, but it seems that all we have had for the last couple of months are straight MB. My AP machine wants to know as it's pulling its hair out wondering if its is going to work AP only again. I hate it when my machines start throwing temper tantrums.

---

I don't buy computers, I build them!!

For a good part of this afternoon and evening there has been sort of an explosion of AP tasks getting split and sent out to the Seti universe. The question -- is this just a figmentation of my imagination or are we finally going the get APs split on a consistent basis? And before somebody hits me upside the head, I know that both MB & AP work are the same tape, but it seems that all we have had for the last couple of months are straight MB. My AP machine wants to know as it's pulling its hair out wondering if its is going to work AP only again. I hate it when my machines start throwing temper tantrums.

It's only been about 2 weeks. At one time they had over 30 tapes mounted to be split, but as you know, APs split out faster than MBs, so once the APs were all split and gone, we had to wait for the MBs to work through. I HOPE they are not going to load that many tapes again. I suspect the AP supply will remain intermittent, but with shorter gaps between batches.

---

Donald
Infernal Optimist / Submariner, retired

It's only been about 2 weeks. At one time they had over 30 tapes mounted to be split, but as you know, APs split out faster than MBs, so once the APs were all split and gone, we had to wait for the MBs to work through. I HOPE they are not going to load that many tapes again. I suspect the AP supply will remain intermittent, but with shorter gaps between batches.

Yep. This 2-week hiatus was unusual, not because there was a hiatus, but because of what started it. What started it is that usually there are only 5-15 tapes loaded to be split, but we ended up with nearly 50 and it just took a while for MB splitting to catch up.

Hopefully, we stay in the 5-15 tape range for a while and 2-3 days between active AP splitting goes mostly unnoticed.

---

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

Got one now.
Tullio

---

It's only been about 2 weeks. At one time they had over 30 tapes mounted to be split, but as you know, APs split out faster than MBs, so once the APs were all split and gone, we had to wait for the MBs to work through. I HOPE they are not going to load that many tapes again. I suspect the AP supply will remain intermittent, but with shorter gaps between batches.

Yep. This 2-week hiatus was unusual, not because there was a hiatus, but because of what started it. What started it is that usually there are only 5-15 tapes loaded to be split, but we ended up with nearly 50 and it just took a while for MB splitting to catch up.

Hopefully, we stay in the 5-15 tape range for a while and 2-3 days between active AP splitting goes mostly unnoticed.

It may have been 2 weeks, but it felt like 2 months. Anyway, it's nice to get back to what I hope is a steady AP diet for this machine. I don't remember when MB work was starved even though it takes longer to split. Still wish there was a way to pre-split MB from AP at the source, to separate tapes, so that there is a steady constant and consistent flow of work for those of us that desire to process AP only on their machines. Another big wish will be to allow VLAR to be processed on GPUs for those that desire and can handle them.

---

I don't buy computers, I build them!!

I grabbed two of them. One brand spanking new and the other a -6. I'm really anxious to see how they do on this new machine of mine.

---

PROUD MEMBER OF Team Starfire World BOINC

Okay, finished the first one, the -6, runtime was 26,739 and CPU time was 22,148. This was run on the CPU- optimized so I don't think it was bad at all. Credit given 698.68. I think I screwed up on installing the opt-app and forgot to mark APs to go to the GPU. I'll play around with it this way for awhile though. Of the other two that completed it one was running NVidia open CL and the other was running ATI open CL. Both way faster than me.

---

PROUD MEMBER OF Team Starfire World BOINC

I have an AP result not yet validated:http://setiathome.berkeley.edu/workunit.php?wuid=1275514255
The wingmen's results are different. One exited, too many pulses. The other result is identical to mine. Yet they are validated, mine is not.
Tullio

---

I have an AP result not yet validated:http://setiathome.berkeley.edu/workunit.php?wuid=1275514255
The wingmen's results are different. One exited, too many pulses. The other result is identical to mine. Yet they are validated, mine is not.
Tullio

Common problem. This problem has been around for years.

_0 missed the deadline
_2 (you) got the task
_0 reported before you did and got validated against _1

Then for some reason, _2 does not validate because the WU has already been marked as validated, and either the result files to compare _2's results against are no longer available, or there is a logic problem in the database or other server-end functions.

The way it works is once two results are returned, they are validated. If the validator decides they are the same results, the contents of the results are assimilated into the database. The database entries for that WU (what you see on the website) get marked to be deleted 24 hours after assimilation. Once the WU has been deleted from the database, any files associated for that WU get deleted from disk.

So.. "validator -> assimilator -> db_purge -> file_deleter" is the way it is supposed to go, but the many thousands of WUs (of all types of crunching on this project) that end up getting stuck like this show that there is some bad logic somewhere in the server code. It isn't a high-priority to fix, and I'm not even sure anyone really has any good idea where the problem actually is.

I have been suggesting that it seems that there is no result file to compare _2 with, but I have never heard a response that said the result files are actually still on disk or not. It almost seems like what happens is "validation -> assimilation -> file_deleter" and db_purge realizes there are still results waiting to come back, so it just sits there and can't do anything.

If we could get some verification from the staff for answers to a couple of simple questions, the community as a whole may be able to point to a small area of server code to look at. I know once two results get compared and a canonical result is chosen, the other result is deleted or discarded. Maybe that's where the problem is, because the validator is trying to compare all three results but only finds the one canonical and won't move on to the next instruction.

---

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

I pulled a bunch...mucho happiness

---

My AP machine is verrrrry happy right now, it's been pumping out APs for the last 2-1/2 days, keep them coming. Next on the wish list is VLARs on the GPUs.

---

I don't buy computers, I build them!!

And it appears we've blasted through the pile of tapes again and are waiting for MB to catch up. All I've gotten in the past 24 hours are re-sends. Hopefully it doesn't take another 14 days to get more tapes this time around.

---

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

It was fun while it lasted, I've got 2 days worth of GPU work and a month's work of CPU, so unless they stoke the fires again soon I'm back to crunching cuda_50 @ 4 on each GPU. But then again, I might turn Milkyway loose on the GPUs and give them a hand for a while. Maybe one of these days, before I get too old and too bald, I'll get back my almost 70k rac.

---

I don't buy computers, I build them!!