Posts by marmot

21) Message boards : Number crunching : 4t CPU time less than run time? (Message 989)
Posted 8 May 2017 by marmot
Post:
I noticed that 4T peak flops are 1/2 and credit is 1/2 credit per hour of an 8T WU even though they run on the same machine and same 4 cores.
It's been replicated on 5 different CPU's.
22) Message boards : Number crunching : 4t CPU time less than run time? (Message 988)
Posted 8 May 2017 by marmot
Post:
(can't delete dupe posting)
23) Message boards : Number crunching : Yafu 16t (Message 967)
Posted 6 Apr 2017 by marmot
Post:
I have another 16t work unit and it also is running on just the single core (over 3 days so far).
I run Amicable Numbers and it runs on the number of cores set for it (was 16 but have reduced to 8). When running Milkyway it also uses the full 16 cores.

So I don't know why YAFU wont use the cores I have, nothing is at high priority which usually will stop a "mt" WU from running.

It is only the 16t wu's as the 8t and 4t work units on this host run the required number of cores.

Conan


This one finally finished after about 13 days WU 728864.
Again it ran just in single mode and would not use all the available cores.

Conan




All the WU types (MT, 4T, etc) have a consolidation period in between ECM and GNFS sections where YAFU runs as a solo process with 1 to 16 cores.
At the very end, YAFU.exe runs in single thread, NCI mode with high disk usage as it compiles the data into it's final result.

Maybe it's possible that every time you were viewing the WU that it was in consolidation mode?
The consolidation can take 15 minutes to an hour on the 16T and the final database collection can take some hours also.

If that's not what happened, check your app_config.xml for typos.
It's always a typo that gets me so I switched to Notepad++ and it color codes the tags and turns them red when the tags don't match up.

(BTW, the credit you received for that WU was horrible!)
24) Message boards : Science : Lehmer 5 (Message 960)
Posted 20 Mar 2017 by marmot
Post:
Do we ever spend time extending the sequence of 276, 552, 564, 660, or 966?

Is there a place to view the graphs of each number run?
25) Message boards : News : Aliquot sequence 708420 has terminated!!! (Message 959)
Posted 20 Mar 2017 by marmot
Post:
How did 708420 terminate?

Was it prime, perfect, amicable, or sociable?

---
I can see how it might take years of calculations to finally pin all 9160 down.

We can prove Catalan conjecture for n<1,000,001 but beyond that, no.
26) Questions and Answers : Web site : Private messaging system (Message 957)
Posted 19 Mar 2017 by marmot
Post:
Is the private messaging system delivering messages?
27) Message boards : Number crunching : Workunit 835151 (Message 956)
Posted 18 Mar 2017 by marmot
Post:
I've run a lot of these and, if it fails, then it fails with an error during calculation and that was usually a system crash or my error during system reconfiguration.
Only 3 of over 1000 have failed on their own.

Longest run time I've seen is about 7 days.

This project is best on dedicated machines that never shut down or not used for gaming. The project has gotten along with other projects running concurrently.
28) Message boards : Number crunching : No work? (Message 955)
Posted 18 Mar 2017 by marmot
Post:
Thanks for the work.
Check your inbox.
29) Message boards : Number crunching : need app_info.xml stuff for non-MT app (Message 927)
Posted 25 Jan 2017 by marmot
Post:
<!-- YAFU -->
<app_config>
<!-- YAFU -->
<!-- YAFU -->
<app_version>
<app_name>yafu</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>2</avg_ncpus> This is the number of threads you want to run
<cmdline>--nthreads 2</cmdline>
</app_version>
</app_config>[/b]


Thanks! I didn't know the plan class as 'mt' and was struggling to get this to work.
30) Message boards : News : Aliquot sequence 708420 has terminated!!! (Message 926)
Posted 25 Jan 2017 by marmot
Post:
My resource share in preferences is stuck at 0 (shows --- when editing) and so can't get any WU's.
Tried entering 100, 1, 99... the HTML control will accept numbers but then zeros out upon saving.
31) Message boards : Number crunching : Yafu 16t (Message 912)
Posted 10 Dec 2016 by marmot
Post:


Well the work unit finished after a run time of 335205 seconds and a cpu time of 874320.70 seconds.
This says it ran for 93 hours and received 2096 credits.

As such the credit turned out to be miserable at just 2 cr/h counting the CPU time and 22 cr/h counting the RUN time


Are they all going to be that low?

Maybe I should terminate these 2 16t's and go back to 8t?
32) Questions and Answers : Windows : multiple bugs and issues with Yafu on multiple machines (Message 798)
Posted 8 Nov 2015 by marmot
Post:
Yep, Yafu is only allowed work on the old Dell Precision m6400 now.

The one thing I listed as a bug is seems actually to be the nature of the algorithm for this problem where the progress will seem to be a asymptotic prgression to completion. All the large WU that I watched progressed this way.

The HP8560p with an i5 2nd gen had the most stable ECM.exe performance where they stayed in RAM and ran 100% CPU slices. I know the Phenom II series AMD run VERY hot when doing Floating POint calculations so maybe the algorithm is taking this into account? I used SM_stress test on the 1090T and when it hit FP the temp shot to 58C. Is the ECM.exe heavily floating point?

I think it would be better to let the jobs go much longer and stay on 1 core as this claiming all cores is a harsh tactic especially when GPU's get stalled. Climate WU's can go on for 300 hours and so do some Collatz problems and they give 50% long time bonus. I'd prefer that much more over the total core take over.
33) Questions and Answers : Windows : multiple bugs and issues with Yafu on multiple machines (Message 796)
Posted 7 Nov 2015 by marmot
Post:
Here is a list of the issues I've had with this project since joining 2 days ago.

1090t machine:
-random reboots (not heat related, as the temp was cooler than other WU's)
-ECM.exe process running on one core while locking out the other 5 cores from other work
-Yafu.exe running on 5 cores asymptotically approaching 0% left. Was at 16 hours and every 1 hour run an ever-decreasing slice of remianing time would be removed. Suspending that WU crashed BOINC completely. Upon restart the work unit went back to 89% (from 99.864%) and 45 minnutes left and only thought it had put in 4 hours instead of 16.
-Yafu claiming 6 cores in description while only 1 ECM.exe runs and 5 period_search (Asteroids@home) are running but BOINC manager claims Asteroids are all not running.
-ECM.exe runs then drops out of RAM in constant flux.

Dell Precision m6500
-suspending Yafu WU resets timer back to 0% complete
-suspending 4 Yafu WU's yet 4-8 ECM.exe processes kept running and dropping even after closing BOINC and telling it to stop all work.
-ECM.exe packets running even though Asteroids, ClimatePrediction packets are running status in BOINC manager.

HP 8560w
-ECM.exe packets running after WU is suspended.
-Yafu.exe preventing Einstein@Home (or Moo!) GPU WU's from getting enough CPU to run efficiently (determined by 20 degree celsius drop in GPU output).

Dell Precision m6400
-again interferes with Einstein, SETI GPU WU CPU requirements so they run less effectively.


Capturing and holding all cores, crashing BOINC, not getting along with GPU WU's, refusing to suspend, resetting it's progress upon suspension, using less cores than claimed are I guess things to be expected from an alpha project.

The ECM.exe app seems to be the culprit and needs to be worked over.
I'm not sure why Yafu needs to claim all cores but that alone is enough to deter many people from running this code.

Since Yafu is an alpha project maybe I'll dedicate an older CoreDuo machine to it where these issue might be negligible.


Previous 20




Datenschutz / Privacy Copyright © 2011-2024 Rechenkraft.net e.V. & yoyo