PRPnet rally Feb. 18th-25th

[Lumiukko]

Originally Posted by Neo

I'm crunching w/u's with N>1026440.

Last prime was at N=1018709

Did we find a gap??

I'm thinking Lumiukko might have a prime in one of his offline batches ....

Neo

My offline batches are now done - no primes there.

--
Lumiukko

[kar_bon]

Originally Posted by Neo

Did we find a gap??

Primeless gaps and higher densities of primes are 'normal', see for example the 4th MiniDrive.

[Neo]

Originally Posted by kar_bon

Primeless gaps and higher densities of primes are 'normal', see for example the 4th MiniDrive.

Hard to argue with that; the 4th Drive illustrates that point well.

And, here we go with two primes only 6N apart.

Neo

[vaughan]

Originally Posted by mdettweiler

I'm still seeing fallbacks to other servers on my own clients. I went ahead and shut down all the PRPnet clients running on the server--to be safe we should probably leave it completely free to do its server job during the rally.

Thanks. I thought it was something wrong at my end when I noticed the fallbacks occurring yesterday.

Today I lost two boxes. A Q9450 - refuses to boot.

Also a Wolfdale E8400 throws an error on starting PRPnet that the PRPnetclient.exe has encountered a problem. Naturally Windows cannot fix it (does it ever?) and the program aborts. I tried reinstalling the prpnetclients but its still not working. I ran Windows updates; only an Atheros WiFi update and a .net update. PRPnet still fails so I've switched that box back to BOINC MersenneAThome.

[gd_barnes]

I just now noticed that we have a tremendous load coming from team Aggie the Pew. They should easily pass Raiders of the Lost Primes for 2nd place. Could they actually catch PrimeSearchTeam by the end of the rally?

What a tremendous rally we are having!

[AMDave]

Originally Posted by gd_barnes

Is there some sort of "memory leak" so to speak of the CPU usage that causes this to "build up"?

Not a memory leak. I don't know the prpnet server code as I haven't looked at it, so I could be off the track, but I expect that as a candidate is completed it is removed (deleted) from the candidate table. This means that ultimately every candidate that is loaded has a delete performed on it. Unless addressed, over time, this leads to terrible fragmentation of the candidate table and the candidate handouts will take longer.

I have optimized the tables in the prpnet database by hand, I can script this to occur periodically if you like, however this should be done periodically by the application that manages them, in this case the prpnet-server. Perhaps a request could be made to the author to add that feature?

[Lennart]

Originally Posted by AMDave

Not a memory leak. I don't know the prpnet server code as I haven't looked at it, so I could be off the track, but I expect that as a candidate is completed it is removed (deleted) from the candidate table. This means that ultimately every candidate that is loaded has a delete performed on it. Unless addressed, over time, this leads to terrible fragmentation of the candidate table and the candidate handouts will take longer.

I have optimized the tables in the prpnet database by hand, I can script this to occur periodically if you like, however this should be done periodically by the application that manages them, in this case the prpnet-server. Perhaps a request could be made to the author to add that feature?

No It is not removed from candidate table, only updated with some info on the candidate status.
.

Lennart

[AMDave]

Originally Posted by AMDave

I'm just having a bad run.

I was inclined to believe that it was just a bad run but I finished testing the issue on the Phenom II X6 boxes and it turned out to be exactly the same problem.
It all works when I use the llravx switch but not when I use the llr switch.

So 3 chip m/frs and 2 OS's later makes me believe solidly that something is barfed in the prpnetclient bundle.

sorry rogue, but either your llr.exe and llravx.exe are named the wrong way around or your code is calling them the wrong way around.

I thought about it some more and realized that in a a lot of cases some people would not notice because the non-AVX version will work on AVX capable machines. As for the rest, it seems some people are using their own bundles, but some may be switching in their own llr.exe so maybe less likely your code and then more likely that the problem is upstream and they renamed the files badly.

At the end of the day, the prpnetclient 5.0.5 bundle works 'as-is' on zero machines in my attempts.
Both linux and windows bundles fail in the same way on all tested machines.
I don't much care what the problem is exactly, just that it gets fixed.

[AMDave]

Originally Posted by Lennart

No It is not removed from candidate table, only updated with some info on the candidate status.
.

Lennart

Cool. It seems those updates are causing fragmentation over time and an app-controlled optimize is better than one applied externally.

[Neo]

Originally Posted by gd_barnes

I just now noticed that we have a tremendous load coming from team Aggie the Pew. They should easily pass Raiders of the Lost Primes for 2nd place. Could they actually catch PrimeSearchTeam by the end of the rally?

What a tremendous rally we are having!

If it weren't for the extended mountain stage over @ Primegrid, things would be a tad bit closer.

Neo
AtP

[rogue]

Originally Posted by AMDave

sorry rogue, but either your llr.exe and llravx.exe are named the wrong way around or your code is calling them the wrong way around.

I have no control over how PrimeGrid or anyone else bundles software with PRPNet. The PRPNet package I release only has prpclient and prpserver Windows exes. I leave it to the Mac and Linux folks out there to build their own application with the supplied makefiles. I leave it to those who run PRPNet to install and configure any 3rd party apps that PRPNet needs to run. That includes: MySQL, llr, pfgw, phrot, and genefer. PrimeGrid has built the packages that most people have downloaded and run. These packages do bundle the 3rd party apps and have updated the configuration to run them.

That being said, I have no issue with what PrimeGrid is doing. They supply the packages that work for MOST users. Your case appears to be an exception, one that is dependent upon the gwnum library that llr/llravx is linked with.