[QUOTE=kriesel;502358]In v5.0-5c13870, at least if doing PRP (no P-1), result lines output to the results.txt file seem to be lacking the trailing \n and so append onto a single run-on record.[/QUOTE]

By looking at the source, it seems to me that at least one '\n' should be there. It is possible that this is not working correctly on Windows, where the editor may expect \r\n (depending on editor). Are you sure there is not any '\n'?

And, interestingly, I couldn't find commit 5c13870, I don't know why..

[QUOTE=preda;502368]By looking at the source, it seems to me that at least one '\n' should be there. It is possible that this is not working correctly on Windows, where the editor may expect \r\n (depending on editor). Are you sure there is not any '\n'?

And, interestingly, I couldn't find commit 5c13870, I don't know why..[/QUOTE]


That's a decade-old problem, maybe older than that, of end-of-line characters translation between Windows and Linux, the standard Windows editor Notepad does not understand the difference, and paragraphs will appear as a long continuous line. One editor that understands the difference is Notepad++.

[QUOTE=preda;502368]By looking at the source, it seems to me that at least one '\n' should be there. It is possible that this is not working correctly on Windows, where the editor may expect \r\n (depending on editor). Are you sure there is not any '\n'?

And, interestingly, I couldn't find commit 5c13870, I don't know why..[/QUOTE]




I cannot find it also...

[QUOTE=preda;502368]By looking at the source, it seems to me that at least one '\n' should be there. It is possible that this is not working correctly on Windows, where the editor may expect \r\n (depending on editor). Are you sure there is not any '\n'?

And, interestingly, I couldn't find commit 5c13870, I don't know why..[/QUOTE]
Sorry; [B]9[/B]c13870.
Observed on Windows, with default editor Notepad; Wordpad finds a separator.
Free hex editor Frhed shows hex 0a (LF).

[QUOTE=kriesel;502393]Sorry; [B]9[/B]c13870.
Observed on Windows, with default editor Notepad; Wordpad finds a separator.
Free hex editor Frhed shows hex 0a (LF).[/QUOTE]


LF is \n = Line Feed aka newline
CR is \r = Carriage Return


[url]https://en.wikipedia.org/wiki/Newline#History[/url]

All known Mersenne primes Mp above p=132049 were run on gpuowl v5.0-9c13870, and run times tabulated and graphed. Fit for run time at exponents near the current wavefront is p[SUP]1.82[/SUP], a lower power than expected from asymptotic fft multiplication time n ln n ln ln n times number of iterations n. See [url]https://www.mersenneforum.org/showpost.php?p=502776&postcount=10[/url]

[QUOTE=kriesel;504039]All known Mersenne primes Mp above p=132049 were run on gpuowl v5.0-9c13870, and run times tabulated and graphed. Fit for run time at exponents near the current wavefront is p[SUP]1.82[/SUP], a lower power than expected from asymptotic fft multiplication time n ln n ln ln n times number of iterations n. See [url]https://www.mersenneforum.org/showpost.php?p=502776&postcount=10[/url][/QUOTE]

Thank you Ken!

I know I didn't get around to apply some of the changes you suggested -- I've been busy with other external things recently. But I still plan to follow through when I get a moment.

From what I remember:
- documentation
- better way to specify FFT size
- makefile small changes to better support windows or mingw
- display FFT list on -h without starting

and probably a few more.

[QUOTE=preda;504043]Thank you Ken!

I know I didn't get around to apply some of the changes you suggested -- I've been busy with other external things recently. But I still plan to follow through when I get a moment.

From what I remember:
- documentation
- better way to specify FFT size
- makefile small changes to better support windows or mingw
- display FFT list on -h without starting

and probably a few more.[/QUOTE]You're welcome. The outcome of no false negatives and no logged errors was encouraging.

I would add conditional compilation, so \r\n could be there for log and result entries for Windows builds. Beyond that, I'd need to refer to the equivalent of [URL]https://www.mersenneforum.org/showpost.php?p=488537&postcount=3[/URL] myself. A quick look indicates it's gotten multiple versions and months out of date. So see also forum thread content.

Something I've considered lately is making a table of interim residues, perhaps approx half way through, per known Mp. I'm keeping the gpuowl logs indefinitely.
I have a PRP-1 running on a current wavefront exponent in 5.0-9c13870 currently; ETA late Dec 30.

After that I'll probably switch the RX480 back to V3.8 and production PRP.

[QUOTE=preda;504043]Thank you Ken!

I know I didn't get around to apply some of the changes you suggested -- I've been busy with other external things recently. But I still plan to follow through when I get a moment.

From what I remember:
- documentation
- better way to specify FFT size
- makefile small changes to better support windows or mingw
- display FFT list on -h without starting

and probably a few more.[/QUOTE]
I've updated the spreadsheet and posted an updated pdf at [URL]https://www.mersenneforum.org/showpost.php?p=488537&postcount=3[/URL]
Happy (and perhaps busy) New Year!

GpuOwl simple primenet integration
 

I added a primenet.py script to GpuOwl, inspired from the mlucas-primenet.py of Mlucas.

[url]https://github.com/preda/gpuowl/blob/master/primenet.py[/url]

It's a 100 lines python script intended to run in the background. It wants to run in the same folder as a gpuOwl instance. It works with these files in that folder:

results.txt : reads results from this file new results
sent.txt : appends processed results here
retry.txt : appends results that were not accepted by the server here
worktodo.txt : reads this file to see how many assignment are active. If less than 2 assignments (i.e. the current and the next), retrieves and appends a new assignment.

How to run, with different ways of passing the primenet password in:

cd gpuowl

./primenet.py -u user -p password
echo password | ./primenet.py -u user
./primenet.py -u user < pass.txt

By default it wakes up every hour, to check if there is work to do.
Work can be:
- a new result is present in results.txt that was not sent to the server previously.
- the number of tasks it worktodo.txt dropped below 2, new tasks need fetching

GpuOwl v6
 

In recent updates to GpuOwl I dropped the PRP-1 feature (which allowed to do a normal P-1 first-stage before the PRP, and a P-1 second-stage in parallel with the PRP).

This was because:
- most exponents at the wavefront (all?) already have TF to high bits and some P-1 already done.
- even without any P-1 done, the rate of factors found by PRP-1 is not huge, let's say about 5% depending on the level of TF

Thus the benefit of PRP-1 was marginal. To make useful use of it, it would need to be run on larger exponents (not at wavefront), that have no P-1 and lower TF.

Dropping PRP-1 removes the dependency on the GMP library.

If anybody has PRP-1 work ongoing (i.e. with B1 != 0), they should finish it before upgrading because GpuOwl v6 can't do PRP-1.