[quote=Prime95;126505]An exponent is not considered double-checked until a different shift count is selected by prime95. Thus, there is a 1 in 20 million chance that a double-check assignment will result in wasted work (the same shift count as the first LL test is chosen).[/quote]
NB 20 million ~ current exponent of a double check.

Hey, I'm looking to try out the new version, but I can't email Prime95 to get the "secret line" to add to prime.txt. What do I do?

[b]Prime95[/b], could you make a static build of mprime v25.6? Thanks in advance.

ZAmodeo, send him a PM.

worktodo.txt needs to get cleaned up after reducing number of worker threads. Now you get an error message about too many workers in worktodo.txt and it is impossible to unreserve work allocated to removed threads. A soloution could be to share work which is already started between the remaining threads and unreserve the rest.

Also I think that work added through a worktodo.add file with no specific Worker sections should get evenly divided between workers. When one worker thread finishes with no more work left, it should also take a line from another worker unless configured not to. I.e if you only want to limit LL to one thread and let other processes have some memory bus bandwith and cache.

An unrelated enhacement request when I'm at it: This weekend one of my 25.6 test machines ran out of ECM work while not connected to the net. When I got to it on monday, it idled. Wouldn't it be better to just continue running ECM curves on the same exponent with the same B1 until it got back on internet? A few more ECM curves never hurt. The same goes for factoring. A level further will not do any harm. And for P-1 if the residue from step 1 is saved and it is possible to continue to a higher B1. An option to do this, perhaps?

[QUOTE=S00113;127804]When one worker thread finishes with no more work left, it should also take a line from another worker unless configured not to...

Wouldn't it be better to just continue running ECM curves on the same exponent with the same B1 until it got back on internet? A few more ECM curves never hurt. The same goes for factoring.... And for P-1...[/QUOTE]:goodposting: I've been [url=http://www.mersenneforum.org/showpost.php?p=116023&postcount=92]asking for this[/url] for (what seems like years) months... My idea was just to steal work from another worker's worktodo, but factoring to another bitdepth or similar as proposed above is a great idea too. Please, George, please :cool:

mprime 25.6 hangs if you start it with a pending prime.add file. It looks like a locking problem.

iniAddFileMerge locks INI_MUTEX and call IniSectionWriteString, which tries to lock INI_MUTEX again => hang.

"Mxxxxxxxx stage 2 is 100% complete" (misleading)
 

In P-1 stage 2 after a couple threads negotiate memory for each thread - the "Mxxxxxxxx stage 2 is 100% complete" starts to appear too soon in the worker thread window. Or some other value higher than the real progress is shown. The proper progress is seen from the intervening lines
"Using 280Mb of memory. Processing 8 relative primes (426 of 480 already processed)".

It is not a critical bug, because it is not a criterion to stop, just a misleading progress line.

(( In ecm.c, line 4652 there's " state.pairs_done++; "
but there's no correction to lower value if the thread is restarted with a different allocated memory. ))

[QUOTE=S00113;128012]mprime 25.6 hangs if you start it with a pending prime.add file. It looks like a locking problem.

iniAddFileMerge locks INI_MUTEX and call IniSectionWriteString, which tries to lock INI_MUTEX again => hang.[/QUOTE]

Thanks for debugging this. Windows locking does not hang. I've coded up a fix. You'll see it next time I upload an executable.

Another suggestion:

Benchmark should test for memory bus congestion when running n LL threads on a multi-core CPU. First run one thread of LL and n-1 of trial factoring. Then switch to two threads running LL on different exponents and n-2 trial factoring. Continue until LL speed is falling or all n threads run LL. Mark when LL speed drops, and tell the user and the server ho many LL threads can be run without worrying about memory bus congestion. The server can use this information when choosing default work for each thread.

Another suggestion: Some computers clock down when the CPU is idle, and automatically increase clock speed when it's needed. (AMD Cool and quiet or something.) mprime should update the CPU speed while working, not while idling just after startup.