Posts by zombie67 [MM]

1) Message boards : News : New app, YAFU-64t (Message 1705)
Posted 13 Jan 2023 by zombie67 [MM]
Post:
Can the number of 64t tasks available for download please be increased? Quite often, there are none available, so the machine sits idle.
2) Message boards : News : New app, YAFU-64t (Message 1694)
Posted 31 Dec 2022 by zombie67 [MM]
Post:
Voicing similar concerns here, I have a task, yafu_ali_216840_L151_C145_1672156508_23, that has taken over 56 hours to this time. It is showing 99.993% complete. Task manager shows the task only taking 7.1% CPU. Since this is such a new application, I'm wondering if what I'm seeing is "normal".

Thanks,
Steve


That looks normal to me. I ran a 128t task. Total run time on a 64 thread threadripper took 74 hours. The majority of the task was done in less than a day, then the last 10% or so took the rest of the time. In that last, long phase there were many hours where the CPU was idle, with occasional spikes. But it eventually completed successfully. This is on windows.
3) Message boards : News : New app, YAFU-64t (Message 1680)
Posted 27 Dec 2022 by zombie67 [MM]
Post:
When I try to get a 64t task, I get"

375    yafu    12/27/2022 5:35:42 AM    Message from server: YAFU-64t needs 1560.21MB more disk space.  You currently have 7022.86 MB available and it needs 8583.07 MB.    


But this is what BOINC says at startup:

11            12/27/2022 5:41:52 AM    OS: Linux Linuxmint: Linux Mint 20 [5.4.0-135-generic|libc 2.31 (Ubuntu GLIBC 2.31-0ubuntu9.9)]
12            12/27/2022 5:41:52 AM    Memory: 125.72 GB physical, 2.00 GB virtual
13            12/27/2022 5:41:52 AM    Disk: 413.51 GB total, 265.48 GB free 


And I have tried settings that say to "Leave at least 1gb free" and I tried "Use more more than 99%". Neither setting resolves the issue.
4) Message boards : Number crunching : checkpoint question (Message 452)
Posted 16 Jul 2012 by zombie67 [MM]
Post:
What is the frequency of checkpointing for yafu?
5) Message boards : Number crunching : GPUs cause yafu to not run (Message 451)
Posted 15 Jul 2012 by zombie67 [MM]
Post:
Yeah, I think they fixed it so that the MT task does not preempt the GPU task. And that is working correctly. The problem is that the MT task does not know to use "total threads minus GPU allocations". It wants all the threads. So it just sits there eternally waiting to run.
6) Message boards : Number crunching : GPUs cause yafu to not run (Message 448)
Posted 14 Jul 2012 by zombie67 [MM]
Post:
I have a couple of GPU tasks running, each is allocating .7 of a CPU thread. Yafu tasks site idle, because they say they need all the CPU threads.

I think this was brought up here in the past, and maybe on the mail lists too. Was a solution ever found? For what it's worth, this is with 7.0.31.
7) Message boards : Number crunching : How much crunching left? (Message 432)
Posted 10 Jul 2012 by zombie67 [MM]
Post:
According to this list http://factorization.ath.cx/stat_1.php we will reach C110 in the next days. There are 15k composites which are 110 digits long.
yoyo


This is all beyond me. "we will reach C110 in the next days" How many days is that? 2? 10? 50? I don't understand.

Also, do you mean "reach", meaning that is when we start 110? Or when we complete 110? I am really confused here.
8) Message boards : Number crunching : How much crunching left? (Message 430)
Posted 8 Jul 2012 by zombie67 [MM]
Post:
Okay. When do you anticipate we will reach C110?
9) Message boards : Number crunching : How much crunching left? (Message 428)
Posted 8 Jul 2012 by zombie67 [MM]
Post:
Yoyo,

Back in December, I asked how much longer the project will run. You said, "I think at least 6 more month[...]" Can we please get an updated projection?

Thanks!
10) Message boards : Number crunching : app reporting negative CPU (Message 361)
Posted 28 Feb 2012 by zombie67 [MM]
Post:
Hi Yoyo,

I read those messages. And after reviewing the numbers a bit more, I think DA is right. CPU time is not considered.

Thanks for looking into this!


But something seriously funky is going on. Here are the results from one of my machines that has been running long enough for "credit learning" to have stabilized. It is a 6 thread machine. I took the last 20 valid tasks, stuck them in a spreadsheet, and then sorted by credit/hour/thread. Notice the CPU time does not correlate at all.

But also notice the highest c/h/t is ~4x the lowest. How can that possibly be? I know DA said that CreditNew "makes no promises about individual jobs or about credit/hour", but 4x variation? Without rhyme or reason? This is ridiculous! I know, not your problem. You are just running the stock code. I guess I am just venting about CreditNew (again). FWIW, POEM tried to implement CreditNew, and had to give up. They switched to fixed credits. Not an option here, of course.


Task#___WU#__________Run______CPU___Credit__c/h/t

657265__646256______3.06_____0.00_____0.13__25
657175__646166_____64.18_____4.93_____2.79__26
657191__646182____136.35_____9.21_____5.93__26
657174__646165___2738.73___293.34___119.13__26
657208__646199___3478.18___435.78____151.3__26
657264__646255_____99.31___432.82_____4.32__26
657225__646216___2719.29___440.37___118.29__26
657266__646257______2.04_____0.00_____0.09__26
657207__646198______2.04_____0.00_____0.09__26
657205__646196______2.06_____0.01_____0.17__50
657206__646197___2939.35___438.17___255.66__52
657268__646259_____93.28_____9.55____11.26__72
657269__646260______3.06_____0.01_____0.37__73
657211__646202______2.06_____0.01_____0.25__73
657216__646207____150.39_____8.57____18.33__73
657212__646203______2.04_____0.01_____0.25__74
657210__646201______2.04_____0.01_____0.25__74
657273__646264___2915.89___505.35___376.28__77
657158__646149____148.41____11.55____20.56__83
657160__646151___3046.91___497.82___480.02__95

________________18548.67__3087.51__1565.47__51
11) Message boards : Number crunching : app reporting negative CPU (Message 355)
Posted 26 Feb 2012 by zombie67 [MM]
Post:
1) Don't know why a negative CPU is reported. The App doesn't do it.


Okay. That is just the message that BOINC is saying "app reporting negative CPU". But something is obviously wrong for BOINC to be saying that, right?

2) As I understand David, the CPU time is not used to calculate the creditnew. They use elapsed time.
yoyo


CreditNew has to account for the multiple CPUs somehow, right? Otherwise a machine using a single CPU for (say) 4 hours, vs. a machine using 4 CPUs for 4 hours, vs. a machine using 8 CPUs for 4 hours, all three would be awarded the same credit. So how are multiple CPUs accounted for with MT tasks, if not from the CPU time?
12) Message boards : Number crunching : app reporting negative CPU (Message 353)
Posted 26 Feb 2012 by zombie67 [MM]
Post:
I wonder if this is a clue for why the CPU time is so under-reported, which leads to credits being under awarded? Notice how small the CPU time is compared with the run time? This is with a 6 core machine, so CPU time *should* be ~5-6x the run time.

This is the task info:

http://yafu.dyndns.org/yafu/result.php?resultid=654613

Name yafu_C106_1330051806_419_0
Workunit 643624
Created 24 Feb 2012 | 2:51:10 UTC
Sent 25 Feb 2012 | 6:22:35 UTC
Received 26 Feb 2012 | 16:51:46 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 2681
Report deadline 27 Feb 2012 | 6:26:35 UTC
Run time 4,765.68
CPU time 82.13
Validate state Valid
Credit 100.80
Application version YAFU v128.09 (mt)
Stderr output

<core_client_version>6.10.58</core_client_version>
<![CDATA[
<stderr_txt>
wrapper: starting
06:47:25 (12256): wrapper: running yafu (-threads 6 -batchfile in)
wrapper: starting
07:24:33 (1494): wrapper: running yafu (-threads 6 -batchfile in)
08:44:00 (1494): called boinc_finish

</stderr_txt>
]]>


This is what the messages tab says:

Sun 26 Feb 2012 08:42:31 AM PST yafu Starting yafu_C105_1330175706_21_0
Sun 26 Feb 2012 08:42:31 AM PST yafu Starting task yafu_C105_1330175706_21_0 using yafu version 13001
Sun 26 Feb 2012 08:42:32 AM PST WUProp@Home Scheduler request completed
Sun 26 Feb 2012 08:42:34 AM PST yafu Computation for task yafu_C105_1330175706_21_0 finished
Sun 26 Feb 2012 08:42:34 AM PST yafu Resuming task yafu_C106_1330051806_419_0 using yafu version 12809
Sun 26 Feb 2012 08:42:35 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:36 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:36 AM PST yafu Started upload of yafu_C105_1330175706_21_0_0
Sun 26 Feb 2012 08:42:37 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:38 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:38 AM PST yafu Finished upload of yafu_C105_1330175706_21_0_0
Sun 26 Feb 2012 08:42:39 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:40 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:41 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:42 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:42 AM PST yafu Sending scheduler request: To report completed tasks.
Sun 26 Feb 2012 08:42:42 AM PST yafu Reporting 1 completed tasks, not requesting new tasks
Sun 26 Feb 2012 08:42:43 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:44 AM PST yafu app reporting negative CPU: -2635968999999999884779421740749610247433506762046125930441861782380097746292225020742886154727291863270878001955922142253977429607358744462498812625468118365885847172438872207944471058305006876168596907847179797486498265247898
Sun 26 Feb 2012 08:42:45 AM PST yafu Scheduler request completed
Sun 26 Feb 2012 08:44:02 AM PST yafu Computation for task yafu_C106_1330051806_419_0 finished

13) Message boards : News : Multithreaded App in Test (Message 342)
Posted 10 Feb 2012 by zombie67 [MM]
Post:
I have a question about the MT results.

In most cases*, the run time value is many times larger than the CPU time. That seems backwards to me.

Run time should equal wall clock time. And CPU time should equal actual CPU usage time. Usually with non-MT tasks, the run time will be slightly larger than the CPU time due to the CPU waiting for something or other. But with MT tasks, since you will have many CPUs running the task concurrently, the CPU time should be larger than the run time.

For example, say a task running for 100 seconds, across 8 CPUs. The run time should show as 100, and the CPU time should show as 800 (less any wait time). See what I mean? So why are the tasks showing the reverse?


*For a very few tasks, the values are reversed, where the CPU time is greater than the run time, like I would expect. But only a very few.


For the record, this is what times for an MP task should look like (run on a 4 core machine):

http://sim1.sytes.net/sim1//result.php?resultid=1247

Run time 5,599.25
CPU time 16,296.33

See? CPU time should be about 4x the Run time, and it is. So the YAFU tasks are report wrong times. And that is effecting credits (I believe). So can this please be fixed?
14) Message boards : Number crunching : need app_info.xml stuff for non-MT app (Message 330)
Posted 29 Jan 2012 by zombie67 [MM]
Post:
maybe an option in: Preferences for this project :to run mt or not run mt,
project T4T has it


That's interesting. DA said it was not possible.
15) Message boards : Number crunching : need app_info.xml stuff for non-MT app (Message 325)
Posted 27 Jan 2012 by zombie67 [MM]
Post:
Ah. Good to know.

And also, I forgot about the wrapper. I have no idea how to write an app_info file for that.

I don't suppose you (or anyone) would be willing to write one for me?

Pleeeease?
16) Message boards : Number crunching : need app_info.xml stuff for non-MT app (Message 323)
Posted 27 Jan 2012 by zombie67 [MM]
Post:
I would like to go back to using the non-MT app. I think the only way to do that is via anonymous platform. But in order to do that, you need to have all the application files. My machines have only the MT files any more. Where can the app files be downloaded from? TIA!
17) Message boards : News : Multithreaded App in Test (Message 322)
Posted 26 Jan 2012 by zombie67 [MM]
Post:
What about credit?
I finish a WU on a 8 cores (runtime near 1h30) and get credit as previous single core version running a WU for 1H30.

It should grant credit for 8*1h30 right?


Disclaimer: CreditNew awards credits in a very random manner.

That said, there is clearly something wrong, beyond CreditNew. We are getting awarded credits as if each task was using only one core. I think this might be tied to the problem with the run time vs. CPU time. And it is therefore throwing off the credit calculation.
18) Message boards : News : Multithreaded App in Test (Message 319)
Posted 25 Jan 2012 by zombie67 [MM]
Post:
I have a question about the MT results.

In most cases*, the run time value is many times larger than the CPU time. That seems backwards to me.

Run time should equal wall clock time. And CPU time should equal actual CPU usage time. Usually with non-MT tasks, the run time will be slightly larger than the CPU time due to the CPU waiting for something or other. But with MT tasks, since you will have many CPUs running the task concurrently, the CPU time should be larger than the run time.

For example, say a task running for 100 seconds, across 8 CPUs. The run time should show as 100, and the CPU time should show as 800 (less any wait time). See what I mean? So why are the tasks showing the reverse?


*For a very few tasks, the values are reversed, where the CPU time is greater than the run time, like I would expect. But only a very few.


Is this behavior correct/normal? Or is something wrong?
19) Message boards : News : Multithreaded App in Test (Message 307)
Posted 24 Jan 2012 by zombie67 [MM]
Post:
I have a question about the MT results.

In most cases*, the run time value is many times larger than the CPU time. That seems backwards to me.

Run time should equal wall clock time. And CPU time should equal actual CPU usage time. Usually with non-MT tasks, the run time will be slightly larger than the CPU time due to the CPU waiting for something or other. But with MT tasks, since you will have many CPUs running the task concurrently, the CPU time should be larger than the run time.

For example, say a task running for 100 seconds, across 8 CPUs. The run time should show as 100, and the CPU time should show as 800 (less any wait time). See what I mean? So why are the tasks showing the reverse?


*For a very few tasks, the values are reversed, where the CPU time is greater than the run time, like I would expect. But only a very few.
20) Message boards : News : Multithreaded App in Test (Message 303)
Posted 23 Jan 2012 by zombie67 [MM]
Post:
I see that mt has been deployed for all three types. How does one choose getting regular vs. mt?


Next 20




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