PRPnet rally Feb. 18th-25th
 

Hi everyone,

After a nearly 10 month absence of rallies, we figured it's time to have another. The rally will begin Saturday, Feb. 18 at 7 PM GMT and finish 168 hours later on Sat., Feb. 25 at 7 PM GMT. That is 2 PM EST and 1 PM CST in the U.S.

This time for the first time, the rally will solely be a PRPnet rally as NPLB continues its transition to mostly PRPnet servers. It will be focusing on our 14th drive, that is k=600-1001 for n>1M, in order for the range to play "catch up" with our 13th drive. That means PRPnet port 2000, which should be in the vicinity of n=1.01M-1.04M during the rally. A prime at that level should come in around 1000th-1500th place in the top-5000 list.

PRPnet config info.:
server = "www.noprimeleftbehind.net"
port = 2000

Or, in terms of a prpclient.ini config line:
server=G2000:100:1:noprimeleftbehind.net:2000

Be sure and change your userID to whatever ID you prefer. Most people use their ID here at mersenneforum. It is also best to set the cache to something in the vicinity of 2 to 10 pairs.

Info. for downloading the newest PRPnet client can be found at [URL="http://www.mersenneforum.org/showthread.php?t=12223"][COLOR=#000080]PRPnet[/COLOR][/URL].

Rally stats can be found at [URL="http://www.noprimeleftbehind.net/stats/index.php?content=gauntlet&rally_date=20120218"]rally stats[/URL].

The last few rallies, PrimeSearchTeam has been rather dominant. Let's see if we can give them a run for their money this time.


Gary


Primes found during the rally:
[code]
prime who
695*2^1008532-1 Lennart
663*2^1009098-1 Lennart
811*2^1010419-1 Lumiukko
899*2^1010544-1 Lennart
947*2^1012854-1 Lennart
669*2^1013592-1 Lennart
691*2^1013875-1 Lennart
829*2^1017747-1 gd_barnes
727*2^1018709-1 Lennart
641*2^1018986-1 Lennart
741*2^1027639-1 Lumiukko
703*2^1031219-1 odicin
727*2^1031225-1 Lennart
783*2^1034775-1 Lennart
[/code]

sweeeeeeeeeeeet :)

The rally starts in just over 12 hours. Come one come all to port 2000! :smile:

I just moved all of my machines over to port 2000 that weren't already there--they should all be on within a couple hours as they finish their current workloads.

This should (hopefully) be a record rally for me--I lost two machines' worth of firepower but more than made up for it by adding two others that are more powerful. My venerable Q6600, long the linchpin of my computational arsenal, kicked the bucket in early December (probably CPU failure--it became extremely unstable at the end) and was replaced by an i5-2400, which in addition to being twice as fast as the Q6600 on a per-core basis to begin with, can take advantage of the AVX speedups in recent pre-release LLR versions for an additional 50% speedup. I also dropped a Phenom 9750 on extended loan from Gary which has now been "returned" to him, but in turn added an i7-2620M (dual core) tablet PC laptop which, like the i5, is 250% faster per-core than a Core 2, for a net throughput slightly greater than what the Q6600 produced. That, plus a Phenom II X4 N970 that I've had for a little while (but not as far back as the last rally) and my old E4500 dualcore should put me consistently over 50-60 tests/hour on port 2000. :cool:

[QUOTE=mdettweiler;289849]I just moved all of my machines over to port 2000 that weren't already there--they should all be on within a couple hours as they finish their current workloads.

This should (hopefully) be a record rally for me--I lost two machines' worth of firepower but more than made up for it by adding two others that are more powerful. My venerable Q6600, long the linchpin of my computational arsenal, kicked the bucket in early December (probably CPU failure--it became extremely unstable at the end) and was replaced by an i5-2400, which in addition to being twice as fast as the Q6600 on a per-core basis to begin with, can take advantage of the AVX speedups in recent pre-release LLR versions for an additional 50% speedup. I also dropped a Phenom 9750 on extended loan from Gary which has now been "returned" to him, but in turn added an i7-2620M (dual core) tablet PC laptop which, like the i5, is 250% faster per-core than a Core 2, for a net throughput slightly greater than what the Q6600 produced. That, plus a Phenom II X4 N970 that I've had for a little while (but not as far back as the last rally) and my old E4500 dualcore should put me consistently over 50-60 tests/hour on port 2000. :cool:[/QUOTE]

I shall try to keep up with you :smile:

Lennart

I also will be in with nearly all cores... but Lennarts firepower is amazing, I seen in other races ;)

Regards Odi

Is this only for Linux hosts? None of my 6 Win hosts (1 Win 2003 server X64, 2 WinXP x86, 3 Win7 x64) can get any work from noprimeleftbehind.net:

[2012-02-18 23:27:13 FST] G2000: nothing was received on socket after 10 seconds
[2012-02-18 23:27:13 FST] Could not verify connection to noprimeleftbehind.net. Will try again later.
[2012-02-18 23:27:23 FST] G2000: nothing was received on socket after 10 seconds
[2012-02-18 23:27:23 FST] Could not verify connection to noprimeleftbehind.net. Will try again later.
[2012-02-18 23:27:23 FST] PPSElow: Getting work from server prpnet.mine.nu at port 12000
[2012-02-18 23:27:32 FST] PPSElow: PRPNet server is version 4.3.6
Hi! Welcome to PrimeGrid's PPSE Low n server.
Starting Proth prime test of 7053*2^323120+1

I have tried also other ports (in noprimeleftbehind.net) with no success.
PRPNet-client ver 5.0.5.
Pinging noprimeleftbehind.net works OK.
Disabling firewall did not help.
My Linux host is getting work fine.

Server lines in prpclient.ini:
server=G2000:100:2:noprimeleftbehind.net:2000
server=PPSElow:0:1:prpnet.mine.nu:12000

--
Lumiukko

[QUOTE=Lumiukko;289906]Is this only for Linux hosts? None of my 6 Win hosts (1 Win 2003 server X64, 2 WinXP x86, 3 Win7 x64) can get any work from noprimeleftbehind.net:

[2012-02-18 23:27:13 FST] G2000: nothing was received on socket after 10 seconds
[2012-02-18 23:27:13 FST] Could not verify connection to noprimeleftbehind.net. Will try again later.
[2012-02-18 23:27:23 FST] G2000: nothing was received on socket after 10 seconds
[2012-02-18 23:27:23 FST] Could not verify connection to noprimeleftbehind.net. Will try again later.
[2012-02-18 23:27:23 FST] PPSElow: Getting work from server prpnet.mine.nu at port 12000
[2012-02-18 23:27:32 FST] PPSElow: PRPNet server is version 4.3.6
Hi! Welcome to PrimeGrid's PPSE Low n server.
Starting Proth prime test of 7053*2^323120+1

I have tried also other ports (in noprimeleftbehind.net) with no success.
PRPNet-client ver 5.0.5.
Pinging noprimeleftbehind.net works OK.
Disabling firewall did not help.
My Linux host is getting work fine.

Server lines in prpclient.ini:
server=G2000:100:2:noprimeleftbehind.net:2000
server=PPSElow:0:1:prpnet.mine.nu:12000

--
Lumiukko[/QUOTE]

I run both winXP and Win7 and they work.

Strange.

Lennart

Win, Mac, and Linux hosts should all work.

Dave,

The rally started ~3-1/2 hours ago. Is there something wrong with the rally stats at [URL]http://www.noprimeleftbehind.net/stats/index.php?content=gauntlet_20120218[/URL]?


Gary

[QUOTE=Lumiukko;289906]Is this only for Linux hosts? None of my 6 Win hosts (1 Win 2003 server X64, 2 WinXP x86, 3 Win7 x64) can get any work from noprimeleftbehind.net....
--
Lumiukko[/QUOTE]

Found the reason, it was not the Win firewall but my HW-firewall. Now I just need to figure out why, and how to configure it to let this traffic through.

--
Lumiukko

[QUOTE=gd_barnes;289916]... Is there something wrong with the rally stats at [URL]http://www.noprimeleftbehind.net/stats/index.php?content=gauntlet_20120218[/URL]?
...[/QUOTE]
Yes. Indeed there was.
Can you sing "Lets doooooo the time warp AGAAAAAAAIN!" lol
2011 instead of 2012. >>facepalm<<
There is an update in progress which will finish in about 10 minutes.
I'll push a manual update as soon as that gets out of the way.

EDIT - results are up.

I need some technical support please.

Win 7 64-bit box running an Intel Q6600 CPU.

When it is configured to run Port=9000 tasks all is good.
Using prpclient.ini:
//server=G2000:100:1:noprimeleftbehind.net:2000
server=G9000:100:1:noprimeleftbehind.net:9000

When I modify the prpclient.ini file and try to start the application it briefly shows it tries to open a DOS box but this disappears immediately.
Using modified prpclient.ini:

server=G2000:100:1:noprimeleftbehind.net:2000
//server=G9000:100:1:noprimeleftbehind.net:9000

What is wrong?

[QUOTE=vaughan;289941]I need some technical support please.

Win 7 64-bit box running an Intel Q6600 CPU.

When it is configured to run Port=9000 tasks all is good.
Using prpclient.ini:
//server=G2000:100:1:noprimeleftbehind.net:2000
server=G9000:100:1:noprimeleftbehind.net:9000

When I modify the prpclient.ini file and try to start the application it briefly shows it tries to open a DOS box but this disappears immediately.
Using modified prpclient.ini:

server=G2000:100:1:noprimeleftbehind.net:2000
//server=G9000:100:1:noprimeleftbehind.net:9000

What is wrong?[/QUOTE]
Have you unfinished work left from 9000 ?

Finish them or remove them.

or change prpclient.ini when it is running to stopasapoption=2

Lennart

[QUOTE=Lennart;289942]Have you unfinished work left from 9000 ?

Finish them or remove them.

or change prpclient.ini when it is running to stopasapoption=2

Lennart[/QUOTE]

Yes.

OK will do.

[QUOTE=vaughan;289943]Yes.

OK will do.[/QUOTE]

Or let this line be open //server=G9000:100:1:noprimeleftbehind.net:9000
like this

server=G9000:100:1:noprimeleftbehind.net:9000

change 100 to 0

server=G9000:0:1:noprimeleftbehind.net:9000

and it looks like this

server=G2000:100:1:noprimeleftbehind.net:2000
server=G9000:0:1:noprimeleftbehind.net:9000


Lennart

[QUOTE=vaughan;289941]
server=G2000:100:1:noprimeleftbehind.net:2000
//server=G9000:100:1:noprimeleftbehind.net:9000

What is wrong?[/QUOTE]

Open the command prompt and start the client manually. It will output a message with a description of the problem.

I'm surprised at the fact that my quad core i5-750, with about 16 complete per hour, places me dead last out of the active participants in the rally.
I'm using 32-bit cllr 3.8.4 to run the tests (my OS is 64-bit). Is there any better software to run for my hardware, or am I simply behind because of the others having more/better hardware?

Try to use the actual 3.8.7 llr64 dev builds. In most cases there speedups at around 10% on 64bit systems.

Regards Odi

[QUOTE=Mini-Geek;289966]I'm surprised at the fact that my quad core i5-750, with about 16 complete per hour, places me dead last out of the active participants in the rally.
I'm using 32-bit cllr 3.8.4 to run the tests (my OS is 64-bit). Is there any better software to run for my hardware, or am I simply behind because of the others having more/better hardware?[/QUOTE]

You are doing extremely well in the stats if that is your only crunching rig.

I have 7 Phenom II cores running (3.35-3.6ghz) and your system is keeping up.

Neo
Aggie The Pew

[QUOTE=odicin;289968]Try to use the actual 3.8.7 llr64 dev builds. In most cases there speedups at around 10% on 64bit systems.

Regards Odi[/QUOTE]
Ah, thanks, prompted by this I did some more searching and found the 64-bit Windows build.
[QUOTE=Neo;289971]You are doing extremely well in the stats if that is your only crunching rig.

I have 7 Phenom II cores running (3.35-3.6ghz) and your system is keeping up.

Neo
Aggie The Pew[/QUOTE]
Yes, that's my only rig. You're doing about 30/hour. Per core, you're doing slightly better than me, which is to be expected given the CPU (Intel generally runs FFTs faster than comparable AMD) and GHz (I'm 2.8 GHz) differences.

@ Lennart: has anything changed in your windows 7z download package?

I have downloaded it a few times today and after I update the master_prpclient.ini config file with my ID details etc and put in the line containing the port 9000 stuff (server=G2000:100:1:noprimeleftbehind.net:2000) and //commenting out the other projects/ports the app fails with a Windows message (prpclient.exe is missing).

I have run the quad update batch file once (4-quad-update-prpclient.bat) and then try to run quad start (4-quad-start-prpclient.bat) and it says the prpclient.exe is missing. I also noticed that the 4 sub-directories that were created by the previous installation package are not made now with today's package (I guess that explains the missing prpclient.exe message).

[QUOTE=vaughan;290034]@ Lennart: has anything changed in your windows 7z download package?

I have downloaded it a few times today and after I update the master_prpclient.ini config file with my ID details etc and put in the line containing the port 9000 stuff (server=G2000:100:1:noprimeleftbehind.net:2000) and //commenting out the other projects/ports the app fails with a Windows message (prpclient.exe is missing).

I have run the quad update batch file once (4-quad-update-prpclient.bat) and then try to run quad start (4-quad-start-prpclient.bat) and it says the prpclient.exe is missing. I also noticed that the 4 sub-directories that were created by the previous installation package are not made now with today's package (I guess that explains the missing prpclient.exe message).[/QUOTE]

No not the last 14 days.

When you run 4 core install script there shall be 4 prpclient-1-4.

If not there are something wrong.

I shall investigate..

Lennart

[QUOTE=vaughan;290034]@ Lennart: has anything changed in your windows 7z download package?

I have downloaded it a few times today and after I update the master_prpclient.ini config file with my ID details etc and put in the line containing the port 9000 stuff (server=G2000:100:1:noprimeleftbehind.net:2000) and //commenting out the other projects/ports the app fails with a Windows message (prpclient.exe is missing).

I have run the quad update batch file once (4-quad-update-prpclient.bat) and then try to run quad start (4-quad-start-prpclient.bat) and it says the prpclient.exe is missing. I also noticed that the 4 sub-directories that were created by the previous installation package are not made now with today's package (I guess that explains the missing prpclient.exe message).[/QUOTE]

What OS Win7 ?

Check that you have permission to create directory.

The same in linux and check that all scripts and bin files have execution permission.

I dowloaded and run the install script for 4 core and got 4 new folders and the apps in them.


Lennart

EDIT: You do it in the uncompressed folder ? :)

Thanks all sorted now. I failed to run the install batch file, silly mistake huh! Only did the master and the update before trying start - forgot the install.

Yeah Win7.

I'm 'trying' to use prpclient-5.0.5-windows.7z
Used the PRPNet client link in the 1st post in this thread and ended up here: [url]http://uwin.mine.nu/PRPNet/[/url]
Can't see the older versions you guys are talking about.
Downloaded the 5.0.5 client.
The readme instructions need to be updated

1. unzip the 7z
2. open that folder
3. modify the file master_prpnet.ini with your settings
4. run the X-xxxx-install-prpclient.bat which will create the number of folders and copy in the programs to each (NB - it does NOT copy the INI file)
5. run the X-xxxx-update-prpclient-ini.bat (NB - this does copy the INI file)
6. run the X-xxxx-start-prpclient.bat

That 'should' get you going.

On Win7 64 however I have a 'failure to fly' with prpclient-5.0.5-windows.7z:

"Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle."

10 cores idling.

Has someone got a link to a PRPNet client that works that I can use?
TIA

[QUOTE=AMDave;290069]On Win7 64 however I have a 'failure to fly' with prpclient-5.0.5-windows.7z:

"Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle."

10 cores idling.

Has someone got a link to a PRPNet client that works that I can use?
TIA[/QUOTE]

Without being familiar with those setup scripts, it sounds more like a problem with LLR or PFGW than PRPnet. There are some builds of the latest LLR (3.8.7) at [url]http://www.primegrid.com/forum_thread.php?id=4016[/url]. Assuming you have a non-AVX CPU, you'll want [URL="http://www.bc-team.org/downloads.php?view=detail&df_id=45"]this link[/URL].
If you do need the PRPnet client: (this doesn't include setup scripts)
[url]http://home.roadrunner.com/~mrodenkirch/prpnet_5.0.6.zip[/url]

The installation looks correct, maybe there is an issue with the master_prpclient.ini.

Which parameters you set as startoption, stopoption and stopasapoption?

Have you commented out the servers you did not want to run?

Have you set the right apps, depending on the system you run (x86, x64, AVX?)

I tried to send you mine via PM, but I looks like there too many characters to send.

Regards Odi

[QUOTE=AMDave;290069]"Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle."[/QUOTE]

Definitely an issue with llr or pfgw, most likely llr since it is base 2. Try a different build of llr.

[QUOTE=Mini-Geek;290071]...it sounds more like a problem with LLR or PFGW than PRPnet...[/QUOTE]
Alternatives tried and failed with same error.

odicin. Thanks. Config is correct.

EDIT -
I found an old set of 32-bit PRPNet binaries in my archive that I used successfully April last year.
Runs slow but at least it is stable and will produce some results.
2 days down and I have 1 core working. yay. I'll try to bring my enthusiasm tomorrow. :p

There are 3 llr in the folders and it will use the one you have in master ini file.

llr.exe
llravx.exe
llrCUDA.exe

In master ini what do you use here ?

// LLR can be downloaded from [url]http://jpenne.free.fr/index2.html[/url]
// If your CPU is AVX capable, comment out the llr.exe line
// and uncomment the llravx.exe line
llrexe=llr.exe
// llrexe=llravx.exe

Lennart

llr.exe in master ini

the point is moot.
I don't have time to do elimination testing right now and I lost the mood for it.
Timezone not working in my favour atm.

I'm now using the 32-bit binaries from April 2011 for this run.
1 laptop now on 2 cores

I was going to bring in several other boxen but I have spent more time on this than planned.
Maybe a couple more cores tomorrow.

[QUOTE=gd_barnes;287828]...It is also best to set the cache to something in the vicinity of 2 to 10 pairs....

[/QUOTE]

What is the max cache (how many wu's I can get from the server at a time)?
What is the expiration time of these wu's?

I am asking because I want to do some work offline, and need to know how long offline periods I can have.

--
Lumiukko

The max cache is 200 (it was at 50 a moment ago but I upped it to 200, since you're planning to do offline work :smile:). The deadline is 72 hours, i.e. 3 days.

(BTW: you can check the deadline on any (recent-version) PRPnet server by looking at the pending-tests list on the [url=http://noprimeleftbehind.net:2000/all.html]stats page[/url]. It shows "Age" and "Expired" columns for all pending tests.)

If anyone sees that sod Murphy, give him a black eye from me.
None of my results are showing up with that old client from any of 8 cores.
That leaves me on the sideline in the Cheer Squad.
Yayy. Go teaaam. Gimme a pom-pom.

I got 4.3.7 working on 1 box and it is reporting some work finally.

I tried all versions from 5.0.5 back to 4.3.7 on the laptops and they all fail on the T4500 chips for both 32 bit and 64 bit options. It's a bit disappointing.
3.1.7 still works on the T4500 cores, but now the server doesn't recognise the results.
I suspect someone has got trigger happy with some compiler flags. :P
A good incentive to go back to compiling my own clients again.
It's nice when things 'just work'.

So 4 out of 22 cores isn't a complete failure.

PS - someone needs to watch what end-of-line characters they use. that 4.3.7 master ini file is awful when you look at it in Notepad. Much better in N++ though.

[QUOTE=AMDave;290187]I got 4.3.7 working on 1 box and it is reporting some work finally.

I tried all versions from 5.0.5 back to 4.3.7 on the laptops and they all fail on the T4500 chips for both 32 bit and 64 bit options. It's a bit disappointing.
3.1.7 still works on the T4500 cores, but now the server doesn't recognise the results.
I suspect someone has got trigger happy with some compiler flags. :P
A good incentive to go back to compiling my own clients again.
It's nice when things 'just work'.

So 4 out of 22 cores isn't a complete failure.

PS - someone needs to watch what end-of-line characters they use. that 4.3.7 master ini file is awful when you look at it in Notepad. Much better in N++ though.[/QUOTE]

It isn't an issue of the PRPNet client, but the llr that is bundled with the package released by PrimeGrid. I don't bundle any of the testing software with PRPNet, but I do provide links to d/l them.

I never use NotePad to edit text files on Windows for the reason you give amongst many others.

rogue, my apologies. I know it's not you and the llr is bundled. I'ts generally agreed that the suspect here is the LLR binary and as I posted higher up, I tried others and they also failed. However the llr that was bundled with 3.1.7 prpnetclient and earlier did work. Sometime since then, someone upstream has likely used some flags that the T4500's don't support. Unfortunately the 3.1.7 client package is not posting the results successfully with the prpnet server, which is to be expected over time. I could try pulling that old llr forward into the 5.0.5 prpnetclient, but I'm over it and now the laptops are doing something else.

Re-the text file, glad to hear it. :) but someone messed up your master ini around the start and stop options in the 4.3.7 windows 7z on Lennart's downloads page. It is fine in the more recent versions. I mention it if anyone else like me has to go back and use that version then maybe Lennart can fix it and repackage the 7z file.

It all works for everyone else. I'm just having a bad run. Ignore me.

So, I'm new here to NPLB, however am excited to be participating in this rally :-)

Anyways, I just wanted to throw a question out there... my first WUs just completed and stats updated for the first hour I returned WUs, and it has a blank team name for me. I noticed this for a few other of my "teammates" as well.

My .ini file properly has team name in it. Is there something else I am missing?

Back to back primes!

Nice job PCZ. :smile:

Neo
AtP

[QUOTE]So, I'm new here to NPLB, however am excited to be participating in this rally :-)

Anyways, I just wanted to throw a question out there... my first WUs just completed and stats updated for the first hour I returned WUs, and it has a blank team name for me. I noticed this for a few other of my "teammates" as well.

My .ini file properly has team name in it. Is there something else I am missing?[/QUOTE]

We have a separate stats DB other than what is in PRPNet. I have added the following to Aggie The Pew based on their PRPNet team choice. The stats should reflect this at the next update.

Caravaggio
KD7LRJ
Mark_Doom
Gary_Craig
meiligo

[QUOTE=Neo;290215]Back to back primes!
Nice job PCZ. :smile:
Neo
AtP[/QUOTE]
Absolutely. Great to see a Free-DC representative again.
And we have some new names and teams this time.
Excellent. Crunch On!

[QUOTE=AMDave;290195]rogue, my apologies. I know it's not you and the llr is bundled. I'ts generally agreed that the suspect here is the LLR binary and as I posted higher up, I tried others and they also failed. However the llr that was bundled with 3.1.7 prpnetclient and earlier did work. Sometime since then, someone upstream has likely used some flags that the T4500's don't support. Unfortunately the 3.1.7 client package is not posting the results successfully with the prpnet server, which is to be expected over time. I could try pulling that old llr forward into the 5.0.5 prpnetclient, but I'm over it and now the laptops are doing something else.

Re-the text file, glad to hear it. :) but someone messed up your master ini around the start and stop options in the 4.3.7 windows 7z on Lennart's downloads page. It is fine in the more recent versions. I mention it if anyone else like me has to go back and use that version then maybe Lennart can fix it and repackage the 7z file.

It all works for everyone else. I'm just having a bad run. Ignore me.[/QUOTE]
Dave, I'm not sure what's up with this but the problem definitely seems to be with the LLR included with the latest clients (perhaps the particular build, or particular version)--as you discovered yourself. Since the LLR bundled with 3.1.7 worked before (presumably on these same computers?), that one should definitely work again with the latest client--all PRPnet versions are fully cross-compatible with all command-line LLR versions (Linux llr and Windows cllr.exe).

That particular error you got, "Number sent to gwsetup is too large...", is, interestingly enough, the exact same error some fellows over at PrimeGrid were reporting with AMD Bulldozer machines on the latest development version of LLR--though in their case it was due to the latest development verison adding AVX support for a speed boost on Sandy Bridge and Bulldozer CPUs, but not (yet) properly taking into account differences in how Bulldozer implements AVX. I don't think I've ever heard of this error being thrown up by a pre-AVX machine, least of all with a non-development LLR build, but nonetheless it is what you're seeing. It would almost seem to indicate that somehow LLR doesn't know how to handle your CPUs, which is strange because a T4500 is a pretty standard laptop-spec Core 2 Duo, which [I]should[/I] be a no-brainer for LLR.

[QUOTE=MyDogBuster;290218]We have a separate stats DB other than what is in PRPNet. I have added the following to Aggie The Pew based on their PRPNet team choice. The stats should reflect this at the next update.

Caravaggio
KD7LRJ
Mark_Doom[/QUOTE]
I saw the accidental '-' at the end of the team name for KD7LRJ but someone fixed it faster than I could get to it. (Good shooting whoever that was)
The team total will be corrected automatically by the database on the next refresh. :smile:

@Max. Thanks. Yup. Used to work on same hardware. As above I suspect upstream LLR sources have made an error. Never mind. There is always next time. :)

[QUOTE=AMDave;290221]I saw the accidental '-' at the end of the team name for KD7LRJ but someone fixed it faster than I could get to it. (Good shooting whoever that was)
The team total will be corrected automatically by the database on the next refresh. :smile:[/QUOTE]
Ah yes, that was me...just fired off a PM to Ian so he would know it was me and not some mysterious gremlins, but didn't expect that you too would be on the ball and catch it before the next refresh. :wink:

[QUOTE=Neo;290215]Back to back primes!

Nice job PCZ. :smile:

Neo
AtP[/QUOTE]

Unfortunately this was not to be. They both turned out to be composite. Brian reported in our "report primes for k<1000" thread that a bad machine found them to be erroneously prime. Max and Dave, see that thread for questions about how to get our DB corrected.


Gary

Oh Boo! Find more primes everyone!

EDIT - action taken pending revised residuals / re-queue. See that thread.

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

The server says "14th Drive (K=600-1001, n=1M-2M)"

Below is all -1 primes for 600<K<1001 for N=1M-2M)
---- -------------------------------- ------- ----- ---- --------------
rank description digits who year comment
----- -------------------------------- ------- ----- ---- --------------
242 737*2^1592724-1 479461 L191 2006 :huh:
292 907*2^1501169-1 451900 L860 2010
888 861*2^1203625-1 362331 L251 2011
947 617*2^1175468-1 353854 L426 2007 :huh:
1459 727*2^1018709-1 306665 L1809 2012
1462 829*2^1017747-1 306376 L1817 2012
1478 691*2^1013875-1 305210 L1809 2012
1481 669*2^1013592-1 305125 L1809 2012
1483 947*2^1012854-1 304903 L1809 2012
1495 899*2^1010544-1 304208 L1809 2012
1497 811*2^1010419-1 304170 L2995 2012
1509 663*2^1009098-1 303772 L1809 2012
1511 695*2^1008532-1 303602 L1809 2012
1518 921*2^1006898-1 303110 L1817 2012
1520 993*2^1006834-1 303091 L1817 2012
1521 903*2^1006812-1 303084 L2257 2012
1534 729*2^1003373-1 302049 L466 2008
1536 853*2^1003063-1 301955 L2257 2012
1540 735*2^1002509-1 301789 L2257 2012
1541 819*2^1002205-1 301697 L2257 2012
----- -------------------------------- ------- ----- ---- --------------

This is confusing. ??

RPS didn't start their search at N=1M? for all k 600-1001?

Neo

[QUOTE=Neo;290402]The server says "14th Drive (K=600-1001, n=1M-2M)"

Below is all -1 primes for 600<K<1001 for N=1M-2M)
<snip>
This is confusing. ??

RPS didn't start their search at N=1M? for all k 600-1001?

Neo[/QUOTE]
The history of this range is somewhat interesting. :smile: Before NPLB began actively searching the range, k=300-1001 was handled by the PrimeSearch project, which provided a web-based automated reservation system for individual k's within the range. Over time the project lapsed into inactivity as it ran into technical difficulties with its website, and much of their later search data ended up being spotty and unreliable. Seeing the inactivity at PrimeSearch, RPS did some limited searches on an individual-k basis, starting from the (assumed correct) PrimeSearch testing limits and somtimes skipping forward to top-5000 ranges. In general, though, the range didn't see much activity during this period, due to uncertainty as to who "owned" the range (so to speak, since of course nobody can "own" a number per se). NPLB was started as an attempt to revitalize the original PrimeSearch effort (it was, in fact, a renaming of the original project with an recognized transfer of leadership from the original admin to Gary), and started right away on the entire continuous k=300-1001, n<1M range. (We completed that goal last year and are now working on completing the entire range to n=2M.)

The idea of doing continuous searches over large blocks of k and n was actually somewhat unique to NPLB when it started--to this day, AFAIK, NPLB and PrimeGrid are the only projects to utilize this approach on a large scale in the Riesel and Proth number spaces. RPS has done some of this recently as well with their 11th Drive on the k=2000-2300 range, though unlike NPLB they opted to start at the current top-5000 threshold level and skip k's that may have (but haven't been confirmed firmly) already tested.

Anyway, long story short, that's how the handful of pre-NPLB primes you found (from 617*2^1175468-1 up on your list) got there--they were found in previous sporadic searches in the range by RPS, pre-NPLB PrimeSearch, and other unaffiliated prime hunters.

[QUOTE=mdettweiler;290220]...That particular error you got, "Number sent to gwsetup is too large...", is, interestingly enough, the exact same error some fellows over at PrimeGrid were reporting with AMD Bulldozer machines on the latest development version of LLR--though in their case it was due to the latest development verison adding AVX support for a speed boost on Sandy Bridge and Bulldozer CPUs, but not (yet) properly taking into account differences in how Bulldozer implements AVX. I don't think I've ever heard of this error being thrown up by a pre-AVX machine, least of all with a non-development LLR build, but nonetheless it is what you're seeing. It would almost seem to indicate that somehow LLR doesn't know how to handle your CPUs, which is strange because a T4500 is a pretty standard laptop-spec Core 2 Duo, which [I]should[/I] be a no-brainer for LLR.[/QUOTE]

Your thoughts gave me a hunch, so I just redeployed the prpnetclient 5.0.5 bundle, but this time I set the INI to use llravx.exe instead of llr.exe (which is counter intuitive for this CPU but bear with me...)

It worked.

So, methinks the 2 filenames of llr.exe and llravx.exe are the wrong way around in the 5.0.5 bundle.

rogue / Lennart is there any way you can verify this?

ITMT I'll redeploy the clients to the T4500s in this configuration and see if I can pull back some ground.

Thanks for the hunch, Max.

[QUOTE=AMDave;290423]Your thoughts gave me a hunch, so I just redeployed the prpnetclient 5.0.5 bundle, but this time I set the INI to use llravx.exe instead of llr.exe (which is counter intuitive for this CPU but bear with me...)

It worked.

So, methinks the 2 filenames of llr.exe and llravx.exe are the wrong way around in the 5.0.5 bundle.

rogue / Lennart is there any way you can verify this?

ITMT I'll redeploy the clients to the T4500s in this configuration and see if I can pull back some ground.

Thanks for the hunch, Max.[/QUOTE]
Hmm...quite interestingly, there was somebody else at PrimeGrid who had it work exactly that way: he had an eminently "ordinary", non-AVX CPU that failed with regular LLR but worked with llrAVX. I don't recall what CPU he had, but given that you're experiencing basically the same thing, I would hazard a guess that the LLRs are indeed labeled correctly, and llrAVX (for some unknown reason) can handle your non-AVX CPU better. :rolleyes:

Incidentally, the non-AVX llr.exe should be on the order of 25 MB, and llrAVX.exe around 35 MB (since it includes most, if not all, of the code for handling pre-AVX CPUs present in earlier versions, plus new code for AVX). If your copies match that, they're probably labeled correctly.

Edit: Aha, found it! The issue was reported [url=http://www.mersenneforum.org/showthread.php?t=16493#post289261]here[/url] in a cross-post [URL="http://www.primegrid.com/forum_thread.php?id=4016&nowrap=true#49389"]from the PrimeGrid forums[/URL]. In this case the CPU was an AMD E350--one of the somewhat-recent AMD CPUs (non-Bulldozer) that is sold as an "APU"--a processor and graphics card wrapped up in one unit, AMD's counterpart to the on-die GPUs in Intel Sandy Bridges. Though it isn't a Bulldozer, it would make sense that the older LLR (more precisely, the older gwnum math library compiled into LLR--the AVX and non-AVX binaries currently provided are both LLR 3.8.7 but compiled with the development and stable gwnum releases respectively) might not be able to handle it since it's a newer and more "oddball" CPU type; but it doesn't explain why your much more common Pentium Dual-Core (C2D based) T4500 is experiencing the same issue.

I have personally used LLR (pre-AVX, in fact an older version, probably the same one you got from the 3.1.7 package) on a laptop Pentium Dual-Core Txxxx (not 4500 but close, a 2.0GHz model) and it worked fine--just like yours did with the older LLR. Unfortunately that laptop belongs to a family member 300 miles away and I can't readily test it with the latest LLR AVX and non-AVX builds to verify your results, but I am quite curious how that would turn out...

Uh, oh. I think my head just imploded. :ouch2: hahaha

So not something as simple as a file naming error upstream then.
How bizarre. I guess that, with the need to keep compilers working across so many core types, these variations would arise eventually.
Is it worth cross posting to that thread to let Jean Penné know that it is not an isolated case?

On the bright-side, I've got a couple of them suckers crunching so if the results are accepted I'm still better off than I was. :cool:

Not only at this time, I try to remember around some months ago (before avx) a similar problem with the older 3.8.4 llr and some AMD CPU's at PG. In fact the problem was the used gnum version so Primegrid updated all there stock apps to 3.8.6 llr which uses a newer gnum version.

Rebirthers AVX build of llr uses the early beta of gnum 27.3, the latest llr from jean penne still use 26.5. I suppose this is the problem there.

You can track down the problem with rebirthers non-avx x64 llr build. This one also use gnum 27.3 instead of 26.5.

Regards Odi

[QUOTE]
Anyway, long story short, that's how the handful of pre-NPLB primes you found (from 617*2^1175468-1 up on your list) got there--they were found in previous sporadic searches in the range by RPS, pre-NPLB PrimeSearch, and other unaffiliated prime hunters.[/QUOTE]

Thanks Max for the clarification; I suspected that was the reason. :smile:

Neo
AtP

[QUOTE=odicin;290445]Not only at this time, I try to remember around some months ago (before avx) a similar problem with the older 3.8.4 llr and some AMD CPU's at PG. In fact the problem was the used gnum version so Primegrid updated all there stock apps to 3.8.6 llr which uses a newer gnum version.

Rebirthers AVX build of llr uses the early beta of gnum 27.3, the latest llr from jean penne still use 26.5. I suppose this is the problem there.

You can track down the problem with rebirthers non-avx x64 llr build. This one also use gnum 27.3 instead of 26.5.

Regards Odi[/QUOTE]
Hmm...so the non-AVX x64 builds are based on gwnum 27.3 as well? How does that work? Is there a compile flag or something that can enable/disable AVX for a given (v27.x) gwnum version?

I have big problem to reach the server ! Only 50-60% is conecting but there are no problem to reach other server on PG.

Are there some problem or some manage ongoing ?


Lennart

Correct. You can swap to another gnum lib, because it's not a part of llr itself. But I don't know how exactly it works, better you ask this rebirther or rouge.

Regards Odi

[QUOTE=odicin;290461]Correct. You can swap to another gnum lib, because it's not a part of llr itself. But I don't know how exactly it works, better you ask this rebirther or rouge.

Regards Odi[/QUOTE]

gwnum is linked into the executable.

[QUOTE=Lennart;290459]I have big problem to reach the server ! Only 50-60% is conecting but there are no problem to reach other server on PG.

Are there some problem or some manage ongoing ?


Lennart[/QUOTE]
Yeah, I've been monitoring this. mysqld is (as you might imagine) under fairly heavy load, this being the highest amount of activity we've ever supported on a PRPnet server. Gary had three PRPnet clients running on "spare" cores of the server machine--well, under normal load they would be spare. :smile: I shut down one of them to give MySQL more headroom, and will keep an eye on things to shut down more if needed.

Edit: Okay, it looks like it's not quite enough--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.

[QUOTE=rogue;290463]gwnum is linked into the executable.[/QUOTE]
I guess what I was wondering, though, was whether it's possible to build both AVX and non-AVX versions of LLR using gwnum v27.3? I had understood that the non-AVX builds were based on v26.x, but odicin mentioned Rebirther's non-AVX x64 build being based on v27 so I wanted to make sure I had that correctly.

[QUOTE=mdettweiler;290464]Yeah, I've been monitoring this. mysqld is (as you might imagine) under fairly heavy load, this being the highest amount of activity we've ever supported on a PRPnet server. Gary had three PRPnet clients running on "spare" cores of the server machine--well, under normal load they would be spare. :smile: I shut down one of them to give MySQL more headroom, and will keep an eye on things to shut down more if needed.

Edit: Okay, it looks like it's not quite enough--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.[/QUOTE]

Have you optimized the tables ? Close the server and all deamons and restart mysql. Then start prpnet servers again.

Lennart

[QUOTE=mdettweiler;290465]I guess what I was wondering, though, was whether it's possible to build both AVX and non-AVX versions of LLR using gwnum v27.3? I had understood that the non-AVX builds were based on v26.x, but odicin mentioned Rebirther's non-AVX x64 build being based on v27 so I wanted to make sure I had that correctly.[/QUOTE]

The non avx version is built with gwnum 26.6. AVX with latest 27.3.

[QUOTE=Lennart;290468]Have you optimized the tables ? Close the server and all deamons and restart mysql. Then start prpnet servers again.

Lennart[/QUOTE]
Hmm, okay...I'll try to do that in 20 minutes or so when the next stats refresh minutes. (BTW: what do you mean by optimize the tables? I don't know too much about MySQL so I don't know how to do that; does simply restarting mysqld do it automatically?)

[B]Notice to all: all noprimeleftbehind.net PRPnet servers will be going down briefly at about 12:20 PM server time. The plan is to have them back online within 5-10 minutes at the max, and this should take care of the issues we've been seeing lately.[/B]

Okay, I restarted mysqld and all PRPnet servers are back online again. Hopefully that will do the trick. :smile:

Edit: looking at the stats from the last few hours, it seems that shutting down all the PRPnet clients running on the server did help, at least some--I notice a marked increase in the number of pairs/hour returned. Between that and restarting mysqld, we should be good to go now.

Edit #2: Ah yes, I'm seeing much less CPU usage from mysqld now--on the order of 15-50% CPU (on the Linux scale where 100%=1 core), versus 150-200% before the mysqld restart.

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

[QUOTE=Neo;290393]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[/QUOTE]

My offline batches are now done - no primes there. :down:

--
Lumiukko

[QUOTE=Neo;290393]Did we find a gap??
[/QUOTE]

Primeless gaps and higher densities of primes are 'normal', see for example the [url=http://www.rieselprime.de/NPLB/Drives/NPLB_MiniDrive4.htm]4th MiniDrive[/url].

[QUOTE=kar_bon;290496]Primeless gaps and higher densities of primes are 'normal', see for example the [url=http://www.rieselprime.de/NPLB/Drives/NPLB_MiniDrive4.htm]4th MiniDrive[/url].[/QUOTE]

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

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

Neo

[QUOTE=mdettweiler;290464]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.[/QUOTE]
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.

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! :smile:

[QUOTE=gd_barnes;290488]Is there some sort of "memory leak" so to speak of the CPU usage that causes this to "build up"?[/QUOTE]

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?

[QUOTE=AMDave;290538]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?[/QUOTE]

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

Lennart

[QUOTE=AMDave;290195] I'm just having a bad run. [/QUOTE]
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.

[QUOTE=Lennart;290566]No It is not removed from candidate table, only updated with some info on the candidate status.
.

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

[QUOTE=gd_barnes;290528]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! :smile:[/QUOTE]

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

Neo
AtP

[QUOTE=AMDave;290569]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. [/QUOTE]

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.

[QUOTE=Neo;290576]If it weren't for the extended mountain stage over @ Primegrid, things would be a tad bit closer. :boxer:

Neo
AtP[/QUOTE]
Phew, it really is close right now! :shock:
[code]
2 Raiders of the Lost Primes 23678
3 Aggie The Pew 23672
[/code]

[QUOTE=rogue;290581]...PrimeGrid or anyone else bundles software with PRPNet.[/QUOTE]Thanks for clearing that up. I was under a misconception that you packaged the bundle. I'll take it up with them.

Lennart must have gotten an expired w/u???. I hope it wasn't one of mine. :redface:

641*2^1018986-1

Neo
AtP

[QUOTE=Neo;290634]Lennart must have gotten an expired w/u???. I hope it wasn't one of mine. :redface:

641*2^1018986-1

Neo
AtP[/QUOTE]
Yeah, there were a fair amount of apparently abandoned tests working their way through the system the last few days...many I think were from Dave's various attempts to get his PRPnet clients working. It's not too big a deal to have those as long as there's not an insane amount being held up--they get expired in three days and sent out again. :smile:

I'm not exactly when this went down, but it appears AMD Users passed Free-DC for 2nd place in the all-time stats sometime in the least few days! Congratulations on a very big upset--Free-DC had a very big "buffer" built up from a few years back when we were their Project of the Month.

Now you guys get to tackle ROLP with nearly 30 million points...as they say, it's lonely at the top. :razz:

:smile: There seems to be a little battle now :smile:



Lennart

[QUOTE=mdettweiler;290640]... AMD Users passed Free-DC for 2nd place in the all-time stats sometime in the least few days! Congratulations on a very big upset--Free-DC had a very big "buffer" built up from a few years back when we were their Project of the Month.

Now you guys get to tackle ROLP with nearly 30 million points...as they say, it's lonely at the top. :razz:[/QUOTE]
I'm working on it just don't race in our hottest month (February) the air conditioner is running flat out and I have to power off the pharm to get some sleep at night :)

Thanks for the PM Lennart. :)

[QUOTE=Lennart;290654]:smile: There seems to be a little battle now :smile:



Lennart[/QUOTE]

[QUOTE=vaughan;290695]I'm working on it just don't race in our hottest month (February) the air conditioner is running flat out and I have to power off the pharm to get some sleep at night :)[/QUOTE]

There seem to be some great battles! The big questions are: Will Vaughan catch me for 3rd place in the individual battle and will AMD users catch ROLP for 3rd place in the team battle. Also, will Brian (PCZ) leave enough cores on there to stay ahead of both of us for 2nd place.

It's been a very long time since ROLP finished below 3rd place in a rally. That means we've had a great response with this one! :smile:


Gary

Gary or Max, can you please give me a link to where I can download a windows 32/64 client for this. The other site gives me a 7z that I can't unzip.

[QUOTE=Brucifer;290748]Gary or Max, can you please give me a link to where I can download a windows 32/64 client for this. The other site gives me a 7z that I can't unzip.[/QUOTE]

Can you install [URL="http://www.7-zip.org/download.html"]7-Zip[/URL]? That'd be the easiest way.
Here's a ZIP of the non-GPU Windows package that Lennart has: [url]http://tim.sorberafamily.com/prpclient-5.0.5-windows.zip[/url] The 7z algorithm is much more efficient for this file, being roughly 5 MB vs 20 MB.

kar_bon is about to pass Flatlander for 3rd spot in the over-all but MyDogBuster might get there before him.

Aggie The Pew have moved past XtremeSystems to grab 7th and BOINC Confederation will probably be right behind them in 8th by the end of the rally.

It's all happening.

And ... and .. we are finding Primes. :smile:

Can it get much better than this?

It's raining, so I released a new version of the [URL="http://www.noprimeleftbehind.net/stats/index.php"]rally pages[/URL] with more detail.

[QUOTE=AMDave;290841]It's raining, so I released a new version of the [URL="http://www.noprimeleftbehind.net/stats/index.php"]rally pages[/URL] with more detail.[/QUOTE]
Very cool, thanks! :grin: Having the score totals on both this and the earlier rally pages is nice because it allows an easy comparison between, say, someone's raw computational output in one rally versus another across different-size tests. (Previously we could compare the approximate total score output of two rallies by looking at the big spikes on the "All Time" graph on the Dashboarrd page, but not individual user or team totals.) It definitely tells a much larger story--I for instance claimed the same spot in the ranking (8th place) as in the previous rally, but cranked out 1.63 times more points than before.

Meanwhile, the rally is now complete--thanks to all who participated! We covered an amazing amount of ground--nearly n=50K worth (which is basically equivalent to n=100K on the 13th Drive, since this one covers twice the k-range). According to the [URL="http://www.noprimeleftbehind.net/stats/index.php?content=dashboard"]Dashboard page[/URL] on the stats website this was our second-biggest rally (in terms of computational power) of all time, nearly matching the output of our January 2011 rally (so far still the record-holder).

We're thinking of having another rally in late March, to make up for the dearth of them throughout 2011. :smile: We haven't finalized details yet, but stay tuned!

Welcome to all the new participants.

Well done to team Aggie The Pew. Someone did a very good job rallying support over there and the effort shows in the results.

The results also show that Vaughan didn't get much sleep last night while he landed the pass on Gary and it was just enough to pull team AMD Users past ROLP. An extensive effort. He'll be having a nap by now I hope :P

Congratulations everyone.

Yup zzzZZZ!!

I turned off all the dual cores and my quad Q6600s leaving the AMD hex cores and high end Intels running last night. With the a/c off the room only got to 32°C so it was OK I guess.

Looking forward to the next race.

[QUOTE=mdettweiler;290909]... We're thinking of having another rally in late March, to make up for the dearth of them throughout 2011. :smile: We haven't finalized details yet, but stay tuned![/QUOTE]
cough cough ... calendar ... cough cough ... March .... cough cough ... late ... cough cough :smile:

[QUOTE=AMDave;293854]cough cough ... calendar ... cough cough ... March .... cough cough ... late ... cough cough :smile:[/QUOTE]
Er, right...thanks for the reminder. :smile: At this point it's probably a bit late to do one in what's left of March (yes, my fault). PrimeGrid's next rally is April 1-3, and their next after that is May 5-10; so perhaps we could get one in in early-mid April. Would this work out well for people?

There's 2 options then

1 - [B]April 8 - 15[/B] : has some public holidays at the start of it, which may be good timing for some if they are staying home.

2 - [B]April 15 - 22[/B] : also looks good if some have plans to be away the previous week.

preferences anyone?

I nominate option 2.