Computation error ?
log in

Advanced search

Message boards : Number crunching : Computation error ?

1 · 2 · Next
Author Message
BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18780 - Posted: 6 Mar 2014, 21:50:30 UTC

Is this computation error caused by something I can (potentially) fix or do I just live with it.

-------------------------------------

Name solo_collatz_2370392632320376678767_412316860416_0
Workunit 883154
Created 6 Mar 2014, 17:44:17 UTC
Sent 6 Mar 2014, 17:51:05 UTC
Received 6 Mar 2014, 18:55:56 UTC
Server state Over
Outcome Computation error
Client state Compute error
Exit status -1 (0xffffffffffffffff) Unknown error number
Computer ID 139595
Report deadline 13 Mar 2014, 21:51:05 UTC
Run time 321.95
CPU time 2.87
Validate state Invalid
Credit 0.00
Application version solo_collatz v6.03 (cuda55)
Stderr output

<core_client_version>7.2.39</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -1 (0xffffffff)
</message>
<stderr_txt>
Collatz Conjecture v6.01 Windows x86_64 for CUDA 5.5
Based on the AMD Brook+ kernels by Gipsel
verbose=1
threads=8
items_per_kernel=22
kernels_per_reduction=8
sleep=1
Config: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Name GeForce GTX 760
Compute 3.0
Parameters --device 0
Start 2370392632732693539183
Checking 412316860416 numbers
Numbers/Kernel 4194304
Kernels/Reduction 256
Numbers/Reduction 1073741824
Reductions/WU 384
Threads 256
Using: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Suspending...
verbose=1
threads=8
items_per_kernel=22
kernels_per_reduction=8
sleep=1
Config: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Name GeForce GTX 760
Compute 3.0

Resuming at 2370392632903418489199
Using: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
At offset 376992749827 got 1723 from the GPU when expecting 565
Error: GPU steps do not match CPU steps. Workunit processing has been aborted.
18:52:49 (8316): called boinc_finish

</stderr_txt>
]]>

-------------------------------------

Bob

Profile Zydor
Avatar
Send message
Joined: 19 Aug 09
Posts: 364
Credit: 840,811,292
RAC: 0
Message 18782 - Posted: 6 Mar 2014, 23:02:47 UTC - in response to Message 18780.
Last modified: 6 Mar 2014, 23:18:31 UTC

Cant do much until your data on the PC is taken off Hiding mode. Once that's done, a relative view off the PC concerned together with the file posted can be taken. Whilst its on "Hidden" little meaningful deduction can be made - as such. Potentially its an error that will reoccur, may already be doing so.

Go to "Your Account", "Collatz Preferences" - Select "Primary (default) prefences" - "edit preferences" - and tick the box:

"Should Collatz Conjecture show your computers on its web site?"

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18784 - Posted: 6 Mar 2014, 23:54:02 UTC - in response to Message 18782.

Ooops. Should be visible now.

Bob

Profile Slicker
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 11 Jun 09
Posts: 2525
Credit: 740,580,099
RAC: 2
Message 18786 - Posted: 7 Mar 2014, 0:10:12 UTC - in response to Message 18780.

Is this computation error caused by something I can (potentially) fix or do I just live with it.

-------------------------------------

Name solo_collatz_2370392632320376678767_412316860416_0
Workunit 883154
Created 6 Mar 2014, 17:44:17 UTC
Sent 6 Mar 2014, 17:51:05 UTC
Received 6 Mar 2014, 18:55:56 UTC
Server state Over
Outcome Computation error
Client state Compute error
Exit status -1 (0xffffffffffffffff) Unknown error number
Computer ID 139595
Report deadline 13 Mar 2014, 21:51:05 UTC
Run time 321.95
CPU time 2.87
Validate state Invalid
Credit 0.00
Application version solo_collatz v6.03 (cuda55)
Stderr output

<core_client_version>7.2.39</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -1 (0xffffffff)
</message>
<stderr_txt>
Collatz Conjecture v6.01 Windows x86_64 for CUDA 5.5
Based on the AMD Brook+ kernels by Gipsel
verbose=1
threads=8
items_per_kernel=22
kernels_per_reduction=8
sleep=1
Config: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Name GeForce GTX 760
Compute 3.0
Parameters --device 0
Start 2370392632732693539183
Checking 412316860416 numbers
Numbers/Kernel 4194304
Kernels/Reduction 256
Numbers/Reduction 1073741824
Reductions/WU 384
Threads 256
Using: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Suspending...
verbose=1
threads=8
items_per_kernel=22
kernels_per_reduction=8
sleep=1
Config: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Name GeForce GTX 760
Compute 3.0

Resuming at 2370392632903418489199
Using: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
At offset 376992749827 got 1723 from the GPU when expecting 565
Error: GPU steps do not match CPU steps. Workunit processing has been aborted.
18:52:49 (8316): called boinc_finish

</stderr_txt>
]]>

-------------------------------------

Bob



I you want to double check it yourself, just add the offset to the starting number and then do the 3x+1 formula yourself. ;-)

Thanks for posting the output. My guess is that the checkpoint is screwing up the offset and so the error is due to it comparing start_number + offset to resume_start + offset (when it should be using start_number in both cases).

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18792 - Posted: 7 Mar 2014, 11:24:52 UTC - in response to Message 18786.

The checkpoint doesn't always cause a problem though.

-------------------------------

Name solo_collatz_2370406018805725374831_824633720832_0
Workunit 918184
Created 7 Mar 2014, 8:13:24 UTC
Sent 7 Mar 2014, 8:18:46 UTC
Received 7 Mar 2014, 11:15:02 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 139595
Report deadline 14 Mar 2014, 12:18:46 UTC
Run time 1,029.48
CPU time 9.55
Validate state Valid
Credit 7,709.13
Application version solo_collatz v6.03 (cuda55)
Stderr output

<core_client_version>7.2.39</core_client_version>
<![CDATA[
<stderr_txt>
Collatz Conjecture v6.01 Windows x86_64 for CUDA 5.5
Based on the AMD Brook+ kernels by Gipsel
verbose=1
threads=8
items_per_kernel=22
kernels_per_reduction=8
sleep=1
Config: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Name GeForce GTX 760
Compute 3.0
Parameters --device 0
Start 2370406019630359095663
Checking 824633720832 numbers
Numbers/Kernel 4194304
Kernels/Reduction 256
Numbers/Reduction 1073741824
Reductions/WU 768
Threads 256
Using: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Suspending...
verbose=1
threads=8
items_per_kernel=22
kernels_per_reduction=8
sleep=1
Config: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1
Name GeForce GTX 760
Compute 3.0

Resuming at 2370406020427075529071
Using: verbose=1 items_per_kernel=4194304 kernels_per_reduction=256 threads=256 sleep=1

Highest Steps 1736 for 2370406019757317067903
Total Steps 439992266314100
Avg Steps 533
CPU time 20.5141 seconds
Total time 1262.9 seconds
10:13:24 (7140): called boinc_finish

</stderr_txt>
]]>

-------------------------------

Bob

Profile Zydor
Avatar
Send message
Joined: 19 Aug 09
Posts: 364
Credit: 840,811,292
RAC: 0
Message 18794 - Posted: 7 Mar 2014, 12:51:28 UTC - in response to Message 18792.
Last modified: 7 Mar 2014, 12:52:37 UTC

Bob

I suspect the settings in the .xml configuration file, are too fast for it at the moment, and you are getting the failures. Try two things....

First - dial the items per kernel back to 20, see if it settles to no errors, keep stepping back until you get no errors (as such - you'll usually get a couple over 24hrs when at high speed). I would be very surprised if you had to go to 19, if you do, need to ferret some more as to what is happening

Second - then step back up from there one step at a time, leaving a good chunk of time between steps. Likely with the current tuning state of your card you will be better off at 20 or 21, and 22 is too much for it until properly tuned.

I'll leave a PM for you .... be there in a few minutes

Profile Slicker
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 11 Jun 09
Posts: 2525
Credit: 740,580,099
RAC: 2
Message 18797 - Posted: 7 Mar 2014, 13:37:02 UTC - in response to Message 18794.

Bob

I suspect the settings in the .xml configuration file, are too fast for it at the moment, and you are getting the failures. Try two things....

First - dial the items per kernel back to 20, see if it settles to no errors, keep stepping back until you get no errors (as such - you'll usually get a couple over 24hrs when at high speed). I would be very surprised if you had to go to 19, if you do, need to ferret some more as to what is happening

Second - then step back up from there one step at a time, leaving a good chunk of time between steps. Likely with the current tuning state of your card you will be better off at 20 or 21, and 22 is too much for it until properly tuned.

I'll leave a PM for you .... be there in a few minutes


Usually, when the host is trying too hard to do too much either via overclocking or config settings, the GPU returns a ridiculously high number of steps. Since the steps are within the expected range, that may not be the case here. Has it happened often? Or is this the very first time? If it happened before, was the WU also suspended? It is hard to base a theory on the output of a single result.

Profile Slicker
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 11 Jun 09
Posts: 2525
Credit: 740,580,099
RAC: 2
Message 18800 - Posted: 7 Mar 2014, 14:50:46 UTC - in response to Message 18792.

The checkpoint doesn't always cause a problem though.


which makes it even harder to find and fix the problem.

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18805 - Posted: 7 Mar 2014, 19:51:06 UTC - in response to Message 18800.

Zydor, Slicker,

FYI my GPU is an 'ASUS GEFORCE GTX 760 DirectCU II OC'. The GPU runs at 1097MHz. With Collatz the temperature runs at about 68/69C and the GPU at 99%. I have not altered any of the GPU parameters.

If I remember correctly I've had 4 tasks fail with this error and they had all been suspended just before the error. However, as noted above, several other taks have been suspended and resumed with no problem. I am well aware that this could be a difficult problem to resolve as it could be hardware, or software, or both. It is only a small numbr of tasks that fail; not enough to really concern me but enough for me to report them.

I am reluctant to modify the GPU parameters as it performs perfectly 99% of the time. But I have no problem playing with the .xml file.

Possibly an aside but I tried GPUGRID for a (short) while and found that at least 50% of the tasks failed due to some sort of error. This was probably due to the program doing its best to melt my GPU. The only solution seemed to be either cool it with liquid nitrogen or severely downclock the GPU, neither of which I was inclined to do because of the knockon effects on other projects and programs.

For the moment I'll follow Zydor's suggestion and modify the .xml file.

Thanks for the intererst and replies.

Bob

Profile Slicker
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 11 Jun 09
Posts: 2525
Credit: 740,580,099
RAC: 2
Message 18806 - Posted: 7 Mar 2014, 21:24:57 UTC - in response to Message 18805.

Zydor, Slicker,

FYI my GPU is an 'ASUS GEFORCE GTX 760 DirectCU II OC'. The GPU runs at 1097MHz. With Collatz the temperature runs at about 68/69C and the GPU at 99%. I have not altered any of the GPU parameters.

If I remember correctly I've had 4 tasks fail with this error and they had all been suspended just before the error. However, as noted above, several other taks have been suspended and resumed with no problem. I am well aware that this could be a difficult problem to resolve as it could be hardware, or software, or both. It is only a small numbr of tasks that fail; not enough to really concern me but enough for me to report them.

I am reluctant to modify the GPU parameters as it performs perfectly 99% of the time. But I have no problem playing with the .xml file.

Possibly an aside but I tried GPUGRID for a (short) while and found that at least 50% of the tasks failed due to some sort of error. This was probably due to the program doing its best to melt my GPU. The only solution seemed to be either cool it with liquid nitrogen or severely downclock the GPU, neither of which I was inclined to do because of the knockon effects on other projects and programs.

For the moment I'll follow Zydor's suggestion and modify the .xml file.

Thanks for the intererst and replies.

Bob



If the number with the highest steps is found prior to suspending, then when it resumes and no number with higher steps is found, it works fine. But, if after suspending, it finds a number with higher steps, that __sometimes__ seems to cause a problem. The difficulty is that on another system, the exact location where it checkpoints is different because of the difference in speed. What I need to do is write a custom app that forces a checkpoint in the same spot as when you ran it and the step through in debug after resuming. I think I have a fix, but I have to prove I can duplicate the issue before I can test whether the fix will work. Or, at a minimum, do testing and try and prove the fix doesn't break it any worse than it currently is.

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18807 - Posted: 7 Mar 2014, 21:41:51 UTC

Slicker,

As it appears, at the moment, to possibly be a software problem, I'll leave the .xml file as it was until I hear otherwise. If there's any other info I can give you let me know.

Bob

Profile Zydor
Avatar
Send message
Joined: 19 Aug 09
Posts: 364
Credit: 840,811,292
RAC: 0
Message 18808 - Posted: 7 Mar 2014, 22:22:29 UTC - in response to Message 18805.
Last modified: 7 Mar 2014, 22:25:09 UTC

Possibly an aside but I tried GPUGRID for a (short) while and found that at least 50% of the tasks failed due to some sort of error. This was probably due to the program doing its best to melt my GPU. The only solution seemed to be either cool it with liquid nitrogen or severely downclock the GPU, neither of which I was inclined to do because of the knock on effects on other projects and programs.


I would try and dial back the core three settings in the .xml configuration file to ..... maybe .....

verbose=1
items_per_kernel=18
kernels_per_reduction=8
threads=7
sleep=1

The 18 setting is probably a low one for your card, but it will aid getting this stable, then move forward. These days that card is a notch below the mid point on the richter scale of GPU performance, and I would have thought 22 is too much for it, 21 is probably the top end, with 20 being likely sensible outcome. But you will only find that out by trying a low setting and work up.

Its worth a shot whilst we wait for the outcome of Slickers work.

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18809 - Posted: 8 Mar 2014, 0:24:12 UTC - in response to Message 18808.

Zydor,

OK. Have done so.

Will also be interested to see if there is any effect on the task duration and GPU load.

I run several projects so not quite sure when I'll get the requisite data.


Bob

Profile Zydor
Avatar
Send message
Joined: 19 Aug 09
Posts: 364
Credit: 840,811,292
RAC: 0
Message 18810 - Posted: 8 Mar 2014, 9:53:06 UTC - in response to Message 18809.
Last modified: 8 Mar 2014, 10:26:10 UTC

Will also be interested to see if there is any effect on the task duration and GPU load.

Looking fine so far ..... but I suspect you will hate the next bit - keep the faith :)

Your CPU time column is way low, which indicates you are forcing down the time for CPU. Let it go to a full core...

That column is at present, basicly, gibberish - not strictly true, its not telling lies, but its not telling us anything we need to know. Ignore - totally - the CPU time column. It'll get sorted in the end, but for now, ignore the values inside the CPU time column.

Set - for now - your CPU allocation as CPU = 1, give it a whole Core. Let that settle for a few hours, and then if its a consistent result (circa +/- 70secs time variance for full size WUs), set it to CPU=0.5 and leave it.

Collatz needs a CPU setting of 0.25 bare minimum, but ideally 0.5. You may settle on a value between the two in the end, but for now CPU 0.5 is the median value. It needs those CPU values, throw away classic BOINC practices, ramming down CPU to classic low allocations will end up throttling it.

When thats settled, go back up the scale on your detailed settings stopping at 21, don't force the beast to 22, with yours I *think* it will struggle at 22 (don't forget to restore the other two values to their full setting of 8 and 9).

I know the temptation - been there done that rofl - but do take the time to slowly step up the value from 18 to 21 (max for your GPU) one step at a time. Lets see how it goes then.... we may have to go one further step to bring them down to +/- 600 secs, but lets see how it goes.

Whilst you are waiting for each stage to settle, go read the thread below from post one ..... its short(ish!) .... it will show an overview of the core configuration needed, and its "evolution"

http://boinc.thesonntags.com/collatz/forum_thread.php?id=1009

(You may well get fed differing WU sizes, don't let that cloud this issue, its something Slicker is working on - just extrapolate times in proportion based on how long shorter ones run compared to a full WU)

Profile Slicker
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Avatar
Send message
Joined: 11 Jun 09
Posts: 2525
Credit: 740,580,099
RAC: 2
Message 18811 - Posted: 8 Mar 2014, 15:38:48 UTC

Version 6.04 of the CUDA55 app has been released for Windows which should fix the bug. Linux versions will follow shortly.

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18815 - Posted: 9 Mar 2014, 12:15:14 UTC - in response to Message 18811.

Slicker,

Thanks for fixing it so quickly.

Bob

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18816 - Posted: 9 Mar 2014, 12:30:18 UTC - in response to Message 18810.

Zydor,

Read and understood your msg. Seems like a good plan to follow.

The CPU time puzzles me possibly through lack of knowledge. I thought that the CPU time specified for a task was merely an indication to BOINC for scheduling purposes and that the tasks took whatever CPU time they needed when running. I have allocated 3 cores (out of 4) for BOINC so there is 1 core free (as I understand it) for the GPU. So I run 3 CPU only tasks and 1 or 2 tasks (depending what is available) on the GPU.

My CPU is an Intel Core i5 Quad 2500K (Sandy Bridge) OC to 4.3GHz. It is 100% stable.

Bob

Profile Zydor
Avatar
Send message
Joined: 19 Aug 09
Posts: 364
Credit: 840,811,292
RAC: 0
Message 18818 - Posted: 9 Mar 2014, 16:26:18 UTC - in response to Message 18816.
Last modified: 9 Mar 2014, 16:42:10 UTC

There are two CPU related timings - one that applies to a Core for a CPU based WU, and a separate timing where all or part of a Core are allocated to a GPU to provide support for GPU crunching. They are totally separate entities.

So, you allocate Cores to CPU crunching (in your case 3), and allocate Core(s) to GPU crunching, in your case 1. Now forget the CPU WU allocated CPU cores - they will do their thing .... focus on the single CPU core you made available to GPU crunching.

The statement:
<cpu_usage>1.0</cpu_usage>
inside the app_config allocates a whole CPU core a BOINC GPU WU. in the case above its giving it a whole Core. Common useage for BOINC since the early days has resulted in allocating only a fraction of a core to GPU WUs - the time honoured 0.05 (etc).

That practice is so burned into the common practice for BOINC - that to allocate a whole CPU core to BOINC in the past, was considered a gross waste, and few did it, resulting in the above statement (typically) reading:
<cpu_usage>0.05</cpu_usage>
.... and come hell or high water that was the maximum CPU resource BOINC allowed each GPU (in the case above 0.05 of a CPU) To allocate more of a CPU was considered (and frankly pretty well was [then] a) waste.

Its all change now ..... with the advent of the new BOINC apps at Collatz starting from nearly a year ago - it needs more then 0.05 of a CPU, it needs 0.25 bare minimum, preferably 0.5 CPU per core, and the above statement inside app_config should read:
<cpu_usage>0.5</cpu_usage> as the common initial value.

Many many folk are still allocating 0.05 CPU per Core (etc) because that's what they are used to since the dawn of BOINC, and Collatz has suffered from this for nearly a year now. At Collatz, the statement inside cpu_usage MUST be set to a minimum of 0.25, preferably 0.5 . Those who restrict it down to 0.05 (etc) because that's what they have done for years, have just blown the Collatz GPU WUs, and throttled them. Its easy to spot those doing this, their GPU WU times are circa 1400 secs plus, and the (completely useless and meaningless "CPU time(sec)" column has a low figure force fed it by the very low CPU useage figure of circa 0.05.

In BOINC, that "CPU time(sec)" is a major anomaly in its raw state, it useless in the current paradimn - ignore it, don't use it here. Some Projects have a local home grown tweek to utilise that column, at present not here - that column should be Utterly ignored, and the GPU allocated 0.5CPU as a routine by using the app_config statement above.

That's a hell of a wordy wordy way to say ignore that column totally , and put 0.5 inside the CPU statement of app_config (I have cores to spare not being used, so I give each GPU a full core)....... the problem is we are "chasing the horse after its bolted from the stable" and people still allocate 0.05 because that's what they have done for years - now, that will THROTTLE the GPU because it needs circa 0.5 CPU per GPU.

CPU useage per GPU must now be 0.25 CPU minimum, preferably 0.5, NOT 0.05 (etc)

BobMALCS
Send message
Joined: 7 Feb 14
Posts: 11
Credit: 153,943,047
RAC: 36,563
Message 18819 - Posted: 9 Mar 2014, 17:26:13 UTC - in response to Message 18818.

I do not have an app_config for Collatz although I do have for another couple of projects. The implication is that I MUST have an app_config for Collatz. I have not deliberately limited Collatz in any way.

Looking at the client_state.xml file in the Collatz section I see the following (which I have not modified in any way).

<app_version>
<app_name>solo_collatz</app_name>
<version_num>604</version_num>
<platform>windows_x86_64</platform>
<avg_ncpus>0.010000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>

<flops>3870824289727.138200</flops>
<plan_class>cuda55</plan_class>
<file_ref>
<file_name>solo_collatz_6.04_windows_x86_64__cuda55.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>solo_collatz_6.04_windows_x86_64__cuda55.pdb</file_name>
<copy_file/>
</file_ref>
<file_ref>
<file_name>cudart64_55.dll</file_name>
<copy_file/>
</file_ref>
<file_ref>
<file_name>solo_collatz_windows_x86_64_cuda.config</file_name>
<open_name>collatz.config</open_name>
<copy_file/>
</file_ref>
<coproc>
<type>NVIDIA</type>
<count>1.000000</count>
</coproc>
<gpu_ram>48234496.000000</gpu_ram>
<dont_throttle/>
</app_version>

The highlighted lines imply to me (possibly totally wrongly) that a Collatz task requires up to 1 CPU. However it seems likely that BOINC applies the minimum value unless specified otherwise.

OK. I have no problem creating an app_config. However, if the above statements influence the CPU usage then they should be looked at.

Profile Zydor
Avatar
Send message
Joined: 19 Aug 09
Posts: 364
Credit: 840,811,292
RAC: 0
Message 18820 - Posted: 9 Mar 2014, 17:43:18 UTC - in response to Message 18819.
Last modified: 9 Mar 2014, 17:52:53 UTC

In the new BOINC paradigm - its not just Collatz, it applies to all Projects, there are three control files, all three must be used to avoid some real wacky outcomes, the new format files are so small its no hassle:

1. Inside the BOINC Directory: cc_config.xml
2. Inside The Collatz directory: app_config.xml
3. Inside the Collatz Directory: a huge named file that will change slightly for some makes of GPU, mine is:
solo_collatz_6.04_windows_x86_64__opencl_amd_gpu.xml configuration

All three MUST be used. The format of those and how to build them is in:
http://boinc.thesonntags.com/collatz/forum_thread.php?id=1009

Suggest you go to that thread, and start from post one - its not too long, couple of pages, you will see the three key files discussed there. The problem at present for many, is they are not using all three, and not paying a close watch on the file extension when saved.

Have a look at that thread, BOINC has changed massively under the hood, and there are now three control files that need to be filled in (shown above).

What happened was BOINC switched from Front End processing (ie all detail supplied in User config files), to Back End processing (ie minimal User files, BOINC now auto supplies needs from the basic info supplied inside the three new control file Types).

Until that concept is hoisted aboard, WUs will continue to fall over or take massive long times to finish.

I suggest you look at that thread and work through the "new" formats, and if you have detailed question post it here - that way that thread stays relatively clean and relatively easy to find the Core information on the new file formats

1 · 2 · Next
Post to thread

Message boards : Number crunching : Computation error ?


Main page · Your account · Message boards


Copyright © 2018 Jon Sonntag; All rights reserved.