**he probably had 6.03 in his cache when he started using the mod app, and the mod app is able to process the 6.03 tasks.**
____________



yes, I have in my cash wu. I just put the new app. why? this is a problem..? what I need first to finish all my cash with cpu, then make fresh start!??

"14/01/2009 17:49:33|SETI@home|Starting task 08no08ab.7216.4571.9.8.113_1 using setiathome_enhanced version 603"


Raistmer, why is he still getting version 603 Work units? Shouldn't that be at least 606?

Good question... either he has big cache or did smth wrong I suppose.

(ok, will read thread complete before answering - but I guess right after all ;) )

yes, I have in my cash wu. I just put the new app. why? this is a problem..? what I need first to finish all my cash with cpu, then make fresh start!??

Don't worry - all go just fine. No, you non need to clean up cache, I assembled app_info.xml specially to keep older tasks alive too. No prob.

yes, I have in my cash wu. I just put the new app. why? this is a problem..? what I need first to finish all my cash with cpu, then make fresh start!??

Don't worry - all go just fine. No, you non need to clean up cache, I assembled app_info.xml specially to keep older tasks alive too. No prob.

but, what is better? to finish processioning the remaining WU's with cpu, or to make 'compute error' with cuda!?? have someone finish processing with CUDA on 8600GT 256MB DDR3!?

yes, I have in my cash wu. I just put the new app. why? this is a problem..? what I need first to finish all my cash with cpu, then make fresh start!??

Don't worry - all go just fine. No, you non need to clean up cache, I assembled app_info.xml specially to keep older tasks alive too. No prob.

but, what is better? to finish processioning the remaining WU's with cpu, or to make 'compute error' with cuda!?? have someone finish processing with CUDA on 8600GT 256MB DDR3!?

It depends. Better is to fix CUDA app of course :)

But to be more realistic:
If you wnat to use most of you hardware - for very this moment - it's better to process SETI MB on CUDA capable GPU and do SETI AP or another project like Einstein@home with optimized app on CPU.
That way you will bring most performance to BOINC.

Haven't received any astropulse wus ,so attached to rosetta and am running 2 rosetta and 1 mb.The new app. works really well.No probs at all,running 18hrs.
Cuda about 3.5 x as fast as oced q6600 at 3474 on 59 credit tasks.

q6600=3783sec....cuda=1080sec.

I think the new app. will change a lot of minds. No babysitting at all. Thanks again Raistmer.

Haven't received any astropulse wus ,so attached to rosetta and am running 2 rosetta and 1 mb.The new app. works really well.No probs at all,running 18hrs.
Cuda about 3.5 x as fast as oced q6600 at 3474 on 59 credit tasks.

q6600=3783sec....cuda=1080sec.

I think the new app. will change a lot of minds. No babysitting at all. Thanks again Raistmer.

You are talking about 8800GTS, in your comparison!??

You are talking about 8800GTS, in your comparison!??

Yes 8800 gts 320.In a PD-920 @3.0

@ Zoran Kirsic

I guess yes, because only this in his overview:
[CUDA|GeForce 8800 GTS|1|319MB] with his Intel(R) Pentium(R) D CPU 2.80GHz


A GTX 260/280 would have maybe a RAC of ~ 8,000 - ~ 10,000


@ Raistmer

Sorry for my ignorance.


You are the master of optimizations.. ;-)

So..
Normally with the stock BOINC and SETI@home-settings I could let run only MB on GPU or MB and AP on CPU.

With your mod, I could let run MB on GPU and AP on CPU.

Why not MB on GPU and CPU, maybe also with AP on CPU?
It's not possible to modify the app_info.xml for this?
If not, why?
BOINC is to 'stupid'? ;-)


MB and AP on CPU and MB on GPU.. this would be perfectly! :-)

---

Why not MB on GPU and CPU, maybe also with AP on CPU?
It's not possible to modify the app_info.xml for this?
If not, why?
BOINC is to 'stupid'? ;-)


MB and AP on CPU and MB on GPU.. this would be perfectly! :-)

Yes, impossible (at least I don't know how and no one jumped with idea how to do this still).
Not, BOINC is not "so stupid" it's just in progress area (cause it's not a bug in any point of view, it's just a way how it designed for now).

As I already noted (maybe even in this thread) most probable way will be to join CUDA MB and AK8 codebases and to create one single app capable to do both CPU and CUDA. Maybe even multithreading CPU (multihost and so on - no limits for perfection). But all this requires time and efforts. Todays programming crew very limited in number of participants both in Berkeley and Lunatics. That's why I again and again invite peoples to join development. It seems "people factor" now more critical that raw processing power factor for SETI project. So, if you can help in coding - just do it, if not - try to participate in another way, but repetitive inquiries for new more faster more, perfect and so on and so forth apps just distracting.
For now short answer is: work in progress

<core_client_version>6.4.5</core_client_version>
<![CDATA[
<message>
- exit code -1073741819 (0xc0000005)
</message>
<stderr_txt>
setiathome_CUDA: Found 1 CUDA device(s):
Device 1 : GeForce 8600 GT
totalGlobalMem = 268107776
sharedMemPerBlock = 16384
regsPerBlock = 8192
warpSize = 32
memPitch = 262144
maxThreadsPerBlock = 512
clockRate = 1188000
totalConstMem = 65536
major = 1
minor = 1
textureAlignment = 256
deviceOverlap = 1
multiProcessorCount = 4
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce 8600 GT is okay
SETI@home using CUDA accelerated device GeForce 8600 GT
Rise priority modification by Raistmer based on rev400 of SETI@home sources
VLAR autokill mod from Crunch3rPriority of worker thread rised successfully
Priority of process adjusted successfully
Total GPU memory 268107776 free GPU memory 224959232
setiathome_enhanced 6.02 Visual Studio/Microsoft C++
libboinc: 6.3.22

Work Unit Info:
...............
WU true angle range is : 0.433357
Optimal function choices:
-----------------------------------------------------
name
-----------------------------------------------------
v_BaseLineSmooth (no other)
v_GetPowerSpectrum 0.00048 0.00000
v_ChirpData 0.01798 0.00000
v_Transpose4 0.01172 0.00000
FPU opt folding 0.00488 0.00000
Cuda error 'cudaAcc_GetPowerSpectrum_kernel' in file 'd:/BTR/seticuda/seti_boinc/clien
</stderr_txt>
]]>


this is from http://setiathome.berkeley.edu/result.php?resultid=1122573992

this is not a VLAR, but still computation error.
link to my results
http://setiathome.berkeley.edu/results.php?userid=467823

I suspect that the code in the Cuda App specifically dealing with
Vlar wu's is buggy. The general consensus is that errors in Vlar
wu's are due to underpowered GPU's, thus the artificial cutoff for
getting Cuda work was set at 60 Gflops, and if your card doesn't
meet that standard at Beta you're not welcome to participate.
...

The Berkeley consensus may be that it's a driver problem or an underpowered GPU problem, but the general consensus is that it's a bug.

For further confirmation, and commiserations, see message 36468 at Beta.

I suspect that the code in the Cuda App specifically dealing with
Vlar wu's is buggy. The general consensus is that errors in Vlar
wu's are due to underpowered GPU's, thus the artificial cutoff for
getting Cuda work was set at 60 Gflops, and if your card doesn't
meet that standard at Beta you're not welcome to participate.
...

The Berkeley consensus may be that it's a driver problem or an underpowered GPU problem, but the general consensus is that it's a bug.

For further confirmation, and commiserations, see message 36468 at Beta.

Hi.

I think I remember reading that you had 2 nvidia cards. I could be wrong.
Just wondering if you're running your 9800 as secondary display.
If you were, the results from that configuration would be quite useful in
tracking down vlar wu errors, since a a secondary display card configuration
for the Cuda Gpu has fewer limitations on "GPU task instance duration errors" and
would narrow the the search down to the real cause of vlar errors more quickly.
I do believe the problem is in errant algorithmic conversion to cuda code.

Cuda rocks.
Maybe Boinc can even surpass Folding@Home's 4.5 TFlops with a little help from
our nvidia, and ati friends.

No, that can't have been me. This is a fairly modest Foxconn G33M motherboard, with only one PCI-e slot. I originally had a cheap 7200GS in it, but swapped that out for the 9800GT and CUDA.

I have put in plenty of secondary PCI graphics cards alongside AGP down the years, and what you say is intriguing - might see if I can dig an old one out and try my luck.

CUDA doesn't quite rock, yet, but it's looking promising.

Getting a buch of overflows

AR2.7
1121875641
1121875606
1121875604

Have several more I managed to keep off the server, but 3 others that uploaded as well. Unfortunately I was trying to update Beta and Einstein when these hit, so I could only stop the others from reporting. Have some VLAR compute errors in there too. Most of those are on my pc and the rest are on the server now. Doing a reboot now to see if I can stop the overflows.

This probably has more to do with some VLAR tasks I had at Beta and unfortunately SETI got the brunt of it.

Edit: Just rebooted and now the tasks are runnig again. Sorry for the screw up, should have known better.
Edit 2: may have spoke to fast, had another overflow after the reboot. The task after that now at 19.526% or so.

---

Getting a buch of overflows

AR2.7
1121875641
1121875606
1121875604

Have several more I managed to keep off the server, but 3 others that uploaded as well. Unfortunately I was trying to update Beta and Einstein when these hit, so I could only stop the others from reporting. Have some VLAR compute errors in there too. Most of those are on my pc and the rest are on the server now. Doing a reboot now to see if I can stop the overflows.

This probably has more to do with some VLAR tasks I had at Beta and unfortunately SETI got the brunt of it.

Edit: Just rebooted and now the tasks are runnig again. Sorry for the screw up, should have known better.
Edit 2: may have spoke to fast, had another overflow after the reboot. The task after that now at 19.526% or so.

what driver do you have!? the new one?

Getting a buch of overflows

AR2.7
1121875641
1121875606
1121875604

Have several more I managed to keep off the server, but 3 others that uploaded as well. Unfortunately I was trying to update Beta and Einstein when these hit, so I could only stop the others from reporting. Have some VLAR compute errors in there too. Most of those are on my pc and the rest are on the server now. Doing a reboot now to see if I can stop the overflows.

This probably has more to do with some VLAR tasks I had at Beta and unfortunately SETI got the brunt of it.

Edit: Just rebooted and now the tasks are runnig again. Sorry for the screw up, should have known better.
Edit 2: may have spoke to fast, had another overflow after the reboot. The task after that now at 19.526% or so.

what driver do you have!? the new one?

At the moment yes, but I'll soon be going back to 180.60 since that's the one I've always done best with.

---

Why not MB on GPU and CPU, maybe also with AP on CPU?
It's not possible to modify the app_info.xml for this?
If not, why?
BOINC is to 'stupid'? ;-)


MB and AP on CPU and MB on GPU.. this would be perfectly! :-)

Yes, impossible (at least I don't know how and no one jumped with idea how to do this still).
Not, BOINC is not "so stupid" it's just in progress area (cause it's not a bug in any point of view, it's just a way how it designed for now).

As I already noted (maybe even in this thread) most probable way will be to join CUDA MB and AK8 codebases and to create one single app capable to do both CPU and CUDA. Maybe even multithreading CPU (multihost and so on - no limits for perfection). But all this requires time and efforts. Todays programming crew very limited in number of participants both in Berkeley and Lunatics. That's why I again and again invite peoples to join development. It seems "people factor" now more critical that raw processing power factor for SETI project. So, if you can help in coding - just do it, if not - try to participate in another way, but repetitive inquiries for new more faster more, perfect and so on and so forth apps just distracting.
For now short answer is: work in progress

I can't 'coding'.. if I could, of course I would help! :-)

I opened one thread at my team- and the opt.-crew -homepage.. for to 'recruit' new people.. and for discuss about to optimize BOINC/SETI@home..

The only thing I could do is to buy a CUDA-GPU and make tests.. and tell if it's running well or not.. ;-)

---

The general consensus is that errors in Vlar
wu's are due to underpowered GPU's, thus the artificial cutoff for

It's just wrong. Sorry can't give full answer need to go now, will explain when return home.

I suspect that the code in the Cuda App specifically dealing with
Vlar wu's is buggy. The general consensus is that errors in Vlar
wu's are due to underpowered GPU's, thus the artificial cutoff for
getting Cuda work was set at 60 Gflops, and if your card doesn't
meet that standard at Beta you're not welcome to participate.

In Windows XP the gpu watchdog timer is set at 5 secs i believe.
A GPU task should take no more than 5 secs, in Vista the timer is
set for 2 secs, so i've read.
[/qoute]
Well, now more details:
1) VLAR bug affects top GPUs too, jus in less degree. So almos no matter how powerful GPU is.
2) Sure it's artifical restriction. Currently restricted GPUs are very suitable for computations - i's jus VLAR bug ha should be corrected. (And AFAIK will be corrected very soon)

The autokill mod will allow wu's to be processed, but will mask the
underlying root of the problem.

No, it doesn' mask he problem - it smooths consequencies ;)
It's just anothe workaround - much more effective than just how away whole range of powerful enough GPUs (and more stable in results - because even fastes GPU can still fall on VLAR)

Getting a buch of overflows

AR2.7
1121875641
1121875606
1121875604

Have several more I managed to keep off the server, but 3 others that uploaded as well. Unfortunately I was trying to update Beta and Einstein when these hit, so I could only stop the others from reporting. Have some VLAR compute errors in there too. Most of those are on my pc and the rest are on the server now. Doing a reboot now to see if I can stop the overflows.

This probably has more to do with some VLAR tasks I had at Beta and unfortunately SETI got the brunt of it.

Edit: Just rebooted and now the tasks are runnig again. Sorry for the screw up, should have known better.
Edit 2: may have spoke to fast, had another overflow after the reboot. The task after that now at 19.526% or so.

Please, follow these rules when report new bugs:

1)Post only "invalid" overflows - that is - CPU wingmate has no overflow, but CUDA has overflow.
2) Don' post any problems that appeared after driver crash/restart.
We already know that this is "bug-full" situation.

These simple rules will save our time and speedup bug analysis.