Any ideia when the AP 7 will be avaiable?

As I said to TBar, that depends on Eric.

AP v7 and AP v6 will produce different results for blanked tasks (because the blanking will be handled differently), so they can't be directly compared. That means that there will have to be new validators, new apps for Mac OS X, new apps for Linux - the whole shooting match.

Some of the issues we've been discussing here - three new revisions this morning alone - will have to go back to Beta, get compiled into new stock apps with Berkeley's digital signing, and be put round the testing cycle again. That's why it's helpful to get the (real) bugs ironed out with the wider community here, because the improvements feed through into into v7 as well, and can all be tested in one go.

But we can't do anything about the quality of the recent data, though.....

I've found that current highly blanked AP tasks are taking as much time to run now on a 4770K w/ 2 x GTX750Ti @ 2ea w/.5 core for each task (2~2.5 hrs.) with these options -use_sleep -unroll 10 -ffa_block 12288 -ffa_block_fetch 6144 -tune 1 64 4 1 -hp as it did running normal tasks with these options -unroll 12 -ffa_block 8192 -ffa_block_fetch 4096 -hp, with 1 core for each task and 3 tasks each. CPU & total run times dropped significantly after inserting the sleep option, and the tune option run times did lower total runtime a little, but the most effect that I've seen from that is the loading of the kernel. I'm noticing one other effect in that Precision X is showing GPU usage is all over the map varying 59-98% when it was usually a steady 99%. I don't know if this if a side effect of heavy blanking or not.

Thats correct Cliff.
Since blanking is processed on CPU on AP6 the GPU usage will drop by the amount of blanking.
This means a task with 86% blanking will only use 24% of the GPU.
This will change for AP7.

Thanks, your explanation suffices enough that I won't remove the tune option for as test.

---

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

Any ideia when the AP 7 will be avaiable?

As I said to TBar, that depends on Eric.

AP v7 and AP v6 will produce different results for blanked tasks (because the blanking will be handled differently), so they can't be directly compared. That means that there will have to be new validators, new apps for Mac OS X, new apps for Linux - the whole shooting match.

Some of the issues we've been discussing here - three new revisions this morning alone - will have to go back to Beta, get compiled into new stock apps with Berkeley's digital signing, and be put round the testing cycle again. That's why it's helpful to get the (real) bugs ironed out with the wider community here, because the improvements feed through into into v7 as well, and can all be tested in one go.

But we can't do anything about the quality of the recent data, though.....

I believe that beta testing desired at one point not to have Lunatics apps involved it testing, is that still the case? If not, would it be beneficial to reattach and start testing.

---

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

Any ideia when the AP 7 will be avaiable?

As I said to TBar, that depends on Eric.

AP v7 and AP v6 will produce different results for blanked tasks (because the blanking will be handled differently), so they can't be directly compared. That means that there will have to be new validators, new apps for Mac OS X, new apps for Linux - the whole shooting match.

Some of the issues we've been discussing here - three new revisions this morning alone - will have to go back to Beta, get compiled into new stock apps with Berkeley's digital signing, and be put round the testing cycle again. That's why it's helpful to get the (real) bugs ironed out with the wider community here, because the improvements feed through into into v7 as well, and can all be tested in one go.

But we can't do anything about the quality of the recent data, though.....

I believe that beta testing desired at one point not to have Lunatics apps involved it testing, is that still the case? If not, would it be beneficial to reattach and start testing.

The AP 7 apps are Lunatics technology.
Brilliant work by our group i might add.

---

With each crime and every kindness we birth our future.

Any ideia when the AP 7 will be avaiable?

As I said to TBar, that depends on Eric.

AP v7 and AP v6 will produce different results for blanked tasks (because the blanking will be handled differently), so they can't be directly compared. That means that there will have to be new validators, new apps for Mac OS X, new apps for Linux - the whole shooting match.

Some of the issues we've been discussing here - three new revisions this morning alone - will have to go back to Beta, get compiled into new stock apps with Berkeley's digital signing, and be put round the testing cycle again. That's why it's helpful to get the (real) bugs ironed out with the wider community here, because the improvements feed through into into v7 as well, and can all be tested in one go.

But we can't do anything about the quality of the recent data, though.....

I believe that beta testing desired at one point not to have Lunatics apps involved it testing, is that still the case? If not, would it be beneficial to reattach and start testing.

The AP 7 apps are Lunatics technology.
Brilliant work by our group i might add.

I always had a ton of faith in the Lunatics.........
That is why I dove in with the new installer, and am so astounded that the new AP app turned out to be such a bummer.
I shall renew my faith when v7 rolls out, and trust that some better thingys are ahead.

Yes, I still have faith in Lunatics. After all, LOL, I've always been one..........

---

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

Any ideia when the AP 7 will be avaiable?

As I said to TBar, that depends on Eric.

AP v7 and AP v6 will produce different results for blanked tasks (because the blanking will be handled differently), so they can't be directly compared. That means that there will have to be new validators, new apps for Mac OS X, new apps for Linux - the whole shooting match.

Some of the issues we've been discussing here - three new revisions this morning alone - will have to go back to Beta, get compiled into new stock apps with Berkeley's digital signing, and be put round the testing cycle again. That's why it's helpful to get the (real) bugs ironed out with the wider community here, because the improvements feed through into into v7 as well, and can all be tested in one go.

But we can't do anything about the quality of the recent data, though.....

I believe that beta testing desired at one point not to have Lunatics apps involved it testing, is that still the case? If not, would it be beneficial to reattach and start testing.

At Beta - especially at a time of intensive testing and rapid (final tweaking) changes like now - it is better to accept the applications that the Beta server sends you, rather than to muddy the waters by supplying your own. That makes it much easier for Eric to assess the quality of the applications under test (error rates, types of error reported, that sort of thing), and make an informed judgement about when it's all ready to deploy here.

In this particular case, the difference between v6 and v7 is primarily in the radar blanking code. That code was originally designed by Josh Von Korff (a PhD student working at the Berkeley labs) six years ago, before any of us were using GPUs to crunch anything. The design he chose proved impossible to migrate to GPUs, which is why we're still using the CPU so heavily. There simply aren't enough SETI@Home staff working in the lab to rewrite the code to be GPU-friendly: that's why the whole application was written by a student in the first place.

The new blanking code (which can run in both CPU and GPU applications) has been contributed by Raistmer for Lunatics, and will be in the applications you receive from the Beta server: so, in effect, running the Beta apps will be running Lunatics anyway.

At other, less hectic, times there can be long periods when no new applications are being deployed by the Beta project itself, and at those times I don't think anybody would see anything wrong in testing a new Lunatics app at Beta - in fact, most of them are tested that way. We just ask you to use some skill and judgement when choosing what apps to test, and when. For now, and for Astropulse, just the server apps, please.

In this particular case, the difference between v6 and v7 is primarily in the radar blanking code. That code was originally designed by Josh Von Korff (a PhD student working at the Berkeley labs) six years ago, before any of us were using GPUs to crunch anything. The design he chose proved impossible to migrate to GPUs, which is why we're still using the CPU so heavily. There simply aren't enough SETI@Home staff working in the lab to rewrite the code to be GPU-friendly: that's why the whole application was written by a student in the first place.

The new blanking code (which can run in both CPU and GPU applications) has been contributed by Raistmer for Lunatics, and will be in the applications you receive from the Beta server: so, in effect, running the Beta apps will be running Lunatics anyway.

Richard....
I thank you so very much for that insight. It was very enlightening.
Rather than curse the darkness, I was pissing on the candle...LOL.
I did not realize the curse went back so far.

As is my usual modus, I tend to react emotionally, and that is not always the correct response, my friend.

Thank you again.

Meow.

---

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

I always had a ton of faith in the Lunatics.........

+1 :) Love Lunatics and the Lunatics Staff !

---

I always had a ton of faith in the Lunatics.........

+1 :) Love Lunatics and the Lunatics Staff !

They are a most wonderful bunch of coconuts indeed.

---

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

lunitics certianly do a good job at get the programmes to work wish I was as clever as they are. v7 works great on my pc

Hm, I'm looking for some help for a troubled host now (this one)...

While running one or two MB tasks/GPU (Cuda 5.0 App selected from Lunatics 0.42), all on default vanilla mbcuda.cfg and only 1 CPU MB Task running parallel, I'm getting frequent random Driver resets (337.88) on the GTX 650Ti.
It's running on the last System I could assemble for the current race.

Notably, the card is running on an old AM2 Motherboard on a 16x PCIe 1.1 Slot.
OS is an otherwise naked Vista32 SP2 (originally SP1 install just updated to SP2, no other patches/updates installed for the sake of getting it running quick).

I've let the System stand completely ilde for an hour and nothing bad happened...
I tortured it with FurMark plus CPU load and nothing bad happened (GPU Temp peaked at 69deg C, so it seems cooling is okay)... That also makes me think the PSU is okay (FurMark is known to create absolute peak GPU power consumption).
PSU is not hughe but a reliable quality Seasonic 330W and the CPU is only a 65W TDP one, HDD is a small 2.5". System should be clearly under 200W peak and I've powered more hungry devices than this with those in the past.

For the sake of trying and ruling it out, I might toss in a brand new Thermaltake 530W tomorrow.

But when I let it run BOINC, I keep getting the NVidia system message that the Video card/Driver stopped responding and was reset.

In effect, that causes the running GPU Tasks to stop and sometimes be placed into the "waiting to run" state (surprisingly they don't error out as I feared). BOINC then simply moves onto the next fresh tasks. The "waiting to run" ones are resumed after others finish, so technically it's still running overall.

Peak temp I observed with GPU-Z during crunching is 59deg C, which should really okay.

For now I'm a bit out of ideas, so any input is appreciated.
If I'm unlucky, the old components I reused just aren't up for the job anymore and I might have to drop the GTX 650Ti again...

As it stands, the System limbs along with that quirk - BUT I'll have to see if those GPU tasks validate (I've now set the cache to 0.1 days, so I don't waste too many Workunits if things go bad)...

--- edit ---
The Error lines from the Stderr output :

Cuda error 'cudaMalloc((void**) &dev_cx_DataArray' in file 'c:/[Projects]/__Sources/sah_v7_opt/Xbranch/client/cuda/cudaAcceleration.cu' in line 328 : all CUDA-capable devices are busy or unavailable.
setiathome_CUDA: CUDA runtime ERROR in device memory allocation, attempt 7 of 6
cudaAcc_free() called...
Exiting...
Preemptively Acknowledging temporary exit -> Exit Status: 0
boinc_exit(): requesting safe worker shutdown ->
boinc_exit(): received safe worker shutdown acknowledge ->
Cuda threadsafe ExitProcess() initiated, rval 0

---

Probably will help to set TdrDelay:
http://setiathome.berkeley.edu/forum_thread.php?id=74843&postid=1553166#1553166

http://msdn.microsoft.com/en-us/library/windows/hardware/ff569918(v=vs.85).aspx

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Oki, found that one.

I'll play around with that one, see if it helps.

---

Hm, those keys mentioned seem Windows 8 specific.

No:
"In Windows Vista and later, the operating system attempts to detect situations in which computers appear to be completely "frozen""
http://msdn.microsoft.com/en-us/library/windows/hardware/ff570087(v=vs.85).aspx

"Both Windows Vista and Windows 7 try to detect these problematic hang situations and dynamically recover a responsive desktop."
http://msdn.microsoft.com/en-us/library/windows/hardware/jj676805(v=vs.85).aspx


Of course TdrDelay do not exist, you have to create it.
The simplest method is to create 2 .reg files (as per my first link) and run one or the other to set/remove it.

EDIT:
You edited the text in your post to completely different!

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Yes, after reading into it I found it and created the Key (sry for that, thought my edit came quick enough ;) ).

However, both extremes didn't work for me :

- removing it (as I read on the other thread) gave me a BSOD
(possibly would have been better to leave it and set it to 0, my mistake I guess)
I'll give a last shot setting the values to 0.

- setting the values to 60 still gives me those driver resets

I really think it's the old motherboard, that's my best explanation at this time.

-- edit --

Just tried it with both values at 0 and still gives the driver error message. I'll just leave it running like that and have an eye on the validating tasks.
Since I'm not sitting in front of it and it's just chugging along only connected via network & VNC, that is weird - but still acceptable for crunching purposes.
With a bit (or alot) of luck, the Workunits just continue in progress now with the 0sec timeout delay, that would be sweet.

Anyway, thanks for your help. It's 4AM in the morning here now and I need some sleep :)

---

To FalconFly:

This is a "shot in the dark" but I recently started having driver hang/recover events on my GTX550Ti which had been reliable for the past year. After several days, it stopped completely.

I removed the card and carefully cleaned all the contacts with a soft pencil eraser, reinserted it and booted. It has been running again nicely.

Your mileage may vary, but it is a cheap and sometimes useful technique.

Best wishes.

I'll give a last shot setting the values to 0

Don't set TdrDelay to 0
If you want to set it to something 'normal' set it to 2 (the default)

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

To FalconFly:

This is a "shot in the dark" but I recently started having driver hang/recover events on my GTX550Ti which had been reliable for the past year. After several days, it stopped completely.

I removed the card and carefully cleaned all the contacts with a soft pencil eraser, reinserted it and booted. It has been running again nicely.

Your mileage may vary, but it is a cheap and sometimes useful technique.

Best wishes.

The card is barely 4 days old, so it's definitely good on that. The board however is likely just too old (and possibly defective). It's the 2nd board of its type and has similar issues (although the 2nd did better, giving me hope initially).

I'll let the GPU run dry on a 2sec delay setting now.

The system is just unstable with it and it makes no sense, I just can't get it to work right.

---

The AP 7 apps are Lunatics technology.
Brilliant work by our group i might add.

So does that mean the credit granted for AP will drop like a stone as happened with MBv7 thanks to Credit New?

---

Grant
Darwin NT

The AP 7 apps are Lunatics technology.
Brilliant work by our group i might add.

So does that mean the credit granted for AP will drop like a stone as happened with MBv7 thanks to Credit New?

When AP 7 started over on beta there At first it didn't seem to make much difference. Now credits for AP v7 over on Beta seem to drop.
Please keep in mind that you will be able to process more AP v7 tasks in the same time as the blanking issue has been solved (some tasks with a high percentage of blanking took more than twice the time compared to non blanked tasks) ...

Here are my results for AP v6 and AP v7 (same computer), so you can check for yourself if you like.

AP v6 here on main:

http://setiathome.berkeley.edu/results.php?userid=34385&offset=0&show_names=0&state=4&appid=

AP v7 over on Beta:

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=58935&offset=0&show_names=0&state=4&appid=

Tom

---