Running P95 v29.4, Win 7 Pro.
Lately I have started seeing P95 print multiple status lines for the same assignment. See screen grab.

[QUOTE=kladner;471478]Running P95 v29.4, Win 7 Pro.
Lately I have started seeing P95 print multiple status lines for the same assignment. See screen grab.[/QUOTE]

Build 4?

I suspect it is a collection of interim residues sent to the server every 5,000,000 iterations.

[QUOTE=Prime95;471491]Build 4?

I suspect it is a collection of interim residues sent to the server every 5,000,000 iterations.[/QUOTE]
OK. Cool. Thanks!

[QUOTE=Prime95;471373]Build 4 now ready. Let me know what I screwed up - the release builds are not a "push button" process.[/QUOTE]

For reference, SHA256 on the new buidls:
[CODE]
p95v294b4.FreeBSD11-64.tar.gz - 7AAF9447F8683F53B482BBAA67C9D2016CE4D449BCBCCF6936A8DE3A4E1795B5
p95v294b4.linux32.tar.gz - 1C3092861FB2B47E7DBAFCDD1D176EC38AEBB05E743104DCA0BEA1B94EA73571
p95v294b4.linux64.tar.gz - 5F5EF2A268C8683347ED4E7F1CF7C774C7EC1B295E6DE56AFC1A43DD7750979B
p95v294b4.MacOSX.zip - D50D6B5DFB1A208449B96A41F0639E15F9BBFFAAA00F2FD0AAA9FF84C6031F05
p95v294b4.source.zip - 130B7AE3F12EC0FE6317D287E952A7C23109FEB3E776C8E44AACAE9B4DA9BFCE
p95v294b4.win32.zip - 0188E36B22E4554DB6959BFCF1A2D3881CDF70A869AC45AC4C62A0F6EF5BED5D
p95v294b4.win64.zip - B9659D26827F14ED7EBF76A9089BED9BEC5D1A46621DCB92094DD1F2B5312D0C[/CODE]

[QUOTE=Prime95;471491]Build 4?

I suspect it is a collection of interim residues sent to the server every 5,000,000 iterations.[/QUOTE]
Oops. It is 29.4B3. I'll have to update.

Still some issues in relation to interim residues output
 

The errors I reported previously have been corrected with the latest version. There are still some cosmetic output issues : on both Linux and Windows the lines about sending the interim results are not ended by end of line characters. This concerns the communication thread and the log file.

Then it seems the interim residues are not always sent when produced, but at communication time. Perhaps this is by design.

On a linux machine where I run two workers the screen output is every 350000 iterations while it is set at 500000 in the settings. Difficult to say if this happened with older versions of the program : that window output is lost :-) One worker does 42M double checks, the other P-1 and "ScaleOutputFrequency" is set to 1 in prime.txt.

In the attched log and output files I prefixed the "offending" lines with "+++ ".

Jacob

[QUOTE=S485122;471537]
Jacob

[Worker #2 Nov 9 18:50] Optimal P-1 factoring of M12345678 using up to 30000MB of memory.
[Worker #2 Nov 9 18:50] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.[/QUOTE]

I could save both of them, M12345678 is clearly composite.

[QUOTE=R. Gerbicz;471540]I could save both of them, M12345678 is clearly composite.[/QUOTE]I replaced all the AID's of the workunits with the string "AID" and the exponents with 12345678 ... Some people get nervous when they see active assigments data on the forum :-)

Jacob

Is there a setting to configure the number of seconds for "Waiting ([b]5 * workernumber[/b]) seconds to stagger worker starts"?

[strike]No, I can add one for build 5: "StaggerSeconds"[/strike]

Yes, it is called "StaggerStarts".

[QUOTE=Prime95;471583]Yes, it is called "StaggerStarts"[/QUOTE]Ah, thanks. Quoting from undoc.txt for reference:[quote]Some machines report much better timings if the worker threads stagger their starts. This was first noticed on Core i7 machines running Windows. Presumably staggering starts improves timings due to each worker allocating contiguous memory. You can control how long the program waits between starting each worker. In prime.txt, enter:
[FONT="Courier New"][COLOR="Blue"]StaggerStarts=n[/COLOR][/FONT]
where n is the number of seconds to wait. The default is 5 seconds.[/quote]