Prime95 version 29.3 - Page 2

Prime95 · 2017-09-09, 03:10

I'm betting the cause is the 12-hour Jacobi timer and 30-minute save file timer fired at roughly the same time. Both of them will create a save file.

I'm not sure what to do about that, I'll think on it.

GP2 · 2017-09-09, 04:39

Quote:

Originally Posted by Madpoo

The timestamps of the main and .bu are identical... did mprime stop right after making that first backup, making it write out a new main save file that was almost the same iteration?

Or anything else that might have stopped mprime and kicked it off again (some task you have running that monitors/restarts stuff?)

No, mprime was running continuously the whole time. It only starts automatically at boot time, and the uptime was much longer than the time since that timestamp.

GP2 · 2017-09-09, 04:56

Quote:

Originally Posted by Prime95

I'm betting the cause is the 12-hour Jacobi timer and 30-minute save file timer fired at roughly the same time. Both of them will create a save file.

I'm not sure what to do about that, I'll think on it.

A few hours later, the savefiles in question look like this:

Code:

p81419599: [Sep 09 04:11] LL (mprime): 2014496 / 81419599 [2.47%]
p81419599.bu: [Sep 09 03:41] LL (mprime): 1877683 / 81419599 [2.31%]
p81419599.bu2: [Sep 09 03:11] LL (mprime): 1740860 / 81419599 [2.14%]
p81419599.bu3: [Sep 09 00:12] LL (mprime): 922855 / 81419599 [1.13%]

Code:

p82062787: [Sep 09 04:31] LL (mprime): 24609328 / 82062787 [29.99%]
p82062787.bu: [Sep 09 04:21] LL (mprime): 24562904 / 82062787 [29.93%]
p82062787.bu2: [Sep 09 04:11] LL (mprime): 24516461 / 82062787 [29.88%]
p82062787.bu3: [Sep 09 00:12] LL (mprime): 23405854 / 82062787 [28.52%]
p82062787.bu4: [Sep 08 12:07] LL (mprime): 20072393 / 82062787 [24.46%]

Note, for no particular reason, the first instance uses a DiskWriteTime of 30 minutes and the second one uses 10 minutes.

So we see that the traditional three save files (no suffix, .bu, and .bu2) are separated by intervals of DiskWriteTime, whereas the .bu3 and higher seem to linger longer, and have timestamps separated by 12 hours from one another if there is more than one of them.

In each case, one of the two savefiles with a matching timestamp disappeared and the other remained. So probably one of them was created by the 12-hour Jacobi timer and the other by the DiskWriteTime-interval timer, as you surmised.

In the other three cases, it seems that only the Jacobi timer wrote a savefile at that particular point in time (Sept 9 00:12 UTC, or in one case, at Sep 08 23:43):

Code:

p26S2579: [Sep 09 04:43] LL (mprime): 4702545 / 78262579 [6.01%]
p26S2579.bu: [Sep 09 04:33] LL (mprime): 4656412 / 78262579 [5.95%]
p26S2579.bu2: [Sep 09 04:23] LL (mprime): 4610259 / 78262579 [5.89%]
p26S2579.bu3: [Sep 08 23:43] LL (mprime): 3321337 / 78262579 [4.24%]

Code:

p81471113: [Sep 09 04:41] LL (mprime): 28813951 / 81471113 [35.37%]
p81471113.bu: [Sep 09 04:31] LL (mprime): 28768075 / 81471113 [35.31%]
p81471113.bu2: [Sep 09 04:21] LL (mprime): 28722214 / 81471113 [35.25%]
p81471113.bu3: [Sep 09 00:12] LL (mprime): 27578749 / 81471113 [33.85%]
p81471113.bu4: [Sep 08 12:08] LL (mprime): 24285228 / 81471113 [29.81%]

Code:

p28S7887: [Sep 09 04:51] LL (mprime): 67752399 / 78287887 [86.54%]
p28S7887.bu: [Sep 09 04:41] LL (mprime): 67708486 / 78287887 [86.49%]
p28S7887.bu2: [Sep 09 04:31] LL (mprime): 67664630 / 78287887 [86.43%]
p28S7887.bu3: [Sep 09 00:12] LL (mprime): 66526121 / 78287887 [84.98%]
p28S7887.bu4: [Sep 08 12:09] LL (mprime): 63372973 / 78287887 [80.95%]

These all use a DiskWriteTime of 10 minutes.

Prime95 · 2017-09-09, 19:17

Quote:

Originally Posted by GP2

So we see that the traditional three save files (no suffix, .bu, and .bu2) are separated by intervals of DiskWriteTime, whereas the .bu3 and higher seem to linger longer, and have timestamps separated by 12 hours from one another if there is more than one of them.

Correct. Plain, .bu, .bu2 are the save files we are familiar with. .bu3 and .bu4 contains data that passed a Jacobi error check.

I'm going to change the meaning of the 12-hour JacobiError timer. Instead of meaning "error check and write save file now" it will mean "run an error check before writing the next save file". Not a big difference.

S485122 · 2017-09-10, 22:32

The Jacobi test does nor run just twice per 24 hours, it also runs at each start of the program.

Jacob

Prime95 · 2017-09-10, 23:44

Quote:

Originally Posted by S485122

The Jacobi test does nor run just twice per 24 hours, it also runs at each start of the program.

Correct. It is done to validate the save file.

The test is also done after the last LL iteration to make sure we send higher quality results to the server.

ATH · 2017-09-11, 20:11

29.3 have the same problem for me as 29.2, I guess my computer does not work well with hwloc. After 5+ benchmarks at 4M FFT, the performance is about the same (almost) as 28.9. But starting just 1 thread of something else makes performance drop a lot, several times what it should from that one thread, and it is not constant performance, the speed varies a lot. Any chance the old way of running the threads could be left in as an option in undoc.txt?

I hope it is just my computer and other people does not have this problem without realizing it, because then using your computer for other things while running Prime95 will hurt performance a lot.

Prime95 · 2017-09-11, 21:18

Quote:

Originally Posted by ATH

29.3 have the same problem for me as 29.2, I guess my computer does not work well with hwloc.

Very strange. Have you tried changing each worker to "run on any core" using the Affinity= option in undoc.txt.

ATH · 2017-09-12, 17:55

"EnableSetAffinity=0" actually solved all my problems. Now 29.3 runs as good as 28.9 with and without extra applications. What does EnableSetAffinity=0 actually do?

And what does EnableSetPriority=0 do? It seems to set priority of Prime95 to Normal instead of Idle? I'm going to leave it at EnableSetPriority=1.

Btw, did you find a way to use the Jacobi check on normal LL tests not just 3-PRP tests? Because it is running Jacobi test in 29.3 on a normal "Test=" worktodo.txt line, or are all tests now 3-PRP tests instead of actual LL tests?

Prime95 · 2017-09-12, 18:52

EnableSetAffinity=0 disables all attempts at setting affinity. Essentially this is equivalent to "run on any core".

Jacobi error checks are for LL tests. This is implemented 29.3.

Gerbicz error checks are for PRP tests. This is not implemented yet.

pepi37 · 2017-09-12, 22:31

I noticed one cosmetic error
At the end of PRP test always was We4, but now is Wf4

2017-09-11, 20:11	#18
ATH Einyen Dec 2003 Denmark 2·1,579 Posts	29.3 have the same problem for me as 29.2, I guess my computer does not work well with hwloc. After 5+ benchmarks at 4M FFT, the performance is about the same (almost) as 28.9. But starting just 1 thread of something else makes performance drop a lot, several times what it should from that one thread, and it is not constant performance, the speed varies a lot. Any chance the old way of running the threads could be left in as an option in undoc.txt? I hope it is just my computer and other people does not have this problem without realizing it, because then using your computer for other things while running Prime95 will hurt performance a lot. Last fiddled with by ATH on 2017-09-11 at 20:16

2017-09-12, 17:55	#20
ATH Einyen Dec 2003 Denmark 110001010110₂ Posts	"EnableSetAffinity=0" actually solved all my problems. Now 29.3 runs as good as 28.9 with and without extra applications. What does EnableSetAffinity=0 actually do? And what does EnableSetPriority=0 do? It seems to set priority of Prime95 to Normal instead of Idle? I'm going to leave it at EnableSetPriority=1. Btw, did you find a way to use the Jacobi check on normal LL tests not just 3-PRP tests? Because it is running Jacobi test in 29.3 on a normal "Test=" worktodo.txt line, or are all tests now 3-PRP tests instead of actual LL tests? Last fiddled with by ATH on 2017-09-12 at 17:56

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Prime95 version 27.3	Prime95	Software	148	2012-03-18 19:24
Prime95 version 26.3	Prime95	Software	76	2010-12-11 00:11
Prime95 version 25.5	Prime95	PrimeNet	369	2008-02-26 05:21
Prime95 version 25.4	Prime95	PrimeNet	143	2007-09-24 21:01
When the next prime95 version ?	pacionet	Software	74	2006-12-07 20:30

2017-09-09, 03:10	#12
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 5·11·137 Posts	I'm betting the cause is the 12-hour Jacobi timer and 30-minute save file timer fired at roughly the same time. Both of them will create a save file. I'm not sure what to do about that, I'll think on it.

2017-09-10, 22:32	#16
S485122 Sep 2006 Brussels, Belgium 1701₁₀ Posts	The Jacobi test does nor run just twice per 24 hours, it also runs at each start of the program. Jacob

2017-09-12, 18:52	#21
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 5·11·137 Posts	EnableSetAffinity=0 disables all attempts at setting affinity. Essentially this is equivalent to "run on any core". Jacobi error checks are for LL tests. This is implemented 29.3. Gerbicz error checks are for PRP tests. This is not implemented yet.

2017-09-12, 22:31	#22
pepi37 Dec 2011 After milion nines:) 10110101011₂ Posts	I noticed one cosmetic error At the end of PRP test always was We4, but now is Wf4