Posts by Len LE/GE
log in
1) Message boards : Number crunching : Computation errors? (Message 61732)
Posted 19 May 2014 by Len LE/GE
It's probably your cat 13.9.
Can you try going back to 13.1 (seems save for nearly everyone) or up to 14.1 (seen a few people using it)?
2) Message boards : Number crunching : adequately supply or WUs: PLEASE: increase max_wus_in_progress or enable the Computing preference settings (Message 61657)
Posted 25 Apr 2014 by Len LE/GE
On two machines I am pretty much constrained to run BOINC 5.8.


Are you talking about version 5.8.16 (April 2007)?
Why are you limited to that one?
Are you still running Win95 or NT4 on those computers?

I have been running BOINC 5.10.45 (March 2008) on WinXP and Win2k for years without any reasonable problems before I upgraded BOINC to 6.10.58. And I am still using that version on Win7 now.
3) Message boards : News : Release of MilkyWay Sepearation Modified Fit v1.30 (Message 61601)
Posted 23 Apr 2014 by Len LE/GE
Message 60211 is an example I guess.
Isn't that about something like SSE2 on a cpu that is only able to do SSE?
4) Message boards : Number crunching : adequately supply or WUs: PLEASE: increase max_wus_in_progress or enable the Computing preference settings (Message 61600)
Posted 23 Apr 2014 by Len LE/GE
The old days of BOINC 5.8 ... some memories came back :)

BOINC is delaying results to send back in bulk; reason is to be nice to the servers.

BOINC 5.8 is a problem since it had no option to force sending results immediately. You had to push projects update to do it by hand. Only way out at that time was the job scheduler and BOINC command line options to force BOINC sending back results; it had to be done sensible or it was 'hammering' the servers.

If you can upgrade to any BOINC 6.1.+ (using 6.10.58 myself because I don't like the newer interface), you could use the cc_config setting report_results_immediately that I mentioned earlier. With that option, results are send back 60 seconds after they are finished and than BOINC should realize that it needs to ask for refilling the work cache.
5) Message boards : Number crunching : adequately supply or WUs: PLEASE: increase max_wus_in_progress or enable the Computing preference settings (Message 61588)
Posted 22 Apr 2014 by Len LE/GE
BOINC needs to request work first, than the MW server can respond and send WUs or say "max WU limit reached". If there is no request for new WUs, than it's a problem of the BOINC client. BOINC decides if it 'thinks' it needs more MW WUs.
BOINC although backs off for some time from a project if there was a connection problem to the server. Add to that the short runtimes of MW gpu WUs and it can take the time of a reasonable number of WUs finished before the next request for new WUs takes place.
Is BOINC set to send finished WUs right away? (see 'report_results_immediately')
Do finished WUs stay in queue too when no new request happens?
What does the log says when results are send back?

With run times of less than 1 minute, the minimum wait time between 2 requests set by the server (60 seconds for MW servers) hits too.
6) Message boards : News : Release of MilkyWay Sepearation Modified Fit v1.30 (Message 61541)
Posted 18 Apr 2014 by Len LE/GE
The source is here on GitHub.
I found it sometimes gives interesting hints about the latest changes and helped me in the past to understand how to use the cmdline line params to tweak the apps for my gpu.
7) Message boards : News : Release of MilkyWay Sepearation Modified Fit v1.30 (Message 61521)
Posted 16 Apr 2014 by Len LE/GE
Doesn't look like it.

The commits on github don't give any hints about it and I can't see a 32bit version for windows in the download directory.
8) Message boards : Number crunching : Milkyway@Home Separation (Modified Fit) v1.28 (opencl_nvidia) crashes on Titan (Message 61517)
Posted 16 Apr 2014 by Len LE/GE
Failed to move file 'separation_checkpoint_tmp' to 'separation_checkpoint' (15100): (null)
Failed to move file 'separation_checkpoint_tmp' to 'separation_checkpoint' (15105): (null)
Failed to move file 'separation_checkpoint_tmp' to 'separation_checkpoint' (15105): (null)
Failed to move file 'separation_checkpoint_tmp' to 'separation_checkpoint' (15105): (null)
Failed to move file 'separation_checkpoint_tmp' to 'separation_checkpoint' (15105): (null)
Failed to move file 'separation_checkpoint_tmp' to 'separation_checkpoint' (15105): (null)
Failed to move file 'separation_checkpoint_tmp' to 'separation_checkpoint' (15105): (null)
Failed to update checkpoint file ('separation_checkpoint_tmp' to 'separation_checkpoint') (34): Result too large
Integration time: 57.212246 s. Average time per iteration = 89.394134 ms
Integral 0 time = 63.559289 s
Failed to calculate integral 0
Failed to calculate likelihood
<background_integral> 1.#QNAN0000000000 </background_integral>
<stream_integral> 1.#QNAN0000000000 1.#QNAN0000000000 1.#QNAN0000000000 </stream_integral>
<background_likelihood> 1.#QNAN0000000000 </background_likelihood>
<stream_only_likelihood> 1.#QNAN0000000000 1.#QNAN0000000000 1.#QNAN0000000000 </stream_only_likelihood>
<search_likelihood> 1.#QNAN0000000000 </search_likelihood>

Not a NVIDIA guy either, but the checkpoint errors make me wonder. Why can't the prog write the checkpoint and why does it even want to write a checkpoint with only 1 minute runtime?
9) Message boards : Number crunching : adequately supply or WUs: PLEASE: increase max_wus_in_progress or enable the Computing preference settings (Message 61480)
Posted 8 Apr 2014 by Len LE/GE
Milkyway needs short turnaround times because the new WUs are generated based on the results coming in.
If you check this board, you will find several discussions about it.
10) Message boards : Number crunching : ATI GPU *and* Catalyst version help please! (Message 61379)
Posted 10 Mar 2014 by Len LE/GE
Restarted and deleted all the ATI folders I could find ...


Did you check for leftovers in windows\system32 and windows\system32\drivers?

I had it once with a cat11.x version, where uninstaller and cleaners still left old openCL drivers in the windows tree and they weren't replaced with a fresh install of the cat version I wanted. Can't remember if I had to delete reg keys by hand too.
I think I was reading somewhere that cat13.12 puts it's openCL drivers now in an own app folder outside of the windows tree. Cat 13.1 definitely still has them in the windows folders mentioned above.
11) Message boards : Number crunching : Benchmark results - times wanted for any hardware, CPU or GPU, old or new! (Message 61354)
Posted 8 Mar 2014 by Len LE/GE
Yep, those are the ones I mean.

Found the answer in the introduction thread for the 1.28 app.
It seems the Win x86 apps still have a bug letting them error out immediately. :(
12) Message boards : Number crunching : Benchmark results - times wanted for any hardware, CPU or GPU, old or new! (Message 61348)
Posted 7 Mar 2014 by Len LE/GE
That 3870 talked about before is using cat 12.4 which in general has openCL support.
After some search I found that the 3870 has no openCL support from the driver because the driver expects compute shader mode which the 3870 does not have. So openCL 1.0 starts with the 4xxx series.

The app table shows no x86 mod_fit apps for Windows, so I expect that to be the reason why noone on Win x86 gets them automatically.
Since the download folder has Win x86 apps it should be possible to run them with an app_info.
Question is: Why aren't they in the official app list? Are they untested? Do they have a bug? Or simply forgotten to put them in the table for automatically downloadable apps?
13) Message boards : Number crunching : No credits, verify errors for all work (Message 61329)
Posted 4 Mar 2014 by Len LE/GE
Anyone noticed
"Running Milkyway@home ATI GPU application version 0.23 (Win32, CAL 1.4) by Gipsel"

That Brook app is long time history.
You need openCL (I was using cc12.1 on XP) and and the app version 1.02
14) Message boards : Number crunching : All Milkyway@Home 1.02 tasks ending in computation error on HD6950. (Message 61179)
Posted 22 Feb 2014 by Len LE/GE
Your actual result list shows no errors for modified fit 1.28, no errors for n-body 1.40 and no errors for mw 1.02.

... boinc keeps running as a service.


Do not run boinc as a service. This might be the cause that you are seeing a confused local client showing errors while the results are valid.
15) Message boards : Number crunching : Home Separation (Modified Fit) v1.28 taking ages (Message 60796)
Posted 23 Jan 2014 by Len LE/GE
From the time differences I guess it was gpu (nonstop) vs. cpu (often suspended).
Since the WU is purged now, I can't verify.
16) Message boards : Number crunching : Suspend not suspending (Message 60649)
Posted 24 Dec 2013 by Len LE/GE
Check your computing preferences:
Is "Suspend GPU work while computer is in use?" set to "Yes"?
17) Message boards : Number crunching : Milkyway Lag (Message 60576)
Posted 14 Dec 2013 by Len LE/GE
mw gpu apps are designed to get as much as possible crunching power out of them with only very few calculations done on the cpu. The gpu is stressed far more than with other projects.
The frequency of 60 was choosen because it showed the best balance between max gpu use and a still responsive system. Still some combinations of hardware / software / driver can lead to a less responsive system or lagging. That's where the commandline params come into play. They can although help to increase your gpu use if needed.
18) Message boards : News : New Separation Runs (Message 60572)
Posted 14 Dec 2013 by Len LE/GE
Good find of those pattern.

Usually I expect a far newer scientific app to be more improved, but you are right that is has to be checked if there hasn't a new bug found it's way into the newer app. Before I thought it was only a difference in the last few digits. With the pattern you found now, this gives a completely different picture.

If the old CAL app gives the wrong numbers, the validator need to get fixed to catch those + results from the old app coming in from newer (openCL enable) GPUs need to get denied to reduce wrong validations.

If the newer app is the problem, we need a quick fix for this one.

Luckily the problematic results seem to be only a small number of all those results coming in.
19) Message boards : Number crunching : Milkyway Lag (Message 60555)
Posted 12 Dec 2013 by Len LE/GE
My best guess is to use an app_info.xml and play with the command line parameters.
The bad thing is that you need to define every app that you want to use in milkyway, not only the modified fit one.
20) Message boards : News : New Separation Runs (Message 60554)
Posted 12 Dec 2013 by Len LE/GE
Workunit 471493607

A Cayman (cat 12.6+) and a Tahiti (cat 12.4) gpu, both running the old 0.82 app, are validated against each other and a Cypress (cat 12.3) result with app 1.02 is marked invalid. That Cypress is usually running with ZERO invalids, which makes me wonder if the proper result was marked as bad.

<search_application> milkyway_separation 1.02 Windows x86_64 double OpenCL </search_application>
<background_integral> 0.000250000203482 </background_integral>
<stream_integral> 126.473032247388670 424.189607956046640 0.000000000000000 </stream_integral>
<background_likelihood> -3.715093764065778 </background_likelihood>
<stream_only_likelihood> -14.211423036510251 -3.997919366742975 -235.464758791616960 </stream_only_likelihood>
<search_likelihood> -3.079346382417015 </search_likelihood>

<background_integral> 0.000250000203482 </background_integral>
<stream_integral> 126.473032247388687 424.189607956046700 0.000000000000000 </stream_integral>
<background_likelihood> -3.715093764065778 </background_likelihood>
<stream_only_likelihood> -14.211423036510251 -3.997919366742975 -4.106932733094966 </stream_only_likelihood>
<search_likelihood> -2.988016909917461 </search_likelihood>
<search_application> milkywayathome_client separation 0.82 Linux x86_64 double CAL++ </search_application>

<background_integral> 0.000250000203482 </background_integral>
<stream_integral> 126.473032247388690 424.189607956046640 0.000000000000000 </stream_integral>
<background_likelihood> -3.715093764065779 </background_likelihood>
<stream_only_likelihood> -14.211423036510251 -3.997919366742975 -4.106932733094965 </stream_only_likelihood>
<search_likelihood> -2.988016909917461 </search_likelihood>
<search_application> milkywayathome_client separation 0.82 Windows x86_64 double CAL++ </search_application>


The old CAL app should only get accepted for gpus (i.e. HD3800) that can't run the newer openCL app.



Next 20

Main page · Your account · Message boards


Copyright © 2018 AstroInformatics Group