I would like to ask why this challenge is running for an entire month? I'm wondering because this is a really long time frame for a challenge.

Thanks Rick

I would like to ask why this challenge is running for an entire month? I'm wondering because this is a really long time frame for a challenge.

Thanks Rick

It was the last state of discussions here

I look forward to this event. I think PrimeGrid/PRPNet can achieve instant fame if we are lucky enough to find a Wieferich prime.

The first Wieferich prime was found in the year 1913 by Meißner who had searched up to 2e3. The second one was found in 1922 by Beeger (article) who announced the search complete to 3.7e3.

No further Wieferich primes have been found since. It is not known (with proof) if there are infinetly many Wieferich primes. (Also, it is not known if there are infinitely many non-Wieferich primes!)

It is often conjectured that the average number of Wieferich primes in an interval of form [ exp(exp(a)) , exp(exp(a+r)) ] is r, or equivalently that the number of Wieferich primes below a given quantity is asymptotically log(log(x)).

From Beeger's first threshold 3.7e3 to where we have searched to today, 1.5e17, by that formula, there should have been 1.57 (=log(log(1.5e17))-log(log(3.7e3))) new Wieferich primes, so (if one chooses to believe the conjecture on the distribution of these numbers) it can be seen as a bit unlucky that no new instances have been found yet.

To compare the occurences of Wieferich primes to that of the more famous Mersenne primes, I made this primitive figure (note the doubly logarithmic nature of the axis):



Note that Wieferich and Mersenne numbers are not really related (except no prime can be both Wieferich and Mersenne), but the conjectured average number of Mersenne primes in [ exp(exp(a)) , exp(exp(a+r)) ] is 2.5695*r. So looking at the image, there should be 1.0 Wieferichs (shown on the right) on average in each "block", and 2.5695 Mersennes (on the left).

We see that there are four Mersenne primes between Beeger's Wieferich number 3511 and the current search limit 1.5e17. Next "milestone" will be Pervushin's Mersenne number 2^61-1 = 2305843009213693951 = 2.3e18. This is reachable in principle by the current software used by PRPNet.

The top of the diagram, exp(exp(4)) = 5.1e23, is out of reach with current technology and available processing resources.

In the interval [1.5e17, 2e17] that this challenge addresses (first), there should be 0.0072 new Wieferich primes (=log(log(2e17))-log(log(1.5e17))). The number of near-Wieferichs under the definition we currently use, should be 2000 times that, which is 14.5.

/JeppeSN

I am happy to be IN after all, thanks to the very helpful PrimeGrid's community :)

@ Sysadm@Nbg : Yes, stats works very well.

NB As this is my first PRPNet experience, can you please tell me (for information only ;) ) if PrimeGrid's stats are updated once / week or once / month ?

THANK YOU :D

Thank You :)

I've noticed that the Wieferich search appears to use only 4% of my GPU.

Would there be any problem with telling the software to run multiple workunits at once, each using the same GPU?

Or would it run into some other limit before I reached 25 CPU cores telling the GPU what to do (assuming I had that many CPU cores)?

In the directory that your prpclient is running edit your wwww.ini file and bump up your threads.
Make sure you remove the // in front of the threads and blocks.

Try threads=4
Blocks=2048

Tweak as needed.
____________

Leading edge is already ~1.7e17.
Good job, let's keep up the performance!

@Sysadm@Nbg : Excellent Stats Uli, same every Time. Thank you.
____________
Member of Charity Team

Use Stojag found the second near-Wieferich in this challenge. /JeppeSN

Very nice!

Congratulation to Grebuloner and Stojag

I did a little improvement: (near) finds during this challenge are displayed on top of the stats

Congratulation to Grebuloner and Stojag

I did a little improvement: (near) finds during this challenge are displayed on top of the stats

I did a little improvement: (near) finds during this challenge are displayed on top of the stats

Who ever "loads" the port with new work, shall be aware that during Friday night UTC, the leading edge might reach 1.8e17. /JeppeSN

Ideas for improving this application:

Add instructions for finding the L2 cache size so that the a parameter can be set to a large fraction of this size.

Investigate whether whatever needs this large L2 space would be better placed in the graphics memory, for wwwwcl.exe and wwwwcl64.exe only. Make it clearer which of these two executables should be used on a 64-bit computer with an OpenCL-capable GPU, and what the other one should be used for. This might call for another parameter to control how much graphics memory it can use; if so, the CPU version needs to ignore this new parameter.

So

[2014-09-04 19:43:32 CDT] WIEFERICH: nothing was received on socket after 10 seconds
[2014-09-04 19:43:32 CDT] Could not verify connection to prpnet.primegrid.com. Will try again later.

Now I get this:

[2014-09-04 19:50:34 CDT] ERROR: Server cannot handle more connections

Edit: Beaten to it...

Yeah I'm getting "Server cannot handle more connections" as well as the above.

Another million WU's have just been loaded onto the Wieferich port. We should blow past 2.0e17 at this rate. Port loaded up to 2.8e17. Enjoy!

Stojag seems very lucky here and just found his second near-hit during this challenge. /JeppeSN

In the directory that your prpclient is running edit your wwww.ini file and bump up your threads.
Make sure you remove the // in front of the threads and blocks.

Try threads=4
Blocks=2048

Tweak as needed.

Hello !

Am I dreaming or is the network &/or test calculation much slower than yesterday ?

Or was the server offline last night ?

Thank You

Best Regards

Philippe

Thank you for your messages.

Next time I'll open my eyes before posting ;)

In the directory that your prpclient is running edit your wwww.ini file and bump up your threads.
Make sure you remove the // in front of the threads and blocks.

Try threads=4
Blocks=2048

Tweak as needed.

Something you didn't mention: File wwww.ini uses Unix-style ends-of-lines (even under Windows), and is therefore hard to edit with most Windows editors. I managed it using the Cygwin unix2dos and dos2unix programs, though.

The wwwwcl.exe and wwwwcl64.exe programs appear to need very different values of these parameters, though - those values give about 4% use of the GPU and 2% use of the CPU core.

The wwww.ini file from the server needs to be modified to mention how to determine the correct values from the L2 cache size and the graphics memory size. Also, it needs to be modified to show more clearly whether to use the wwwwcl.exe program or the wwwwcl64.exe program under x64 Windows, and what if anything to use the other one for.

In the directory that your prpclient is running edit your wwww.ini file and bump up your threads.
Make sure you remove the // in front of the threads and blocks.

Try threads=4
Blocks=2048

Tweak as needed.

Something you didn't mention: File wwww.ini uses Unix-style ends-of-lines (even under Windows), and is therefore hard to edit with most Windows editors. I managed it using the Cygwin unix2dos and dos2unix programs, though.

The wwwwcl.exe and wwwwcl64.exe programs appear to need very different values of these parameters, though - those values give about 4% use of the GPU and 2% use of the CPU core.

The wwww.ini file from the server needs to be modified to mention how to determine the correct values from the L2 cache size and the graphics memory size. Also, it needs to be modified to show more clearly whether to use the wwwwcl.exe program or the wwwwcl64.exe program under x64 Windows, and what if anything to use the other one for.

I use notepad to edit the wwww.ini in windows and it works fine.
On the rest of your comment, I just tweak it until I get the quickest return of a workunit on my gpu.
I don't bother with cpu, not worth it in my opinion.

I used Notepad AFTER I used unix2dos to adjust the ends-of-lines to a format compatible with Notepad, and then used dos2unix to adjust then back.

I finally found the way to decode .7z files on my other computer, and then was able to make four CPU cores each finish workunits about as fast as the GPU on the other computer - which show just how bad the initial settings are for GPUs.

I used Notepad AFTER I used unix2dos to adjust the ends-of-lines to a format compatible with Notepad, and then used dos2unix to adjust then back.

I finally found the way to decode .7z files on my other computer, and then was able to make four CPU cores each finish workunits about as fast as the GPU on the other computer - which show just how bad the initial settings are for GPUs.

My GTX 770 can do 1 WFS work unit in 49 seconds.
There is no way any cpu can do one that fast no matter how much tinkering your do.
Or am I missing something?

@robertmiles
I run only one instance of prpclient and one gpu per box and this is my wwww.ini

User 288larsson found a near-Wieferich above 1.8e17. /JeppeSN

There is absolutely no way a CPU core can complete a WU anywhere near as fast as a modern GPU, unless you somehow hamper the GPU deliberately.

My Haswell @ 4.3, even with only one core active and no GPU activity, takes about 25 minutes to complete a WFS WU. All 4 cores active and they'll complete in just under 28 minutes (HT off), so even dividing that by 4 or even 8 comes nowhere close.

User 288larsson found a near-Wieferich above 1.8e17. /JeppeSN

You're missing the fact that my GTX 560 takes much longer, for unknown reasons - a few hours per workunit. A CPU should have little trouble beating that speed, even with no tinkering on the computer running workunits on CPU cores.

You might mention ALL of the relevant settings you are currently using on your GTX 770, so I will have some idea of which parameter to change in which direction.

It may or may not be important that my Windows Vista computer has the bigger L2 cache - 12 MB, compared to 8 MB for my Windows 7 computer.

Another suggestion for improving this application: Add a line of output, showing the total time the workunit ran.

1988golfer,

Thanks. The GPU workunits are running in about 4000 seconds, and the CPU workunits are running in about 3600 seconds.


brinktastee,

What value are you using for wwwwexe?

Also, the Windows 7 version of Notepad appears to be able to edit wwww.ini without changing the end-of-lines, but the Windows Vista version does not.


gassyk1ns,

So you didn't read my earlier posts saying that the GPU version is definitely hampered on my Windows Vista computer, but NOT deliberately?

brinktastee,

What value are you using for wwwwexe?

gassyk1ns,

So you didn't read my earlier posts saying that the GPU version is definitely hampered on my Windows Vista computer, but NOT deliberately?

brinktastee,

What value are you using for wwwwexe?

robertmiles,
I comment out the wwww.exe in my prpclient.ini, I don't use it.
I run my prpclient.exe with wwwwcl64.exe only.
Again, this is my wwww.ini file for my gtx 770 ...

// blocks is a multiplier used to set workgroup size blocks=8000 // threads is the number of concurrent threads to execute threads=5

...and use all 8 HT cores of my i7-950 to feed the GPU.

The GPU workunits are running in about 4000 seconds, and the CPU workunits are running in about 3600 seconds.

Ouch! That's not good.

There is something incredibly broken there. I'll go out on a limb and say even the oldest, slowest, bottom-of-the bargain-bin GPU that is capable of running OpenCL is faster than that. Certainly your GPU is a lot faster than that. Two or three minutes is a reasonable runtime for your GPU.

Either something is severely impacting the nominal performance of the GPU, or the app is actually running on the CPU. (OpenCL apps can run on CPUs as well as GPUs.) Given that the run time on the "GPU" is so close to the CPU runtime, this seems like a real possibility.

The obvious guess is the ini file for configuring the number of threads and block sizes, but if that's not it there's lots of other potential causes. I scanned back through the posts but couldn't find the values you're using in the ini file for Wieferich with that GPU. I know if you don't use an ini file, and the app uses the defaults, it runs VERY slowly. What are the contents of the ini file? What's the name of the ini file?

Edit: Mistake.

128 threads is way too many.
Re-read Scott's post on threads and SM.
12 threads would be max threads if you have a Titan.
____________

brinktastee,

What value are you using for wwwwexe?

robertmiles,
I comment out the wwww.exe in my prpclient.ini, I don't use it.
I run my prpclient.exe with wwwwcl64.exe only.
Again, this is my wwww.ini file for my gtx 770 ...

// blocks is a multiplier used to set workgroup size blocks=8000 // threads is the number of concurrent threads to execute threads=5

...and use all 8 HT cores of my i7-950 to feed the GPU.

I was asking about wwwwexe, not wwww.exe that is one of the possible values for it. It appears that the value you're using is wwwwcl64.exe, though, which is the same value I'm using.

I think I'm only using one CPU core to feed the GPU, and that core is showing only 4 % use. Which parameter controls how many CPU cores are used?

Something that might make a difference - which version of the Nvidia graphics driver are you using?

Also, the Windows 7 version of Notepad appears to be able to edit wwww.ini without changing the end-of-lines, but the Windows Vista version does not.

...

So you didn't read my earlier posts saying that the GPU version is definitely hampered on my Windows Vista computer, but NOT deliberately?

It is NOT a Windows Vista issue. I have identical GTX 645 cards in i-7 boxes (one 860 and one 920). The Win 7 one and the Vista one run in identical times (about 151 secs). Also, I edit all the .ini files using notepad in each without any problems.

So what might be issues that hamper the GPU in one vs. the other? Here are a few things that I have observed for WFS work:

1) Don't run anything else...I mean ANYTHING else. No CPU work on PRPnet or BOINC obviously. These can slow down the work by a factor of 3x or more. But even really light weight things that hit the GPU can cause a significant slowdown (e.g., GTX 645 is about 10 - 15 seconds slower if I do nothing more than run a minesweeper game!)

2) Turn off the "fancy" Windows GUI options. These bells and whistles (especially Aero in the Vista environment) will slow down GPU calculations generally, and really do this with WFS.

3) It is also about the RAM! These are large units in memory. I have identical OEM GTX 660 cards in Quad core plus systems (no HT). One runs work around 87 sec without issue. Another takes three times longer. Both machines are Win 7 dedicated crunchers, and the slower system actually has more RAM. However, the real difference is that the slower system has mismatched RAM running in single channel mode, and this likely is causing the slowdown (I have 8GB of matched RAM on the way and should know this for certain later this week).

4) Dual GPU systems often need more than 4 cores. Let me say that again...you need more than four cores for running two GPUs at full speed. This may work a little different on different systems, but each GPU usually will need at least two cores, and often they may use 3 (or in one case I have, the GPU wants 3.5+ cores!).

5) The default threads and blocks rarely works to maximum efficiency on most cards. The defualt is more likely to work well with older cards (early Fermi cards and the GTX 2xx series). Really old cards (8xxx and 9xxx series) will need these to be smaller (especially the block size), and Kepler cards can go larger (sorry...no experience with ATI/AMD cards on WFS). More importantly, one needs to remember that your cards are not arranged in just shader counts, but these shaders are blocked together in computational groupings (e.g., SM count). It is best to start with the Threads number matched to this value and tinker from their. For example, the GTX 645 has 576 shaders in 3 SMs (i.e., 192 shaders per SM). Running threads=3 is near optimal for this card. The OEM GTX 660 is double this (1152 shaders in 6 SM), and thus, the best starting spot is threads=6.

As with all advice, systems vary and so may our results. Hope the above is somewhat helpful. I'll add more as I continue to test things.

128 threads is way too many.
Re-read Scott's post on threads and SM.
12 threads would be max threads if you have a Titan.

brinktastee,

What value are you using for wwwwexe?

robertmiles,
I comment out the wwww.exe in my prpclient.ini, I don't use it.
I run my prpclient.exe with wwwwcl64.exe only.
Again, this is my wwww.ini file for my gtx 770 ...

// blocks is a multiplier used to set workgroup size blocks=8000 // threads is the number of concurrent threads to execute threads=5

...and use all 8 HT cores of my i7-950 to feed the GPU.

I was asking about wwwwexe, not wwww.exe that is one of the possible values for it. It appears that the value you're using is wwwwcl64.exe, though, which is the same value I'm using.

I think I'm only using one CPU core to feed the GPU, and that core is showing only 4 % use. Which parameter controls how many CPU cores are used?

Something that might make a difference - which version of the Nvidia graphics driver are you using?

I don't follow what you are saying about the wwwwexe.
What is your GPU utilization?
I'm running the latest driver not beta.

These settings work for me in wwww.ini

wieferich_threads=3 wieferich_blocks=3000

I haven't tried blocks= and threads=. This may be irrelevant.

Also you should set wwwwexe=wwwwcl64.exe in prpclient.ini

And finally make sure you copy the wwww.ini file into the directory where the prpclient is running.

Could the Q9650 in my Windows Vista computer versus the i-7s you're using have something to do with it?

Maybe, although I have HT turned off on the 920 and run it as a quad core. I have noticed that the GPU work's CPU usage for Core2 Quads for WFS is usually higher than on other CPUs.

No other PRPnet work running. I'll try setting BOINC to No new tasks to see how much that helps.

With your particular CPU, I'd recommend allowing all the CPU cores to be available for the WFS GPU work.

How can I turn off Aero? I didn't find any settings that appear to be relevant to this.

Try the instructions here.

My Windows computer is using 8GB of matched RAM, and its motherboard cannot accept any more.

Then this isn't an issue.

Only a single GPU on my Windows Vista computer, and no extra motherboard socket to allow adding another one.

What setting controls the number of CPU cores the GPU can use?

This depends on the architecture and the number of threads you are running. As far as i know, it cannot be controlled directly, just indirectly via the settings in the ini file.

How do I find the number of SMs the GTX 560 and GTX 560ti have?

The GTX 560 has 7 SMs. The GTX 560 Ti comes in three models: GTX 560 Ti, GTX 560 Ti OEM, and GTX 560 TI 448. The standard GTX 560 TI (384 shaders) has 8 SMs; the OEM version (352 shaders) has 11; the "448" version (448 shaders) has 14. See here for a list of NVidia cards with the shader and SM details.

With what graphics card?

840M in a laptop (Windows 8.1); completes a WU in 750 seconds using 0.17 CPU core. It ran very slowly until I copied the wwww.ini file into the runtime directory are restarted the WU. The install and update scripts don't copy that file into the runtime directories, so you have to do it manually.

A 760 in a desktop completes a WU in 250 seconds with the same settings, but uses a full CPU core (Linux). I constrain all 3 threads to run on the same core. The GPU completes a WU 23 times faster than the i7-920 CPU, so I make sure that the logical CPU that shares the physical core serving the GPU isn't also running a WU. If I don't do that, the GPU runs about 10% slower.

When you restart the client, it will resume with the new settings and run faster.

288larsson found another one! I need more GPUs.
Might have to cut some copper plumbing out of my house and cash it in for funds.
Those cards aren't cheap!
____________

288larsson found another one! I need more GPUs.

[...]