Workload trends

Graphics of 1 hour workload trends:


- trial factoring: essentially flat;

- PRP: irregular.
after roundoff error trend became worse like it is now.

[kriesel]

Originally Posted by SELROC

Graphics of 1 hour workload trends:

- trial factoring: essentially flat;

- PRP: irregular.
after roundoff error trend became worse like it is now.

Horizontal axes are time.

What are the units of the vertical axes?
On what computing device? software? (mfakto and gpuowl on RX580?)

[chalsall]

Originally Posted by kriesel

Horizontal axes are time. What are the units of the vertical axes?
On what computing device? software? (mfakto and gpuowl on RX580?)

Thank you!

Without defining both axis, with magnitudes, we have no idea what we're dealing with.

[kriesel]

Originally Posted by chalsall

Thank you!

Without defining both axis, with magnitudes, we have no idea what we're dealing with.

There's no escape from engineering school (with a diploma) without that concept and some commitment to completeness. We were taught to cancel units like they were variables in simplifying equations in algebra. A number without the associated units has little meaning.
(For example: I traveled over 6.28 AU last year, along with everyone else here. The nearest post office is almost a 6.28 mile round trip. Those distances are about 10⁸ to 1 away from being equal. Going to the dentist is about a 30 mile trip. Without the units, just comparing numbers lacking units, going to the dentist would seem further than the earth's annual orbit of Sol. It's many billions of Angstroms from where I am now to my refrigerator. Or less than 10 steps.)

Originally Posted by kriesel

Horizontal axes are time.

What are the units of the vertical axes?
On what computing device? software? (mfakto and gpuowl on RX580?)

The GPUs are not accounted for workload that way....


The two computations are being done on CPU with mprime.


The horizontal axis is time, the vertical axis is just "total workload" per machine.

Originally Posted by kriesel

There's no escape from engineering school (with a diploma) without that concept and some commitment to completeness. We were taught to cancel units like they were variables in simplifying equations in algebra. A number without the associated units has little meaning.
(For example: I traveled over 6.28 AU last year, along with everyone else here. The nearest post office is almost a 6.28 mile round trip. Those distances are about 10⁸ to 1 away from being equal. Going to the dentist is about a 30 mile trip. Without the units, just comparing numbers lacking units, going to the dentist would seem further than the earth's annual orbit of Sol. It's many billions of Angstroms from where I am now to my refrigerator. Or less than 10 steps.)

An engineering school can teach you to be an engineer but can't teach you to become smarter....

[kriesel]

Originally Posted by SELROC

The GPUs are not accounted for workload that way....
The two computations are being done on CPU with mprime.
The horizontal axis is time, the vertical axis is just "total workload" per machine.

"Total workload" = Linux sense of workload, on a multicore machine? Presumably a lot of cores, if you're getting 8 and 10.

https://scoutapp.com/blog/understanding-load-averages
The TF and PRP are running simultaneously? On the same system? What other activity is there on the machine(s)?
Save files for PRP or LL are much bigger (typ. 10 MB) than checkpoint files for TF (~53B). That might generate a periodic slowdown for PRP, when writing a new one.
The 3 slight bumps in TF appear to coincide with dips in PRP.
What else is happening on the PRP system?
I was reading prime95 code earlier tonight, and noted there's provision for some threads to suspend when memory becomes scarce. That's likely to show up as reduced % cpus utilization in Windows, or reduced load in linux. If a memory hungry application that might use little cpu is running, that might indirectly modulate mprime PRP load.

[kriesel]

Originally Posted by SELROC

An engineering school can teach you to be an engineer but can't teach you to become smarter....

Not sure who you're talking about there. It was a lot of fun to see which of the handful of other curve-busters would also be in the top 5 on engineering exams, especially in the make or break more challenging required classes. It didn't take long before we all knew each other by name. (Time though is the great equalizer. We all will end up at IQ 0.)

[kriesel]

Image attached is from a dual-E5645 Win7-x64 system, 4 prime95 workers 3 cores each, with a couple gpu tasks going and misc OS overhead activity, plus remote desktop, gpu-z times two. The GPU-Z sessions show maxed out 100% gpu load, but fluctuating memory controller load. I think it interesting there are 3 cpu cores with almost 100% utilization, and the others fluctuate a lot. Time period covered by the 12 little graphs is ~2 minutes.
I don't run TF on cpus, as that's not an effective use of cpus that could be doing PRP or LL.
But it might make an interesting comparison test.

Originally Posted by kriesel

"Total workload" = Linux sense of workload, on a multicore machine? Presumably a lot of cores, if you're getting 8 and 10.

https://scoutapp.com/blog/understanding-load-averages
The TF and PRP are running simultaneously? On the same system? What other activity is there on the machine(s)?
Save files for PRP or LL are much bigger (typ. 10 MB) than checkpoint files for TF (~53B). That might generate a periodic slowdown for PRP, when writing a new one.
The 3 slight bumps in TF appear to coincide with dips in PRP.
What else is happening on the PRP system?
I was reading prime95 code earlier tonight, and noted there's provision for some threads to suspend when memory becomes scarce. That's likely to show up as reduced % cpus utilization in Windows, or reduced load in linux. If a memory hungry application that might use little cpu is running, that might indirectly modulate mprime PRP load.

It should be clear from the two graphics that there are two machines, one running trial factoring and one running prp.

Originally Posted by kriesel

"Total workload" = Linux sense of workload, on a multicore machine? Presumably a lot of cores, if you're getting 8 and 10.

https://scoutapp.com/blog/understanding-load-averages
The TF and PRP are running simultaneously? On the same system? What other activity is there on the machine(s)?
Save files for PRP or LL are much bigger (typ. 10 MB) than checkpoint files for TF (~53B). That might generate a periodic slowdown for PRP, when writing a new one.
The 3 slight bumps in TF appear to coincide with dips in PRP.
What else is happening on the PRP system?
I was reading prime95 code earlier tonight, and noted there's provision for some threads to suspend when memory becomes scarce. That's likely to show up as reduced % cpus utilization in Windows, or reduced load in linux. If a memory hungry application that might use little cpu is running, that might indirectly modulate mprime PRP load.

Originally Posted by SELROC

It should be clear from the two graphics that there are two machines, one running trial factoring and one running prp.

My GIMPS systems are all dedicated systems, no other application is running.
I don't think of scarcity of memory, TF system has 4GB RAM, PRP system has 32GB RAM.