I have 236,000 + should be a great bounce...

I hear you. I'm at 81k now. Looking forward to the logjam breaking.

And getting bigger...Pending credit: 246,567.47

---

Official Abuser of Boinc Buttons...
And no good credit hound!

I'm no where near some of the rest of you but I did just break 10,000 pending today. My oldest one was from back on Dec 2. The first wingman timed out on Jan 19. That computer still shows an average turnaround time of 14 days. The WU reissued the same day to a computer with an average turnaround time of 5 days. Now it looks like that one will have to wait to timeout on Mar 8. It doesn't look like the average turnaround time means much on these computers that are no longer connecting.

---

But if that option was available and everyone did it, then there would end up being not enough tasks waiting to be validated (until the task got to high priority mode). Someone has to go first in the wingman pair.

Actually, wouldn't that mean that the second WU couldn't be issued until it "needed validation" and that doesn't happen until the first one is done?

Ah, I didn't consider the option of not issuing the 2nd WU until the first one was ready to be validated. I was picturing both WUs being issued and each one waiting for the other to finish first, thus neither would start processing until the deadline was about to be reached.

However, not issuing the 2nd WU until the first is returned only introduces even longer wait times and more pending credit for those who don't select "Validation: yes"

---

"Life is a tragedy for those who feel, and a comedy for those who think."

"I never get into an argument that I cannot win."

But if that option was available and everyone did it, then there would end up being not enough tasks waiting to be validated (until the task got to high priority mode). Someone has to go first in the wingman pair.

Actually, wouldn't that mean that the second WU couldn't be issued until it "needed validation" and that doesn't happen until the first one is done?

Ah, I didn't consider the option of not issuing the 2nd WU until the first one was ready to be validated. I was picturing both WUs being issued and each one waiting for the other to finish first, thus neither would start processing until the deadline was about to be reached.

However, not issuing the 2nd WU until the first is returned only introduces even longer wait times and more pending credit for those who don't select "Validation: yes"

I think the best things to add is "It's not broken, so it doesn't need fixed."

---

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

...
If a task validates, it transitions out of BOINC and into the science database. If it doesn't validate, or if it times out, a new result is created and assigned. In fact, that's how we get "new work" when the splitters are off.

In order to make this actually "do" something, you'd have to give those reissued work units priority, and that would have to extend to the BOINC client.
...

The existing BOINC accelerating retries project option is quite close to what's wanted. It gives reissued WUs priority and will only send them to hosts with a reasonably short average turnaround combined with a low error rate.

                                                                Joe

The existing BOINC accelerating retries project option is quite close to what's wanted. It gives reissued WUs priority and will only send them to hosts with a reasonably short average turnaround combined with a low error rate.
Joe

Does that mean we can 'avoid' being a target for re-issued VLARS by increasing our queue length, turn around time, and returning VLARS with an error instead of doing them on our CPU?

... just kidding

The existing BOINC accelerating retries project option is quite close to what's wanted. It gives reissued WUs priority and will only send them to hosts with a reasonably short average turnaround combined with a low error rate.
Joe

Does that mean we can 'avoid' being a target for re-issued VLARS by increasing our queue length, turn around time, and returning VLARS with an error instead of doing them on our CPU?

... just kidding

LOL...
Nope. The servers dish out what is in the pot......
It is up to you to configure your crunchers to best deal with it. An ongoing task for those who wish to excel.
To paraphrase..
"Seti life is like a box of chocolates, you never know what, from the servers, you are going to get."

---

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

"Seti life is like a box of chocolates, you never know what, from the servers, you are going to get."

Ain't that the truth!

Didn't mean to upset you or the kitties earlier ... just speaking my mind.

Up to 115,262 pending this morning. It doesn't seem to be going down, ever, and my RAC is only about 19k. However, my overall credit keeps increasing. ?

---

Up to 115,262 pending this morning. It doesn't seem to be going down, ever, and my RAC is only about 19k. However, my overall credit keeps increasing. ?

Just keeps going up but at least I am starting to see a bit of a bounce...
Pending credit: 260,197.55

---

Official Abuser of Boinc Buttons...
And no good credit hound!

My RAC has dropped, my pending is climbing, my total credits are still climbing but have slowed down. Wonder if the new APs have anything to do with it? All my wingmen got APs while my CPUs are still trying to clear off all the VLARs I got?

---

PROUD MEMBER OF Team Starfire World BOINC

Hi all.

I am wondering if it has something to do with the vlar units and rescheduling them to run on the cpu rather than letting vlarkill do it's thing and if this is returning a lot of validation inconclusive results.
Also I have come across a few wu's going through my pendings and noticed even units claiming the same amount of credit as my wingman wont validate, is this because of the difference in time taken between a wu being done by a gpu against one done by a cpu?

Not to clear on it myself and hoping for someone to come forward with an explanation in laymans terms.

Thanks.

---

Looking through a few of your WUs, it looks like you are finding a bit more noise than your wingmates. When was the last time you did a dustbunny roundup? Since it's summer down there it could be heat related too. That or your machine being upside down all the time has caused something to fall out. :-) (sorry, couldn't resist)

Running the rescheduler shouldn't cause any problem with the running of the work units.

---

PROUD MEMBER OF Team Starfire World BOINC

That or your machine being upside down all the time has caused something to fall out. :-) (sorry, couldn't resist)

Are you sure he's the one that's upside down? Maybe we are??

---

...Not to clear on it myself and hoping for someone to come forward with an explanation in laymans terms....

Hi there,
There ARE subtle differences between CPU & GPU applications in the order signals are processed, that manifest differences in [Genuinely] noisy task results. This was one of the design decisions made in the nVidia code, that we wrestle with at Lunatics (among others).

While this shouldn't influence normal <30 signals validation at all, noisy '-9' workunits, where both yourself & the wingman detect >30 signals, the result set may not match between CPU & GPU processed tasks.

As prior posters have mentioned, if you appear to get noisy ( '-9' ) tasks when the wingman doesn't, I would be looking for temperature issues etc, but if both get -9 but do not match, that's the status quo.

Jason

[PS: Both my Cuda & CPU operate just fine being upside down.... ]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Hi all.

I wrangle dust bunnies every month on all the machines and yes it has been hot here the last couple of months but I do monitor temps and back off the overclocks on hot days still it could be that simple.

Thanks for the replies all and keep on crunching.

---