I was wondering. The ati-nocal and ati5-nocal. I have been getting storms of them. They are short to very short. Is SETI trying for a quick turn around on these type of wu's?

There are no ati-nocal and ati5-nocal wus. Only tasks marked as ati-nocal and ati5-nocal after you ask the server for work. We often get groups of VHAR tasks or "shortie storms". Pretty standard things. Unless your GPU is having errors and just trashing all of the task it gets, but looking over your tasks they are just VHARs. So nothing to worry about.

Those tasks at true angle range 0.408901 aren't VHARs, http://setiathome.berkeley.edu/results.php?hostid=7368710&offset=80
He's just having a hard time believing his card is working Sooo much better than before, http://setiathome.berkeley.edu/result.php?resultid=4175896531

The New App r2929 is Much better than the old r1831, but, I'm having a hard time believing it's that much better. Perhaps his recent repairs helped a little.
Anyway, it's good to see his card working the way it's suppose to. Hopefully CreditFew will realize an AR of 0.408901 should be scoring around 100 credits before too much longer.

Well since you know exactly which tasks I was looking at when they mentioned they are running "very short tasks". Why not look at the same ones I did.
http://setiathome.berkeley.edu/result.php?resultid=4248289513
http://setiathome.berkeley.edu/result.php?resultid=4248212965
http://setiathome.berkeley.edu/result.php?resultid=4248212969

Okay. I am totally blown away by my GPU cards performance. My RAC has gone up 400% since I replaced the CPU cooler and PSU.

It does seem to be preforming better than just the new app would warrant. It might go even faster, you should try each of those 3 mb_cmdlines I gave you for about half a day each. The one with all the numbers set at 256 was the last one being used on my Vista host. It might be the best for Windows, you'll just have to try it...for a few hours.
Just in time for the Cruncher challenge later this month...

It does seem to be preforming better than just the new app would warrant. It might go even faster, you should try each of those 3 mb_cmdlines I gave you for about half a day each. The one with all the numbers set at 256 was the last one being used on my Vista host. It might be the best for Windows, you'll just have to try it...for a few hours.
Just in time for the Cruncher challenge later this month...

I am seeing credit numbers climbing in the 8000-9000's lately.

---

How the hell can this validate?

Stderr output
<core_client_version>7.4.42</core_client_version>
<![CDATA[
<stderr_txt>

</stderr_txt>
]]>

http://setiathome.berkeley.edu/workunit.php?wuid=1819553789

I have more than a few tasks doing this

And I haven't figured out yet why I'm shooting blanks on MB GPU tasks :(([/url]

---

How the hell can this validate?

Stderr output
<core_client_version>7.4.42</core_client_version>
<![CDATA[
<stderr_txt>

</stderr_txt>
]]>

http://setiathome.berkeley.edu/workunit.php?wuid=1819553789

I have more than a few tasks doing this

And I haven't figured out yet why I'm shooting blanks on MB GPU tasks :(([/url]

There's an old thread about that. There were even Apps developed to stop it. I'm not sure about the current status, however, the old Apps are here, http://www.jgopt.org/download.html
The one you would want is - Lunatics_x41zc_win32_cuda50_commode_exeonly.7z, since you are running setiathome enhanced x41zc, Cuda 5.00 under Anonymous platform it wouldn't be very hard to give it a try.
If it were me, I'd probably downgrade to a different version of BOINC....if the Commode trick doesn't work.

How the hell can this validate?

Stderr output
<core_client_version>7.4.42</core_client_version>
<![CDATA[
<stderr_txt>

</stderr_txt>
]]>

http://setiathome.berkeley.edu/workunit.php?wuid=1819553789

I'm not 100% sure but it could be because the under the result that ran for over 13,000 seconds & gave output data

---

How the hell can this validate?

Stderr output
<core_client_version>7.4.42</core_client_version>
<![CDATA[
<stderr_txt>

</stderr_txt>
]]>

http://setiathome.berkeley.edu/workunit.php?wuid=1819553789

I have more than a few tasks doing this

And I haven't figured out yet why I'm shooting blanks on MB GPU tasks :(([/url]

To answer your question. SETI@home result data is separate from stderr_txt.

---

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

Thanks Hal.

---

BTW, Some of them are Not Validating, as here, Invalid tasks for computer 7454279.
Those are called Instant Invalids in the thread here;
Strange Invalid MB Overflow tasks with truncated Stderr outputs...
It's Exactly what you are experiencing, an Invalid Overflow with a truncated Stderr and a Spike count of less than 30.

Yes, that thread was a Long time ago, the problem was identified, yet it still exists.

Hey TBar,

Yes I have a pile of invalids for June 29/30. I reinstalled Lunatics to fix some AP problems and inadvertently installed cuda32 for MB. So it errored out my entire GPU cache until I caught it and reinstalled.

I only have 1 error since then.

EDIT: opps I meant 1 invalid since then, my 3 aborted errors are from me getting rid of cuda32 tasks before reinstalling.

That's why I was asking about blank stderr files validating, been watching to make sure i'm running clean.

---

Hey TBar,

Yes I have a pile of invalids for June 29/30. I reinstalled Lunatics to fix some AP problems and inadvertently installed cuda32 for MB. So it errored out my entire GPU cache until I caught it and reinstalled.

I only have 1 error since then.

That One 'Error', actually an Invalid, just happens to be an Instant Invalid on an Overflow with a truncated Stderr and a Spike count of less than 30. As are a few of the others.
Right...
If you follow the thread you will discover part of the Stderr is used by the Validator on certain Overflows.
Whenever your results are Invalidated as soon as the validator looks at them, it means something is missing/wrong.
What is missing is the part of the Stderr the validator is looking for.
But, nevermind.

Yes, that thread was a Long time ago, the problem was identified, yet it still exists.

Most irritating to me, not only was the problem identified, but a simple fix for the validation side of it was proposed by Joe Segur and passed along to Eric....never to be heard of again. While Jason's commode build seems to successfully address the Stderr truncation, it only covers NVIDIA GPUs. Unfortunately, the truncations can happen on CPUs and ATI GPUs, as well, so the validation-side fix would be more comprehensive, even though it wouldn't eliminate the truncations. I usually see the truncations happening every day, but only a small subset of those end up Invalid, currently averaging about 5 a month for me in 2015.

Yes, that thread was a Long time ago, the problem was identified, yet it still exists.

Most irritating to me, not only was the problem identified, but a simple fix for the validation side of it was proposed by Joe Segur and passed along to Eric....never to be heard of again. While Jason's commode build seems to successfully address the Stderr truncation, it only covers NVIDIA GPUs. Unfortunately, the truncations can happen on CPUs and ATI GPUs, as well, so the validation-side fix would be more comprehensive, even though it wouldn't eliminate the truncations. I usually see the truncations happening every day, but only a small subset of those end up Invalid, currently averaging about 5 a month for me in 2015.

I ran the commode build for months and months on my Win 8.1 system and never had the truncated Stderr again. Then one day I tried it with the normal build and still haven't had the problem. I attribute it to BOINC 7.2.33 which seems to be the best version I've come across. That's why it's on all my hosts, plus, look at what Eric is running, http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=72274. I wonder if Eric has had any of those truncated Stderrs, I really haven't checked...
;-)

I attribute it to BOINC 7.2.33 which seems to be the best version I've come across.

Well, take a look at my active hosts and see which BOINC version I'm running....on all of them. :^) I still average a couple of truncations a day, I think, though as I mentioned, only(!) about 5 a month end up Invalid.

Hi folks!

I just checked my pending MBs and noticed some recent results haven't validated yet, although my wingmen and I finished the WUs. For example http://setiathome.berkeley.edu/workunit.php?wuid=1830619685
Any idea what's wrong with the validators?

I attribute it to BOINC 7.2.33 which seems to be the best version I've come across.

Well, take a look at my active hosts and see which BOINC version I'm running....on all of them. :^) I still average a couple of truncations a day, I think, though as I mentioned, only(!) about 5 a month end up Invalid.

In that case, I'd have to resort to the suspicion my GTS250 isn't fast enough to outrun the Windows file system, most of the time. Since it's strictly a Windows problem, and I'm only running 1 Windows host, I suppose my other systems are immune...lucky me.

Hi folks!

I just checked my pending MBs and noticed some recent results haven't validated yet, although my wingmen and I finished the WUs. For example http://setiathome.berkeley.edu/workunit.php?wuid=1830619685
Any idea what's wrong with the validators?

27 June was the day that S@H shut down while the CoLo did some power systems work. My best guess is that when the project came back up, the validators missed some tasks. In the past, IIRC, those Tasks sit on the servers until the Deadline date, which for that Task is 18 August, then they get revisited by the Validators. If they don't get picked up then, Eric or Matt can manually validate them.

---

Donald
Infernal Optimist / Submariner, retired

Hi folks!

I just checked my pending MBs and noticed some recent results haven't validated yet, although my wingmen and I finished the WUs. For example http://setiathome.berkeley.edu/workunit.php?wuid=1830619685
Any idea what's wrong with the validators?

It seems that, from time to time, the validators take a nap and some WUs like that one slip past them. Last September I had a whole bunch of tasks that fell into a validation black hole that lasted about 10 minutes or so. Richard Haselgrove responded to my report, as follows:

There is a failsafe in place, which weeds out most errors like that - the transitioners/validators take a second look at stuck WUs on the day the original deadlines would have passed (three weeks for shorties, six/seven/eight weeks away for the rest).

He was right. When the original deadline was reached for those tasks, the validators successfully picked them all up. In the case of your task, that should be about August 18. You'll just have to be patient until then.

Thanks Donald & Jeff. Panic mode off until the deadline :D

Uh, oh...
I see the SSP has not updated in over an hour, and the loading of stats seems to be crawling again.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Uh, oh...
I see the SSP has not updated in over an hour, and the loading of stats seems to be crawling again.

I am going to assume that boinc.berkeley.edu suddenly being offline as well is unrelated.

---

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