Screw it.............
I posted a link to my tasks.
I dunno if you can see it.

And castigating me for the wrong links in a troubleshooting problem...

I won't ask again and my initial comment stands.

See ya on a better day.

---

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

Want to review?
My AP results.

You should know by now that UserID links are for the owner only - the rest of us have to follow HostID links.

And I'd prefer specific examples, please, rather than generalities: I have to pass this on to the developers, and I know that they will ignore vague grumblings. I would in their place.

Richard................

---

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

Agreed. Maybe we will talk on Monday, when you can hold a lucid conversation.

Yep, personal ID links do not work for anyone else, but after looking at each of your rigs valid AP results I can't see why you would make that statement though a few tasks with low blanking do have high CPU usage, but that may be just an over commitment of hardware resources (which maybe why those that have errored out have extremely high CPU usage) though both don't happen very often.

But now I have to ask about all the aborted MB work that every one of your rigs has. Were they caused by the installer or....?

Cheers.

Yep, personal ID links do not work for anyone else, but after looking at each of your rigs valid AP results I can't see why you would make that statement though a few tasks with low blanking do have high CPU usage, but that may be just an over commitment of hardware resources (which maybe why those that have errored out have extremely high CPU usage) though both don't happen very often.

But now I have to ask about all the aborted MB work that every one of your rigs has. Were they caused by the installer or....?

Cheers.

I detached a couple of days ago.........OK?

---

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

My thread. Let's leave it there, everyone, please.

Friends we don´t need to be hostile here.

I belive what Mark´s is talk about was something related with my post on our team forum.

Few of us are trying to understand why our daily production sudenly drops (in my case from 500k/day to about 300k or worst today) if all our crunchers are working fine 24/7 and our caches are fully loaded with AP WU. Something must cause that and is making the new apps runs apparently very slow in our hosts.

In the process of testing we abort (if you see i allready have >1000 AP WU aborted about 1/4 of my entire farm cache) some part of the caches in some of the hosts to see if the new work present the same problem, and aparently all is related to the % blank on the WU.

I copy it here as posted since i know most of you can´t see it and maybe give us some tip or path to flow:

Please forgive if i´m wrong and i´m chassing ghosts but...

I´m starting to belive the new AP builds have something wierd in some type of WU, something who only apears or is worst on the slower and less powerfull CPU hosts who drive fast GPU´s like the ones Mark & i have.

Something related to the mid range blanked WU, not sure about but seems like the CPU usage on those WU is too high and that slow down the entire cruncher.

Since i don´t do CPU work and my CPU cores are totaly free to feed the GPUs that´s sounds wierd, yes i agree, but what else could explain a host who crunch normaly a WU in about 3k sec crunch another WU in 8k sec?

Considering the host is leaving alone doing nothing else? All scheduled task like backup, updates, are stoped and obviusly the boinc dir is out of the antivirus range.

Look this 2 WU for example

http://setiathome.berkeley.edu/result.php?resultid=3694905930

http://setiathome.berkeley.edu/result.php?resultid=3694915755

the first one crunch in 2 hours 20 min 41 sec with 1 hours 5 min 19 sec of CPU time and has percent blanked: 81.68

the second one it´s a zero blanked WU with the normal cruching time of 1 hours 0 min 52 sec and CPU time of 3 min 56 sec.

That´s makes me remember the old Vlar problem with NV GPU´s, not sounds familiar? Could something similar happening here?

For help the understanding, i run 3WU at a time on the 780´s hosts and don´t do CPU work on any of them.

Thanks in advance and please any help is welcomed.

---

Friends we don´t need to be hostile here.

I belive what Mark´s is talk about was something related with my post on our team forum.

Few of us are trying to understand why our daily production sudenly drops (in my case from 500k/day to about 300k or worst today) if all our crunchers are working fine 24/7 and our caches are fully loaded with AP WU. Something must cause that and is making the new apps runs apparently very slow in our hosts.

In the process of testing we abort (if you see i allready have >1000 AP WU aborted about 1/4 of my entire farm cache) some part of the caches in some of the hosts to see if the new work present the same problem, and aparently all is related to the % blank on the WU.

I copy it here as posted since i know most of you can´t see it and maybe give us some tip or path to flow:

Please forgive if i´m wrong and i´m chassing ghosts but...

I´m starting to belive the new AP builds have something wierd in some type of WU, something who only apears or is worst on the slower and less powerfull CPU hosts who drive fast GPU´s like the ones Mark & i have.

Something related to the mid range blanked WU, not sure about but seems like the CPU usage on those WU is too high and that slow down the entire cruncher.

Since i don´t do CPU work and my CPU cores are totaly free to feed the GPUs that´s sounds wierd, yes i agree, but what else could explain a host who crunch normaly a WU in about 3k sec crunch another WU in 8k sec?

Considering the host is leaving alone doing nothing else? All scheduled task like backup, updates, are stoped and obviusly the boinc dir is out of the antivirus range.

Look this 2 WU for example

http://setiathome.berkeley.edu/result.php?resultid=3694905930

http://setiathome.berkeley.edu/result.php?resultid=3694915755

the first one crunch in 2 hours 20 min 41 sec with 1 hours 5 min 19 sec of CPU time and has percent blanked: 81.68

the second one it´s a zero blanked WU with the normal cruching time of 1 hours 0 min 52 sec and CPU time of 3 min 56 sec.

That´s makes me remember the old Vlar problem with NV GPU´s, not sounds familiar? Could something similar happening here?

For help the understanding, i run 3WU at a time on the 780´s hosts and don´t do CPU work on any of them.

Thanks in advance and please any help is welcomed.

Is there an example of highly blanked task from older app?

To me it would seem logical that sleep command line would cause increased run time for highly blanked tasks. As they are done mostly on CPU & CPU is told to sleep. If you receive mostly blanked tasks, we seem to have many in this last batch of tapes, then output would drop off.

Unlike the MB VLAR issue on Nvidia GPU this does not cause the task to error. Also I think the blanking is only known as the task is processed. So there would not be a way to detect blanking and split highly blanked work form non or low blanked work.

---

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

Friends we don´t need to be hostile here.

I belive what Mark´s is talk about was something related with my post on our team forum.

Few of us are trying to understand why our daily production sudenly drops (in my case from 500k/day to about 300k or worst today) if all our crunchers are working fine 24/7 and our caches are fully loaded with AP WU. Something must cause that and is making the new apps runs apparently very slow in our hosts.

In the process of testing we abort (if you see i allready have >1000 AP WU aborted about 1/4 of my entire farm cache) some part of the caches in some of the hosts to see if the new work present the same problem, and aparently all is related to the % blank on the WU.

I copy it here as posted since i know most of you can´t see it and maybe give us some tip or path to flow:

Please forgive if i´m wrong and i´m chassing ghosts but...

I´m starting to belive the new AP builds have something wierd in some type of WU, something who only apears or is worst on the slower and less powerfull CPU hosts who drive fast GPU´s like the ones Mark & i have.

Something related to the mid range blanked WU, not sure about but seems like the CPU usage on those WU is too high and that slow down the entire cruncher.

Since i don´t do CPU work and my CPU cores are totaly free to feed the GPUs that´s sounds wierd, yes i agree, but what else could explain a host who crunch normaly a WU in about 3k sec crunch another WU in 8k sec?

Considering the host is leaving alone doing nothing else? All scheduled task like backup, updates, are stoped and obviusly the boinc dir is out of the antivirus range.

Look this 2 WU for example

http://setiathome.berkeley.edu/result.php?resultid=3694905930

http://setiathome.berkeley.edu/result.php?resultid=3694915755

the first one crunch in 2 hours 20 min 41 sec with 1 hours 5 min 19 sec of CPU time and has percent blanked: 81.68

the second one it´s a zero blanked WU with the normal cruching time of 1 hours 0 min 52 sec and CPU time of 3 min 56 sec.

That´s makes me remember the old Vlar problem with NV GPU´s, not sounds familiar? Could something similar happening here?

For help the understanding, i run 3WU at a time on the 780´s hosts and ndo noCPU work on any of them.

Thanks in advance and please any help is welcomed.

I wasn't being "hostile", just asking a question, but as to why RAC's are dropping, have you looked at the number of your pendings?

I know that I have 1 rig that is dropping a lot in RAC due to the fact of people attaching to this project, grabbing a lot of tasks, and then letting most of them (if not all) time out.

Cheers.

AP`s with high blanking always slows down processing and drop the RAC thats normal and has nothing to do with recent apps.
This is fixed in AP 7.

If you`re running 3 instances on each card and have 2 cards installed thats 6 instances which requires CPU resources but you only have 4 cores.
Understand ?

---

With each crime and every kindness we birth our future.

AP`s with high blanking always slows down processing and drop the RAC thats normal and has nothing to do with recent apps.
This is fixed in AP 7.

If you`re running 3 instances on each card and have 2 cards installed thats 6 instances which requires CPU resources but you only have 4 cores.
Understand ?

Yes, an over commitment of hardware resources would certainly be a problem there especially as only 2 of those cores are physical.

Cheers.

Thanks for the fast answers.

I understand blank changes the performance but this time the change was, lets call "a lot stronger than usual", i could only spoke for me of course but i never see my farm pruducing 8k/hr as was few hours ago even when i crunch MB only.

I allways compare it´s production with few fellow cruchers who has aproximately the same output, something liki out "private race" and normaly the diference is very little but now the drop was huge.

I know about the pedings problem, and normaly my pendings are very high, but could look incledible but 1400 pendigs like i have now is relatilevy a "small number" they are normaly in the range of 1800-2200 WU.

<edit> after i post i see the last msgs. I know about the cores but why that aparently changes 2 days ago only? You know Mike i´m running r2399 for about a month and never see that happening before. A simple coincidence? By task manager, the CPU usage never pass 20% even when i run 6 WU. And BTW the same probem is happning on a single 780 host who only run 3 WU, so it have 4 cores to feed the GPU.

---

Thanks. It does help if you bring questions and problems here to the public forums, where everyone can mull over the examples you've provided.

First, can I take it as given that you have observed this as a specific change in behaviour with r2399 (from the v0.42 installer), compared with r1843 from the v0.41 installer?

If so, you might like to consider the v0.42a installer from http://1drv.ms/1vrU6pP - that's described in my post around this time yesterday, in this thread, and reverts that particular change. If that produces better timings for this batch of high-blanked tasks, then we will have some specific data to work with.

Secondly (as I see others have been speculating while I've been typing), the problem may be related to the number (up to 12) of high-blanked tasks running at the same time. It's very hard for us to simulate that in testing, so it might be helpful if some of you with highly-specialised rigs could come across and help us with the alpha testing before release.

And finally, much of the recent development effort has centered on Astropulse v7, which is being developed jointly by Lunatics and the SETI project staff specifically to avoid the inefficient handling of radar blanking which takes so much CPU time. For that reason, it's unlikely that a new AP v6 application will be developed specifically for the mega-hardware niche, but if we can help you (and you can help us) to choose the most appropriate earlier version to distribute via the installer, that would benefit all.

Thanks. It does help if you bring questions and problems here to the public forums, where everyone can mull over the examples you've provided.

I know that, but i don´t like to keep posting too much on the public forums since as you kindly explain we use a highly specialyzed configuraitons who could cause a lot of confusion to the major part of the normal volunteers, and could easly leave to wrong assumptions. That why i normaly rise those question on the team forum only.

First, can I take it as given that you have observed this as a specific change in behaviour with r2399 (from the v0.42 installer), compared with r1843 from the v0.41 installer?

No i was ussing the r2399 for a long time before just never see someting like this happening before.

If so, you might like to consider the v0.42a installer from http://1drv.ms/1vrU6pP - that's described in my post around this time yesterday, in this thread, and reverts that particular change. If that produces better timings for this batch of high-blanked tasks, then we will have some specific data to work with.

I jut install the new build in one host, from what that posted and since i dont do CPU Work the new builds just install the sae r2399 i allready use. Did you realey sugest i use the install? Remember i need to do that on a large number of hosts not just one.

Secondly (as I see others have been speculating while I've been typing), the problem may be related to the number (up to 12) of high-blanked tasks running at the same time. It's very hard for us to simulate that in testing, so it might be helpful if some of you with highly-specialised rigs could come across and help us with the alpha testing before release.

I agree and thing the problem is relater to the number of high.blanked WU but what bugs my mind is why that not happening before, i run the same version of AP crunching for a while. And there where some other blanking storms in the middle.

And finally, much of the recent development effort has centered on Astropulse v7, which is being developed jointly by Lunatics and the SETI project staff specifically to avoid the inefficient handling of radar blanking which takes so much CPU time. For that reason, it's unlikely that a new AP v6 application will be developed specifically for the mega-hardware niche, but if we can help you (and you can help us) to choose the most appropriate earlier version to distribute via the installer, that would benefit all.

You know, i´m ready to do my part, but i´m a simple (ok agree a mad) user so somebody must tellme what i need to do. My rings are yours anytime they could help the test and to help the comunity.[/quote]

---

And I did not attack anybody........
I just simply noted that, on my part, the app sucked.

Meow.

---

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

If so, you might like to consider the v0.42a installer from http://1drv.ms/1vrU6pP - that's described in my post around this time yesterday, in this thread, and reverts that particular change. If that produces better timings for this batch of high-blanked tasks, then we will have some specific data to work with.

I jut install the new build in one host, from what that posted and since i dont do CPU Work the new builds just install the sae r2399 i allready use. Did you realey sugest i use the install? Remember i need to do that on a large number of hosts not just one.

v0.42a contains older AP GPU apps from v0.41.
I think he wants to see example times from r1843 & r2399 on same host with highly blanked work. That would be useful data point.
Do you have a host with older app still. Then you could install r2399 for comparison.

---

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

If so, you might like to consider the v0.42a installer from http://1drv.ms/1vrU6pP - that's described in my post around this time yesterday, in this thread, and reverts that particular change. If that produces better timings for this batch of high-blanked tasks, then we will have some specific data to work with.

I jut install the new build in one host, from what that posted and since i dont do CPU Work the new builds just install the sae r2399 i allready use. Did you realey sugest i use the install? Remember i need to do that on a large number of hosts not just one.

v0.42a contains older AP GPU apps from v0.41.
I think he wants to see example times from r1843 & r2399 on same host with highly blanked work. That would be useful data point.
Do you have a host with older app still. Then you could install r2399 for comparison.

Sorry i don´t have anymore, when i make a version change i made on all the hosts to be sure i don´t forget someone, something easy to do when you have many host to update.

---

If so, you might like to consider the v0.42a installer from http://1drv.ms/1vrU6pP - that's described in my post around this time yesterday, in this thread, and reverts that particular change. If that produces better timings for this batch of high-blanked tasks, then we will have some specific data to work with.

I jut install the new build in one host, from what that posted and since i dont do CPU Work the new builds just install the sae r2399 i allready use. Did you realey sugest i use the install? Remember i need to do that on a large number of hosts not just one.

v0.42a contains older AP GPU apps from v0.41.
I think he wants to see example times from r1843 & r2399 on same host with highly blanked work. That would be useful data point.
Do you have a host with older app still. Then you could install r2399 for comparison.

Sorry i don´t have anymore, when i make a version change i made on all host to be sure i dont miss something.

For the purposes of testing out an issue like this, it's actually probably best to just change one host at a time to a comparison version, and leave the others as controls working on the same batch of tasks. I only mentioned the installer as a possible delivery method because, well, we are discussing it in an installer release thread, and the Installer is conveying the 'new app' that was presented as having problems.

As the conversation proceeds, we seem to be swinging more towards the idea that it's 'new data' which is the problem, rather than the app. As Juan says, r2399 has been available for download as a separate application for some time, and I don't think we've heard of problems like this until now.

There should be absolutely no difference in how r2399 runs, whether it's delivered by the installer or downloaded and installed manually. The only difference might be in the recommended configuration settings - @ Mike, can you remember if you changed any advice when you reviewed the NVidia ReadMe file in preparation for the installer release?

If anyone is having problems with a particular application build, we can supply the other test builds in individual download bundles as well as via the installer - but it might be better to have that conversation in front of a technical audience over at Lunatics, rather than cluttering this board.

Is it ok to install the latest nvidia drivers yet? I haven't seen anyone discussing issues about them in this thread

---

Is it ok to install the latest nvidia drivers yet? I haven't seen anyone discussing issues about them in this thread

The better discussion on that particular issue is over in A word of warning about Nvidia driver 340.52. From a quick skim of the recent posts, the answer seems to be "nobody quite knows yet". It works fine for some people, and others suffer slow-downs (such as we've just been discussing here). And again, slow-downs are related to Astropulse tasks with high blanking levels.

Personally, I have no reasons which prompt me to upgrade my video driver just yet - so I haven't, the older ones are working fine for me. But I suppose I'd better do at least some testing in the run-up to AP v7 release - watch that other thread.