Almost 120,000 AP's are still awaiting validation, and the AP validators are *NOT* off (unlike the AP assimilators). As there are only 250 AP results yet to be returned, the math seems waaaaay off ;-)

As we're past all reasonable 30 day time outs, might these be AP Wingmen who bailed and for some reason these AP's weren't re-issued? Or might the number represent that in the AP DB woes, about 120K in-process records got trashed? Other thoughts?

Waiting for validation are WUs that were processed and returned, had two wingmen do the same thing, and were waiting for the validator to grant credit and move on to assimilation. Since the AP database is not available, the validator can't access the database to grant the credit (I think..) and move the WU on to the assimilator, which is disabled.

Once the database gets fixed and becomes available again, credit will be granted, WUs will be validated, and then assimilated, then purged.

---

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

the validator can't access the database to grant the credit

I'm not so sure about that. Credit is tracked elsewhere (User ID), thus those AP's should get validated fine by the running AP validator processes, credited, and then moved off into the assimilator queue (which, yes, perhaps those 3 steps are atomically applied, thus blocking --- In which case, why leave the AP validators on when the rest of AP is shut down (presumably not to avoid time-outs as the DB's & services exhibit plenty of downtime as it is without such timeouts occuring, thus that potential is already architected in)?).

I had some AP work units that were uploaded in early Dec. just go through validation. wuid 534401745 was finished on Dec 1st & just validated a day or two ago. I've got a total of 3 that validated the past few days over the 3 machines I have enabled for AP.

I figure it's part of their ongoing process of trying to fix the few corrupt rows in the AP database.

---

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

Just in case nobody noticed.. AP has been turned back on with the exception of the splitters. There are results and WUs that are in the purge queue now, and the "awaiting validation" count is shrinking.

---

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

Astropulse Splitters are now online. :)

Claggy

I'll be looking for work when I get home

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

I'll be looking for work when I get home

Form an orderly queue - the Cricket Graph has jumped from below 50 Mbit/sec (daily average) to over 85 Mbit/sec already.

... and they're splitting AP's from *OLD* tapes !! That potentially opens up a floodgate of AP packets all the way back to 2005 (unless there is something special about March 2007 and forward).

I was more interested in the "results in the field".. this morning before the splitters were turned on it was 65. Just 65. Now look at it. each one of those is 8MB pushed across that link.

---

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

I was more interested in the "results in the field".. this morning before the splitters were turned on it was 65. Just 65. Now look at it. each one of those is 8MB pushed across that link.

Uh oh! Over 40 new AP results returned in the last hour. That probably means errors.

---

Join the PACK!

I was more interested in the "results in the field".. this morning before the splitters were turned on it was 65. Just 65. Now look at it. each one of those is 8MB pushed across that link.

Uh oh! Over 40 new AP results returned in the last hour. That probably means errors.

I'm thinking so..

Result turnaround time (last hour average) 1.70 hours

---

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

I was more interested in the "results in the field".. this morning before the splitters were turned on it was 65. Just 65. Now look at it. each one of those is 8MB pushed across that link.

Uh oh! Over 40 new AP results returned in the last hour. That probably means errors.

I'm thinking so..

Result turnaround time (last hour average) 1.70 hours

Maybe they are just AP shorties? Anyone seen a result form the new ones yet? Only for 1 on all of my machines. I might force it to run tomorrow when I get into work to see if it fails quickly.

---

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

Uh oh! Over 40 new AP results returned in the last hour. That probably means errors.

Agreed, and since then the return % rate has tripled with very little passage of time. Something seems amiss with the AP's being split from the scrubbed '07 data.

A few threads back, SkilDude said something about these older tapes (and they might have actually still been tapes back then) being too noisy for AP. So perhaps that's still the case despite radar blanking, if these actually are erroring out.

Ok, a round of kudos for anyone who can provide a link to one of these AP result sets ;-)

Something I never understood about AP....

When AP work is being split and sent, the Cricket graphs show the increased server bandwidth. Given the increased size of the AP WUs, this is not too surprising, at first.

But wouldn't the increased crunch time of AP work eventually offset the increased bandwidth to send them out and settle down a bit once the pipeline is filled? Or does the percentage of increased bandwidth to send them exceed the increase in the time to crunch them?

This of course, would be if they were crunching normally and not showing signs of possible error problems as is currently being discussed.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

When AP work is being split and sent, the Cricket graphs show the increased server bandwidth. Given the increased size of the AP WUs, this is not too surprising, at first.

But wouldn't the increased crunch time of AP work eventually offset the increased bandwidth to send them out and settle down a bit once the pipeline is filled? Or does the percentage of increased bandwidth to send them exceed the increase in the time to crunch them?

That's the way I understand it.

---

When AP work is being split and sent, the Cricket graphs show the increased server bandwidth. Given the increased size of the AP WUs, this is not too surprising, at first.

But wouldn't the increased crunch time of AP work eventually offset the increased bandwidth to send them out and settle down a bit once the pipeline is filled? Or does the percentage of increased bandwidth to send them exceed the increase in the time to crunch them?

That's the way I understand it.

8mb data vs 300-400kb data. So AP tasks are about 20 times more data to transfer, but only require 10 times the amount of time to process.

---

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

When AP work is being split and sent, the Cricket graphs show the increased server bandwidth. Given the increased size of the AP WUs, this is not too surprising, at first.

But wouldn't the increased crunch time of AP work eventually offset the increased bandwidth to send them out and settle down a bit once the pipeline is filled? Or does the percentage of increased bandwidth to send them exceed the increase in the time to crunch them?

That's the way I understand it.

8mb data vs 300-400kb data. So AP tasks are about 20 times more data to transfer, but only require 10 times the amount of time to process.

Ahh....
And here all along I was under the impression that AP work was bandwidth sparing...

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

When AP work is being split and sent, the Cricket graphs show the increased server bandwidth. Given the increased size of the AP WUs, this is not too surprising, at first.

But wouldn't the increased crunch time of AP work eventually offset the increased bandwidth to send them out and settle down a bit once the pipeline is filled? Or does the percentage of increased bandwidth to send them exceed the increase in the time to crunch them?

That's the way I understand it.

8mb data vs 300-400kb data. So AP tasks are about 20 times more data to transfer, but only require 10 times the amount of time to process.

Ahh....
And here all along I was under the impression that AP work was bandwidth sparing...

cursed math getting in the way!

---

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

When AP work is being split and sent, the Cricket graphs show the increased server bandwidth. Given the increased size of the AP WUs, this is not too surprising, at first.

But wouldn't the increased crunch time of AP work eventually offset the increased bandwidth to send them out and settle down a bit once the pipeline is filled? Or does the percentage of increased bandwidth to send them exceed the increase in the time to crunch them?

That's the way I understand it.

8mb data vs 300-400kb data. So AP tasks are about 20 times more data to transfer, but only require 10 times the amount of time to process.

Ahh....
And here all along I was under the impression that AP work was bandwidth sparing...

cursed math getting in the way!

Indeed......
This was a major misunderstanding on my part from the launch of AP.
Don't know quite where I got it from, but I always thought that the massive crunch times of AP compared to MB were gonna save some work on the server's part...
But now I have been enlightened.

No matter, AP is enabled on all of my rigs, and the kitties shall be happy to process any work the servers send our way.

Meow meow.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster