I test now a Windows 32bit multi threaded application. It uses as many cores as your system has. This is a preparation for composites with more digits.

I test now a Windows 32bit multi threaded application. It uses as many cores as your system has. This is a preparation for composites with more digits.

Great news! If successful, will you offer 64 bit versions too?

Edit: Will the 32bit MT app be issued to 64 bit win machines? I have only 64 bit win machines, and I have beta turned on. But I don't have any MT tasks yet.

---

Reno, NV
Team: SETI.USA

I will deploy also a win 64 mt app if the 32 bit version runs well.
yoyo

I tested the app and got the same error like the "normal" app under x86.

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

app exit status: 0xc0000374.

Regards Odi

---

Running 1 instance each of YAFU on a AMD Phenom X6 and an AMD Phenom X4.

Though not finished yet both are running at 100% using all available cores, so far so good.
Waiting to see how the WU finishes.

Conan

---

I see that mt has been deployed for all three types. How does one choose getting regular vs. mt?

---

Reno, NV
Team: SETI.USA

I see that mt has been deployed for all three types. How does one choose getting regular vs. mt?

I have Test Work allowed in my preferences, and when I request work I get MT types.
Of the couple I have run on both of my computers they have run well with no problems and completed and validated.

I was curious as to why the second of my WUs on my Phenom X4 (Windows), ran longer than the first WU but was awarded half the credit.
other than that all ran OK.

Conan

---

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.

---

Reno, NV
Team: SETI.USA

I test now a Windows 32bit multi threaded application. It uses as many cores as your system has. This is a preparation for composites with more digits.

I have set use at most 87.5% of the cores. That is 7 of 8 to have 1 core free.
The mt app is taking all 8cores.

And 1 question.

How much memory is the app using at the most when using 8cores?

---

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?

---

Reno, NV
Team: SETI.USA

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?

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.

---

Reno, NV
Team: SETI.USA

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?

---

Reno, NV
Team: SETI.USA

I can agree. I run yafu and BURP on the same machine. On a 8core machine CPU-time at BURP is around 7x higher then runtime, here at yafu CPU time is only half of runtime.

I also wondered about the boinctasks display of CPU usage. The yafu app only shows around 10% CPU usage, althrough the cores were fully used.

Regards Odi

---