mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2020-07-19, 16:18   #551
kruoli
 
kruoli's Avatar
 
"Oliver"
Sep 2017
Porta Westfalica, DE

32·37 Posts
Default

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.
kruoli is online now   Reply With Quote
Old 2020-07-19, 17:18   #552
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

31×149 Posts
Default

Quote:
Originally Posted by kruoli View Post
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.
Attached Thumbnails
Click image for larger version

Name:	ostrich-cold-system-restart.png
Views:	40
Size:	61.7 KB
ID:	22830  
kriesel is offline   Reply With Quote
Old 2020-07-19, 18:21   #553
kruoli
 
kruoli's Avatar
 
"Oliver"
Sep 2017
Porta Westfalica, DE

32·37 Posts
Default

If the timings are changing this much, I'll admit that NUMA is at least not the only cause.
kruoli is online now   Reply With Quote
Old 2020-07-20, 03:58   #554
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

31·149 Posts
Default

Quote:
Originally Posted by kruoli View Post
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%.
kriesel is offline   Reply With Quote
Old 2020-07-24, 23:45   #555
pepi37
 
pepi37's Avatar
 
Dec 2011
After milion nines:)

134810 Posts
Default

Quote:
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
pepi37 is offline   Reply With Quote
Old 2020-07-27, 00:22   #556
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

31×149 Posts
Default

Quote:
Originally Posted by kriesel View Post
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.

Last fiddled with by kriesel on 2020-07-27 at 00:28
kriesel is offline   Reply With Quote
Old 2020-07-28, 13:55   #557
kotenok2000
 
Mar 2018

23 Posts
Default Ui problem

When i test ecm stage 2 window header does not update
Attached Thumbnails
Click image for larger version

Name:	Снимок экрана (58).png
Views:	36
Size:	120.6 KB
ID:	22906  
kotenok2000 is offline   Reply With Quote
Old 2020-07-28, 14:03   #558
rainchill
 
Apr 2005
DFW, tx

2·3·5 Posts
Default

I've had various issues with title bar headers not updating properly or being in the main communication window like you have too.
rainchill is offline   Reply With Quote
Old 2020-08-02, 20:38   #559
R. Gerbicz
 
R. Gerbicz's Avatar
 
"Robert Gerbicz"
Oct 2005
Hungary

17×83 Posts
Default

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?

Last fiddled with by R. Gerbicz on 2020-08-02 at 20:39 Reason: small typo
R. Gerbicz is offline   Reply With Quote
Old 2020-08-02, 21:14   #560
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

55 Posts
Default

Quote:
Originally Posted by R. Gerbicz View Post
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.
James Heinrich is offline   Reply With Quote
Old 2020-08-03, 07:12   #561
preda
 
preda's Avatar
 
"Mihai Preda"
Apr 2015

24138 Posts
Default

Quote:
Originally Posted by R. Gerbicz View Post
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)

Last fiddled with by preda on 2020-08-03 at 07:14
preda is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Prime95 version 29.2 Prime95 Software 71 2017-09-16 16:55
Prime95 version 29.1 Prime95 Software 95 2017-08-22 22:46
Prime95 version 26.5 Prime95 Software 175 2011-04-04 22:35
Prime95 version 25.9 Prime95 Software 143 2010-01-05 22:53
Prime95 version 25.8 Prime95 Software 159 2009-09-21 16:30

All times are UTC. The time now is 12:08.

Tue Oct 27 12:08:52 UTC 2020 up 47 days, 9:19, 0 users, load averages: 1.66, 1.89, 1.83

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.