Prime95 version 29.6/29.7/29.8

[kruoli]

That's most likely because of NUMA. I see something similar on my 1950X, since it has two NUMA nodes.

Prime95 starts on a single NUMA node and allocates all the memory on the same node, it seems.

[kriesel]

Originally Posted by kruoli

That's most likely because of NUMA.

The disparity I posted previously is not normal. It's occasional, and relatively new. Worker 1 is the first to start; #2 the second, etc, staged by 15 seconds or so, so that they get contiguous memory allocated. After a complete system shutdown, ~2 hour dwell off, and restart, things are at least initially close to normal. Oddly though, worker 1, which is the only one with an 8M fft length is running a bit slower at 32ms/iteration. But nowhere near the 4.65:1 disparity shown in my previous post for the same system, same prime95 folder and version, same exponents and workers, most of which are running at 8960K fft.

[kruoli]

If the timings are changing this much, I'll admit that NUMA is at least not the only cause.

[kriesel]

Originally Posted by kruoli

If the timings are changing this much, I'll admit that NUMA is at least not the only cause.

It's an aged-hardware issue. The system is an HP Z820 dual-Xeon-e5-2690 running Win 10 Pro on 64GB. One Xeon was found running at 84 watts, the other at 41, using HWMonitor, and Task Manager showed only 24% cpu usage. I downed it again, removed the cpu/ram fans assembly, and found the cpu heat exchangers rather dusty. After a good brush/vacuuming, one is back up to the full 134W, the other is at about 60W. I suspect a bad cpu fan also. Timings on all 4 workers improved. Prime95 is using 36% of cpu. It should be reaching ~50%.

[pepi37]

You can change the interval between outputs of the timestamp to the results.txt file
ResultsFileTimestampInterval=0
If n is zero, the timestamp will never be output In results.txt file

[Sat Jul 25 01:10:55 2020]
Iteration 200000 / 1805675
Iteration 400000 / 1805675
Iteration 600000 / 1805675
Iteration 800000 / 1805675


Latest prime95 on Windows

[kriesel]

Originally Posted by kriesel

It's an aged-hardware issue. The system is an HP Z820 dual-Xeon-e5-2690 running Win 10 Pro on 64GB. One Xeon was found running at 84 watts, the other at 41, using HWMonitor, and Task Manager showed only 24% cpu usage. I downed it again, removed the cpu/ram fans assembly, and found the cpu heat exchangers rather dusty. After a good brush/vacuuming, one is back up to the full 134W, the other is at about 60W. I suspect a bad cpu fan also. Timings on all 4 workers improved. Prime95 is using 36% of cpu. It should be reaching ~50%.

A replacement fan did not help. Successive rounds of compressed air (a whole pancake-compressor tank at a time, after allowing for condensate etc to settle out) and retest raised the front Xeon's wattage by stages, to 90, 115, now full 134W, but it's still running ~10C warmer than the back Xeon. Task Manager shows cpu load back to 51%. HwMonitor shows the warmer Xeon running 2.9Ghz, the other 3.0. The ms/iter values of the 4 workers are looking good. For comparison to post 552's attachment, 18, 22, 21, 21 ms / iter. And before the cleanout, it was a lot worse at thermal equilibrium than 552's figures at resumption show.

So, count it as one more practical application for prime95: identifying when the system internals need a good dusting off. Onward, to another lagging system next.

[kotenok2000]

When i test ecm stage 2 window header does not update

[rainchill]

I've had various issues with title bar headers not updating properly or being in the main communication window like you have too.

[R. Gerbicz]

With the new version we could lower the trial factoring limit for all p by roughly one bit, as you'd do only one prp test with a quick proof instead of two tests. Any thoughts?

[James Heinrich]

Originally Posted by R. Gerbicz

With the new version we could lower the trial factoring limit for all p by roughly one bit, as you'd do only one prp test with a quick proof instead of two tests. Any thoughts?

It's been discussed a bit (e.g. GPU72 thread) and yes, if and when this becomes adopted as the primary method used by GIMPS then the target TF level drops by one bitlevel. I'm not sure how quickly we could expect the bulk of the GIMPS population to switch from LL to PRP+Cert, there's probably a fairly large base of set-and-forget installations. Personally I would suggest that once the new test becomes widely available then wavefront new tests should only be handed out to PRP+Cert capable clients, the older installs can clean up the LL DC work; if they want to work on "new" exponents then they should upgrade their software. My opinion anyways.

[preda]

Originally Posted by R. Gerbicz

With the new version we could lower the trial factoring limit for all p by roughly one bit, as you'd do only one prp test with a quick proof instead of two tests. Any thoughts?

P-1 bounds getting lower too. A pity, I liked P-1 :)

(I always thought P-1 is so much more beautiful than TF :), but TF is done early to high-bits and too little opportunity is left for P-1)