Ah, I see now what I need to do. now for 4 tasks running at once. In other projects, only changing the <count>1</count> part is needed, not anything else. So I am not sure why this app would be different really.

Ah, I see now what I need to do. now for 4 tasks running at once. In other projects, only changing the <count>1</count> part is needed, not anything else. So I am not sure why this app would be different really.

It's different because it works with OpenCL runtime even on BOINC that doesn't know about OpenCL and also it works on project that doesn't recognize ATi GPUs at all still.. In short, because it advanced one :P

looking at http://lunatics.kwsn.net/downloads/Lunatics_ReadMe.txt again, it shows nothing on command line options other than to help increase or reduce UI lag. Only mention of running multiple WUs per card was in the NVidia section, and that is what I did, change the <count>1</count> variable.

I referring to release notes for OpenCL app itself. Hope next installer release will include description of all available app switches...

Then how about next time raising the issue when the relevant documentation is up for comments at Lunatics ???

List the available switches, describe what they do and I'll get the readme updated.

NB The relevant info is (quoting from first post here)

If you are already running ATI applications: Make a note of what numbers you are using to be able to restore to those values PRIOR to running the installer. This also applies to setting the <count> variable according to your -instances_per_device variable for multithreading.

I admit, that is pretty obscure if somebody starts fresh. sorry.

I've UPgraded to cat.12.1., probably a stupid move, cause my HD5870 GPUs, aren't
detected anymore.

Anybody with similar experience?
And would it be best to downgrade to cat. 11.6 and AMD-APP-SDK 2.6?
This host
, has trouble finding the GPUs.

Would adding a cc_config.xml file, stating to use all GPUs, provide a solution?

---

Would adding a cc_config.xml file, stating to use all GPUs, provide a solution?

No, the GPUs have to be detected by BOINC first
(<use_all_gpus>1</use_all_gpus> means just 'Use all GPUs which you already know about')


Try Catalyst 11.12

To clean the traces of 'old' (currently used) drivers:
Phyxion.net - Driver Sweeper
http://phyxion.net/item/driver-sweeper.html

---

 


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

Would adding a cc_config.xml file, stating to use all GPUs, provide a solution?

No, the GPUs have to be detected by BOINC first
(<use_all_gpus>1</use_all_gpus> means just 'Use all GPUs which you already know about')


Try Catalyst 11.12

To clean the traces of 'old' (currently used) drivers:
Phyxion.net - Driver Sweeper
http://phyxion.net/item/driver-sweeper.html

@ BilBg, thanx for your swift reply, removing remnants of Catalyst drivers,
is necessary as they can indeed cause a lot of trouble.
I've tried catalyst 11.12; 11.6; 11.5, with no joy, trying Catalyst 11.4, removed all the newer versions and now, with Cat. 11.4, I've got OpenCL support, again!

Unfortunatly, I lost a lot of work and have to apollogize to my wing(wo)men, for any delay, caused by this incident.
Both 5870 GPUs are now seen by GPU-CapsViewer, so I'll try BOINC (6.12.34;64 bit), again. (Catalyst 11.12, did not give me OpenCL support)

If other programs, f.i. games or video-editting/rendering, cause problems, I'll
try cat 11.12.

---

ments at Lunatics ???

List the available switches, describe what they do and I'll get the readme updated.

Will be enough to include original release notes for each app.
I spent enough time to write them once and don't see any need to re-write them. Just add new switches to the end of list, probably :)

Catalyst 11.12, did not give me OpenCL support

Are you sure you get the full package (Catalyst Software Suite)?:
http://support.amd.com/us/gpudownload/windows/previous/11/Pages/radeon.aspx?os=Windows%20Vista%20-%2064-Bit%20Edition&rev=11.12

---

 


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

You can also try Cat 12.1.
Its released today.

---

With each crime and every kindness we birth our future.

Just a report of validation inconclusives.

I have been running .41g without problems but found many inconclusive results on recent big WUs.
At this point, 6 are passed validation, but one is marked invalid and 4 ( listed below) are in pending as inconclusive.

http://setiathome.berkeley.edu/workunit.php?wuid=917829102
http://setiathome.berkeley.edu/workunit.php?wuid=917829092
http://setiathome.berkeley.edu/workunit.php?wuid=917829083
http://setiathome.berkeley.edu/workunit.php?wuid=917829077
# these are not sent third wingan yet.

I just wonder why got incomclusive on these big WU, as other normal size WU are ok.

Just a report of validation inconclusives.

I have been running .41g without problems but found many inconclusive results on recent big WUs.
At this point, 6 are passed validation, but one is marked invalid and 4 ( listed below) are in pending as inconclusive.

http://setiathome.berkeley.edu/workunit.php?wuid=917829102
http://setiathome.berkeley.edu/workunit.php?wuid=917829092
http://setiathome.berkeley.edu/workunit.php?wuid=917829083
http://setiathome.berkeley.edu/workunit.php?wuid=917829077
# these are not sent third wingan yet.

I just wonder why got incomclusive on these big WU, as other normal size WU are ok.

By 'big WU', do you mean the 2.8MB datafiles I first reported last night?

Since all four of the workunits you've linked are from the 21jn11ac.5207.... sequence, I guess so.

The answer is - nobody knows. We weren't expecting those big WUs, we've never seen them before, and - until last night - nobody would have had one to test.

Having looked at one in detail, and compared it with a normal-size one (see the Panic thread) - I'm none the wiser. I didn't see anything that would have prompted the size to grow like that. My comparison WU was recorded at exactly the same time, from the same part of the sky and with the same telescope. So we can rule out anything like the Green Bank observatory data.

For the time being, I'm inclined to put it down to a glitch or mistake - until/unless we get a definitive answer from the project staff.

Just a report of validation inconclusives.

I have been running .41g without problems but found many inconclusive results on recent big WUs.
At this point, 6 are passed validation, but one is marked invalid and 4 ( listed below) are in pending as inconclusive.

http://setiathome.berkeley.edu/workunit.php?wuid=917829102
http://setiathome.berkeley.edu/workunit.php?wuid=917829092
http://setiathome.berkeley.edu/workunit.php?wuid=917829083
http://setiathome.berkeley.edu/workunit.php?wuid=917829077
# these are not sent third wingan yet.

I just wonder why got incomclusive on these big WU, as other normal size WU are ok.

By 'big WU', do you mean the 2.8MB datafiles I first reported last night?

Since all four of the workunits you've linked are from the 21jn11ac.5207.... sequence, I guess so.

Yes. I means those you called as 'mega WU' in Panic mode On thread.

The answer is - nobody knows. We weren't expecting those big WUs, we've never seen them before, and - until last night - nobody would have had one to test.

Having looked at one in detail, and compared it with a normal-size one (see the Panic thread) - I'm none the wiser. I didn't see anything that would have prompted the size to grow like that. My comparison WU was recorded at exactly the same time, from the same part of the sky and with the same telescope. So we can rule out anything like the Green Bank observatory data.

As I checked WU in the queue after the last post, I found these mega WUs have difference on the filter value in splitter_cfg section.
The value is 'polyphase' on all big WU while it is 'fft' in all other WU.
It might be a clue for WU size difference, but I don't know how it affect crunching.

For the time being, I'm inclined to put it down to a glitch or mistake - until/unless we get a definitive answer from the project staff.

I see. I'll wait for some news coming in.

# I saved copy of remaining 48 big WUs ( but 4 above are not included ).
# Let me know if you like to check them.

As I checked WU in the queue after the last post, I found these mega WUs have difference on the filter value in splitter_cfg section.
The value is 'polyphase' on all big WU while it is 'fft' in all other WU.
It might be a clue for WU size difference, but I don't know how it affect crunching.

Hmmm. How similar were the other WUs you checked?

As I said in the Panic thread, I found I had a closely-matched WU from the same 'tape', but normal size. That had exactly the same splitter_cfg as the mega WUs, including 'polyphase':

  <splitter_cfg>
    <version>0.200000003</version>
    <data_type>encoded</data_type>
    <fft_len>256</fft_len>
    <ifft_len>1</ifft_len>
    <filter>polyphase</filter>
    <window>welsh</window>
    <samples_per_wu>1048576</samples_per_wu>
    <highpass>0</highpass>
    <blanker_filter>randomize</blanker_filter>
  </splitter_cfg>

I'm rather hoping that Joe Segur will drop by sometime over the weekend - he knows this stuff better than any of us.

As I checked WU in the queue after the last post, I found these mega WUs have difference on the filter value in splitter_cfg section.
The value is 'polyphase' on all big WU while it is 'fft' in all other WU.
It might be a clue for WU size difference, but I don't know how it affect crunching.

Hmmm. How similar were the other WUs you checked?

As I said in the Panic thread, I found I had a closely-matched WU from the same 'tape', but normal size. That had exactly the same splitter_cfg as the mega WUs, including 'polyphase':

  <splitter_cfg>
    <version>0.200000003</version>
    <data_type>encoded</data_type>
    <fft_len>256</fft_len>
    <ifft_len>1</ifft_len>
    <filter>polyphase</filter>
    <window>welsh</window>
    <samples_per_wu>1048576</samples_per_wu>
    <highpass>0</highpass>
    <blanker_filter>randomize</blanker_filter>
  </splitter_cfg>

I'm rather hoping that Joe Segur will drop by sometime over the weekend - he knows this stuff better than any of us.

I had a look at a couple of my Regular Wu's, their splitter_cfg's were as follows:

<splitter_cfg>
<version>0.200000003</version>
<data_type>encoded</data_type>
<fft_len>2048</fft_len>
<ifft_len>8</ifft_len>
<filter>fft</filter>
<window>welsh</window>
<samples_per_wu>1048576</samples_per_wu>
<highpass>0</highpass>
<blanker_filter>randomize</blanker_filter>
</splitter_cfg>

Claggy

Since this is Richard's thread and he's invited my comment on the offtopic Mega WU stuff, I'll do so but keep it brief.

In both normal and Mega WUs there's a <nsamples>1048576</nsamples> in the 23rd line. That's what determines how much of the data will be processed, and explains why the processing time for Mega WUs is like normal WUs. The extra data is decoded but ignored.

The splitting process takes 107.374 seconds of 2.5 MHz. bandwidth data and divides it into 256 subbands of 9765.625 Hz. bandwidth, each of which is the data for one WU. The usual method first divides the data down to 2048 subbands of 1220.703125 bandwidth then combines sets of 8 to give the right bandwidth. That is a bandpass filter implemented directly with the FFTs which provides reasonably flat response across the bandwidth and reasonably steep skirts at the edges. The method used for the Mega WUs divides by 256 immediately and uses a digital polyphase filter to improve the shape. Code to do that method has been in the splitters since at least late 2005, the oldest I have saved.

Speculation: Since the Mega WUs have almost exactly 8 times as much data as normal WUs, the change in FFT lengths by a factor of 8 may be causing unwanted side effects. In any case, Murphy's law has been demonstrated once again.

                                                                  Joe

Since this is Richard's thread and he's invited my comment on the offtopic Mega WU stuff, I'll do so but keep it brief.

In both normal and Mega WUs there's a <nsamples>1048576</nsamples> in the 23rd line. That's what determines how much of the data will be processed, and explains why the processing time for Mega WUs is like normal WUs. The extra data is decoded but ignored.

The splitting process takes 107.374 seconds of 2.5 MHz. bandwidth data and divides it into 256 subbands of 9765.625 Hz. bandwidth, each of which is the data for one WU. The usual method first divides the data down to 2048 subbands of 1220.703125 bandwidth then combines sets of 8 to give the right bandwidth. That is a bandpass filter implemented directly with the FFTs which provides reasonably flat response across the bandwidth and reasonably steep skirts at the edges. The method used for the Mega WUs divides by 256 immediately and uses a digital polyphase filter to improve the shape. Code to do that method has been in the splitters since at least late 2005, the oldest I have saved.

Speculation: Since the Mega WUs have almost exactly 8 times as much data as normal WUs, the change in FFT lengths by a factor of 8 may be causing unwanted side effects. In any case, Murphy's law has been demonstrated once again.

                                                                  Joe

Pardon me, the ever simpleton.....
Does that mean this was an unexpected anomaly from a server code change?
Or something else?

---

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

Or is it an trial to see what impact on server loadings larger MB WU would have?

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Perhaps not the right place, sorry. I can't find the proper thread.

I have 5770, running in XP x64 environment. Default clocks. Using drivers 11.8 and r390 release of Raimster's OpenCL app.
It stuck when crunching MB WUs on several ocasions. Restarting BOINC causes BSOD, can be avoided with reboot, which is functionally same :). I've seen similar behavior when I was doing Bitcoins, when VGA was preclocked. I increased iteration_num command line parameter for 20 up to 100 in steps of 20, didn't help at all. Card is not overheating, running 70-71 deg.
Astropulse is okay, but several I did, werent pushing its utilization a much, mostly 60%.

I need to know from someone, who has similar conditions(OS, VGA and doing MBs) which drivers are trouble-free. It will save me great amount of time, needed to install and scratch each version of drivers, also several extra reboots bcs BSODs.

---

Perhaps not the right place, sorry. I can't find the proper thread.

No problem with the location. r390 is the version included in the installer, and it wasn't given a separate release/comment thread here.

But I can't help you with the ATI driver side of things, I'm afraid - have to wait for Raistmer or one of the other ATI support guys to pass by.

Perhaps not the right place, sorry. I can't find the proper thread.

I have 5770, running in XP x64 environment. Default clocks. Using drivers 11.8 and r390 release of Raimster's OpenCL app.
It stuck when crunching MB WUs on several ocasions. Restarting BOINC causes BSOD, can be avoided with reboot, which is functionally same :). I've seen similar behavior when I was doing Bitcoins, when VGA was preclocked. I increased iteration_num command line parameter for 20 up to 100 in steps of 20, didn't help at all. Card is not overheating, running 70-71 deg.
Astropulse is okay, but several I did, werent pushing its utilization a much, mostly 60%.

I need to know from someone, who has similar conditions(OS, VGA and doing MBs) which drivers are trouble-free. It will save me great amount of time, needed to install and scratch each version of drivers, also several extra reboots bcs BSODs.

actually 71 very hot for an ATI card. you'll want to adjust your fan speed to about 60% in the CCC. Before doing that... You'll need to update your drivers to 11.12 or 12.1 if available. 11.8 didn't actually work well since it dropped work to the CPU.

To do this first uninstall the current ATI drivers, then run the program Driver sweep to remove any ATI which the uninstall didn't catch, restart and install your 11.12 or 12.1 drivers. Make sure when it installs that the final page does not show an error when installing. If so just reinstall. then restart if necessary.

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope