Welcome to PrimeGrid's Birthday/Summer Solstice Challenge

ATTENTION: The primality program LLR is CPU intensive and the WU's for this Challenge are quite long; so, it is vital to have a stable system (solid hardware) with GOOD COOLING. Invalid WU's will not receive credit.

PrimeGrid's Challenge series continues with the "Birthday/Summer Solstice Challenge". We are celebrating PrimeGrid's 4th birthday on 12 June...culminating 21 June on the Summer Solstice. It seems fitting that the sun will shine the longest for the project with the longest WU. For those in the southern hemisphere, you'll get some extra heating running these WU's. :)

For a brief history of PrimeGrid in celebration of its Birthday, please see the next post.

A 9 day Challenge is being offered on PrimeGrid's Prime Sierpinski Problem (LLR) application. The duration is needed for the length of the WU's being tested. This is the first Challenge for PSP LLR and will be by far, the most demanding Challenge yet.

PSP LLR is currently testing n>7M which can produce a 2M+ digit prime. It will be like running a constant "stress test" on your computer for 9 days straight. Solid, well cleaned and cooled computers will be a necessity. Good hardware will "rule the day".

As for the psychology of the Challenge, patience will be the virtue needed if you wish to participate. :) The recent average WU is 62 hours long (range: 28hrs to 100hrs). So, you can see the importance of having stable hardware.

To participate in the Challenge, please select only the Prime Sierpinski Problem (LLR) project in your PrimeGrid preferences section. The challenge will begin 12 June 2009 05:45 UTC and end 21 June 2009 05:45 UTC. Application builds are available for Linux 32 bit and Windows 32 bit. These applications will be sent to 64 bit clients. As with all LLR application projects, there is no advantage of 64 bit over 32 bit.

ATTENTION: The primality program LLR is CPU intensive; so, it is vital to have a stable system with good cooling. It does not tolerate "even the slightest of errors." Please see this post for more details on how you can "stress test" your computer. WU's will take ~32 hours on fast/newer computers and 75+ hours on slower/older computers. If your computer is highly overclocked, please consider "stress testing" it. Sieving is an excellent alternative for computers that are not able to LLR. :)

Please, please, please make sure your machines are up to the task.

Time zone converter:

The World Clock - Time Zone Converter

NOTE: The countdown clock on the front page uses the host computer time. Therefore, if your computer time is off, so will the countdown clock. For precise timing, use the UTC Time in the data section to the left of the countdown clock.

Scoring Information

Scores will be kept for individuals and teams. Only work units issued AFTER 12 June 2009 05:45 UTC and received BEFORE 21 June 2009 05:45 UTC will be considered for credit. We will use the "prime score" method which is based on k,b,n values (k*b^n-1) to score the challenge. The only difference is that the primary and double checker of a WU will receive the same score.

Therefore, each completed WU will earn a unique score based on its k,b,n values. The higher the n, the higher the score. This is different than BOINC cobblestones! A quorum of 2 is NOT needed to award Challenge score - i.e. no double checker. Therefore, each returned result will earn a Challenge score. Please note that if the result is eventually declared invalid, the score will be removed.

For details on how the score is calculated, please see this thread.

At the Conclusion of the Challenge

We kindly ask users "moving on" to ABORT their WU's instead of DETACHING, RESETTING, or PAUSING.

ABORTING WU's allows them to be recycled immediately; thus a much faster "clean up" to the end of an LLR Challenge. DETACHING, RESETTING, and PAUSING WU's causes them to remain in limbo until they EXPIRE. Therefore, we must wait until WU's expire to send them out to be completed.

Please consider either completing what's in the queue or ABORTING them. Thank you. :)

About the Prime Sierpinski Problem

Waclaw Franciszek Sierpinski (14 March 1882 - 21 October 1969), a Polish mathematician, was known for outstanding contributions to set theory, number theory, theory of functions and topology. It is in number theory where we find the Sierpinski problem.

Basically, the Sierpinski problem is "What is the smallest Sierpinski number" and the prime Sierpinski problem is "What is the smallest 'prime' Sierpinski number?"

First we look at Proth numbers (named after the French mathematician Fran�ois Proth). A Proth number is a number of the form k*2^n+1 where k is odd, n is a positive integer, and 2^n>k.

A Sierpinski number is an odd k such that the Proth number k*2^n+1 is not prime for all n. For example, 3 is not a Sierpinski number because n=2 produces a prime number (3*2^2+1=13). In 1962, John Selfridge proved that 78,557 is a Sierpinski number...meaning he showed that for all n, 78557*2^n+1 was not prime.

Most number theorists believe that 78,557 is the smallest Sierpinski number, but it hasn't yet been proven. In order to prove it, it has to be shown that every single k less than 78,557 is not a Sierpinski number, and to do that, some n must be found that makes k*2^n+1 prime.

The smallest proven 'prime' Sierpinski number is 271,129. In order to prove it, it has to be shown that every single 'prime' k less than 271,129 is not a Sierpinski number, and to do that, some n must be found that makes k*2^n+1 prime.

Seventeen or Bust is working on the Sierpinski problem and the Prime Sierpinski Project is working on the 'prime' Sierpinski problem. The following k's remain for each project:

• Waclaw Franciszek Sierpinski (WIKI)
  
• Sierpinski number / The Sierpinski problem (WIKI)
  
• The Sierpinski problem (Prothsearch)
  

What is LLR?

The Lucas-Lehmer-Riesel (LLR) test is a primality test for numbers of the form N = k*2^n − 1, with 2^n > k. Also, LLR is a program developed by Jean Penn� that can run the LLR-tests. It includes the Proth test to perform +1 tests and PRP to test non base 2 numbers. See also:

• Lucas-Lehmer-Riesel test (WIKI)
  
• Download LLR by Jean Penné
  

(Edouard Lucas: 1842-1891, Derrick H. Lehmer: 1905-1991, Hans Riesel: born 1929).
____________

This is a “fluid” description based on bits and pieces I gathered in the forum. For those who have excellent memories or deft detective skills, please PM me with your suggestions, improvements, corrections, etc. Green sections are under active editing.

Introduction

PrimeGrid is a volunteer computing project searching for world record prime numbers. It is built on the Berkeley Open Infrastructure for Network Computing (BOINC) platform. It utilizes the spare CPU cycles of your computer that would otherwise go unused. Combine your CPU power with that of thousands of other computers around the world, and you have a very powerful prime finding “computer”. Anyone with a computer and an Internet connection can participate.

PrimeGrid's primary goal is to bring the excitement of prime finding to the “everyday” computer user. By simply downloading/installing BOINC and attaching to the PrimeGrid project, users can choose from a variety of prime forms to search. With a little patience, you may find a large prime or even a record prime and enter into Chris Caldwell's The Largest Known Primes Database as a Titan! :)

History

On 12 June 2005, at approximately 14:00 UTC, Message@Home (now PrimeGrid) opened account creation to 50 users. It was being run on Rytis’ home laptop. :)

Message@Home was developed as a test project for PerlBOINC, an attempt to implement the BOINC server system in the Perl programming language in order to bring BOINC server software to Windows. With the primary focus on PerlBOINC, a project was needed that provided a short WU with a standard consistent result.

The first project was Message7, and it attempted by “brute-force” to recover a message encoded with the md5 algorithm. The message was split into parts of 7 symbols of length, and each part was encoded with md5.

In August 2005, the RSA 640 Factoring Challenge application was added. Similar to Message7, this was an attempt by “brute-force” to factor the 640 digit RSA number. The Message7 application was discontinued.

On 1 September 2005, after a short contest to select a new project name, the PrimeGrid name was chosen from a variation of PrimeGrid@Home submitted by Heffed. He was awarded 999 cobblestones for his submission. :)

By November 2005, another effort factored the RSA 640 Challenge so PrimeGrid moved on to the RSA 768 Factoring Challenge. While the chances of solving the challenge remained infinitesimally small, it allowed for further development of PerlBOINC.

In March 2006, RSA 768 Factoring was abandoned for a new application, primegen. It was an attempt to build a sequential prime number database bringing PrimeGrid for the first time to the “prime finding” arena. The secondary goal was to also use this to help with the RSA Factoring Challenges. However, it was soon revealed that this effort too had an infinitesimally small chance of succeeding. Nevertheless, it “provided a short WU with a standard consistent result” which “allowed for further development of PerlBOINC”. However, the search for a “computing-time worthy” application was started.

In June 2006, dialog started with Riesel Sieve to bring their project to the BOINC community. Rytis provided PerlBOINC support and RS was successful in implementing their sieve as well as a prime finding (LLR) application. With collaboration from RS, PrimeGrid was able to implement the LLR application in partnership with another prime finding project, Twin Prime Search. In November 2006, the TPS LLR application was officially released at PrimeGrid. Less than two months later, January 2007, the record twin was found by the original manual project. PrimeGrid and TPS then advanced their search for even larger twin primes.

The summer of 2007 was very active as the Cullen and Woodall prime searches were launched. In the Fall, more prime searches were added through partnerships with the Prime Sierpinski Problem and 321 projects. Additionally, two sieves were added: the Prime Sierpinski Problem combined sieve which includes supporting the Seventeen or Bust sieve; and the combined Cullen/Woodall sieve.

In the Fall of 2007, PrimeGrid migrated some of its systems from PerlBOINC to standard BOINC software. However, many of the services still remain based on PerlBOINC.

2008 was a very busy year with the addition of

To date, PrimeGrid has directly discovered 6 mega primes, 3 Fermat Number divisors, and over 4000 titanic primes. Additionally, it has found several Arithmetic Progression records and has advanced the PSP and SoB combined sieve by over a decade.

The immediate future direction of PrimeGrid involves adding... :)

Timeline of Events and Milestones
(We would like to create an extensive timeline. Again, please PM me with your suggestions, improvements, corrections, etc.)

2005

• 12 June – Message@Home goes live with the Message7 application by opening account creation to 50 users
  
• 30 July – Rytis buys his first car, a 1997 Renault Megane
  
• August - the RSA 640 Factoring Challenge application is added and the Message7 application is discontinued
  
• 01 September - Message@Home changes name to PrimeGrid
  
• November - the RSA 768 Factoring Challenge application is added and the RSA 640 Factoring Challenge application is discontinued
  

2006

• March - the primegen application is added and the RSA 768 Factoring Challenge application is discontinued
  
• 26 November – Collaboration established with Twin Prime Search. TPS LLR application is added
  

2007

• 15 January - Eric Vautier of France finds a record twin prime through the manual TPS effort (2003663613*2^195000-1 and 2003663613*2^195000+1)
  
• July - Woodall LLR application is added
  
• August - Cullen LLR application is added
  
• 04 August - Lasse Mejling Andersen of Denmark finds a record Woodall Prime (2013992*2^2013992-1)
  
• 13 August - Stephen Kohlman of Canada finds a record Woodall Prime (2367906*2^2367906-1)
  
• 29 September – Combined Cullen/Woodall sieve application is added
  
• 13 October – PSP sieve application is added
  
• 18 November – Collaboration established with 321search. 321 LLR application is added
  
• 11 December – PSP LLR application is added
  
• 21 December - Matthew J. Thompson of the United States finds a record Woodall Mega Prime (3752948*2^3752948-1)
  

2008

• 29 January – Rytis buys his second car, 2002 Peugeot 307 2.0HDi, 79kw engine
  
• 29 February - Collaboration established with Proth Search
  
• 15 March - Challenge Series established
  
• 23 March – Dylan Bennett of Canada finds a 321 Mega Prime (3*2^4235414-1)
  
• 13 April – Project Staging Area added to help facilitate new prime searches into BOINC production
  
• 10 May - the primegen application is archived
  
• 28 August - Meebo chat room added to forum
  
• 27 December - Eric Ueda of the United States finds a Fermat Number divisor 651*2^476632+1 Divides F(476624)
  

2009

• 06 March - Senji Yamashita of Japan finds a Fermat Number divisor 519*2^567235+1 Divides F(567233)
  
• 31 March - Eric Embling of the United States finds a Fermat Number divisor 659*2^617815+1 Divides F(617813)
  
• 03 April – Andy Brady of the United States finds a 321 Mega Prime (3*2^5082306+1)
  
• 20 April – Dennis R. Gesker of the United States finds a Cullen Mega Prime (6328548*2^6328548+1)
  

Milestones

• Users with credit
  
  June 2005 - 50 users
  July 2005 - 100 users
  October 2005 - 500 users
  December 2005 - 1000 users
  July 2006 - 2000 users
  May 2007 - 5000 users
  December 2007 - 10,000 users
  July 2008 - 15,000 users
  January 2009 - 20,000 users

  
  

• BOINC Credit
  
  July 2005 - 100,000 cobblestones
  August 2005 - 200,000 cobblestones
  September 2005 - 500,000 cobblestones
  October 2005 - 1,000,000 cobblestones
  November 2005 - 2,000,000 cobblestones
  December 2005 - 5,000,000 cobblestones
  May 2006 - 10,000,000 cobblestones
  November 2006 - 20,000,000 cobblestones
  July 2007 - 50,000,000 cobblestones
  December 2007 - 100,000,000 cobblestones
  May 2008 - 200,000,000 cobblestones
  October 2008 - 400,000,000 cobblestones
  December 2008 - 500,000,000 cobblestones
  March 2009 - 750,000,000 cobblestones
  May 2009 - 1,000,000,000 cobblestones
  

____________

is this a problem to face again?

And as usual: One FB-DIMM in my Xeon throws a thermal trip event

EDAC MC0: UE row 1, channel-a= 0 channel-b= 1 labels "-": (Branch=0 DRAM-Bank=2 RDWR=Read RAS=10479 CAS=0 FATAL Err=0x4 (>Tmid Thermal event with intelligent throttling disabled))

Congratulations to Willy from BOINCstats for the first score :)
____________

How can he get 13933.97 challenge credits for one reported WU with claimed 705.65 credits and not validated ?

Please, can you explain this ?

i take a look in the participants there are only eight ?

We have been made aware that some teams have created group accounts where multiple people can attach and are using them to game user stats for challenge points. We do not encourage such behavior, and while we won't disclose the teams and accounts we know of right now, challenge points will not be awarded to them when the final results are published.

Continue at your own risk. If you have doubts about your account's eligibility, please contact me via PM or at admin@primegrid.com.
____________

We have been made aware that some teams have created group accounts where multiple people can attach and are using them to game user stats for challenge points. We do not encourage such behavior, and while we won't disclose the teams and accounts we know of right now, challenge points will not be awarded to them when the final results are published.

Team scores will not be affected in any way - afterall, this is a team account. What we're not endorsing is teams encouraging their members to join a single account to get high in the user stats - but that's actually a team that is getting listed in the user stats, so it isn't fair against other participants. So far two teams have done this (that we know of).

I know this is a bit of a grey area, because a lot of people are running BOINC on their friends and coworkers computers. We believe that it is acceptable behavior. We will not tolerate team actions to pool their members into a single account though.

All in all, we want to create fair competition, and group accounts are ruining the fun. So I'd like to ask all teams: please don't ruin user stats. If a lot of teams start doing this, this will probably destroy the challenge series...
____________

So this warning only applies to the user-stats and not the team stats?
If so it appears fair to me.
____________

I know this is a bit of a grey area, because a lot of people are running BOINC on their friends and coworkers computers. We believe that it is acceptable behavior. We will not tolerate team actions to pool their members into a single account though.

To be sure never Camal because YOU are not losing challenge points.....but I may as well as 36 others.....I can't compete with a team within a team for points....and if the others behind Booster feel the same way the project will loose more participants than what Booster is crunching! SO i SAY YOU ARE HURTING THE PROJECT NOT HELPING!

@Marty
is it fair if I have an PIII and you crunch with 8 or more machines ???
is it fair if you crunch with 8 machines and I crunch with a hole company ???

Rytis brought up an good idea, deleting all group and company accounts from user stats. But is it enough ???
Delete all user stats and concentrate on team-stats, that maybe is fair ...

just my 2 cents

btw: search what ever you want, Yeti was found by me ;)
____________
Sysadm@Nbg
my current lucky number: 113856050^65536 + 1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/

Come on folks, let's try not to get too emotional.

It is true that our Booster is not a user in the way that most people would interpret "user". Including myself. It is understandable that individuals don't like the idea of competing against groups of people. If I was in a top position I wouldn't like it either.

But there's no need for a witch hunt. The account is called "SG-Booster" and its profile said from the beginning that this is an account used by many people. We've never tried to make it look like an individual. And this accounts purpose never has been to mess up user stats. So far the problem has not turned up and nobody gave it a thought. Now it did turn up and it would be much better if we tried to figure out how to handle this instead of pointing fingers.

Exclude it from the user ranking, it's the fair thing to do in my opinion. Provided that similar accounts will be treated in the same way of course.

People crunching for SG on the Booster account or on their own accounts has no influence on the team stats. SG will win or not win this challenge regardless of the accounts the booster machines are attached to.

Prime Grids challenges used to be full of good-hearted competition. Nobody wants this to change. Let's be open and honest about these group accounts and take them out of the user stats. Starting with our Booster if you like.

My €0.02
Peter
____________
There are only 10 kinds of people - those who understand binary and those who don't

From my point of view it is sad that the points rewarded for a pspLLR-WU are capped at 800.

I was about to change the subject, but Roadrunner beat me to it. 800 points for a 40-hour WU seems like a low and rather arbitrary number. I can see where sieving might need an arbitrary number, but at 190 points for a 321 sieve WU, I can get 2-4 times as much BOINC credit for those (depending on 32 vs 64-bit) as for these PSP WUs. Even the little PPS LLR WUs give me 50-60% more credit for the time than PSP.

The prime score method seems like a much better way of generating a fair BOINC credit for LLR WUs. In particular, about 1/10 of the prime score seems like a fair BOINC credit score to me, at least for these PSP WUs, as it is fairly close to the credit my client claimed, and also close to what I saw an i7 claim.

The prime score method seems like a much better way of generating a fair BOINC credit for LLR WUs. In particular, about 1/10 of the prime score seems like a fair BOINC credit score to me, at least for these PSP WUs, as it is fairly close to the credit my client claimed, and also close to what I saw an i7 claim.

Prime Grids challenges used to be full of good-hearted competition. Nobody wants this to change. Let's be open and honest about these group accounts and take them out of the user stats. Starting with our Booster if you like.

now this is getting funky - those guys,who managed to put this race into misery, are trying to tell the rest of the participants how to act now?

SONST NOCH WAS?

From my point of view it is sad that the points rewarded for a pspLLR-WU are capped at 800.

looks like the credit limit is history:

110089900 74744607 12 Jun 2009 6:04:26 UTC 14 Jun 2009 19:09:02 UTC Completed and validated 192,713.05 677.83 1,057.53

Yes, the limit was an oversight. We apologize. It has been increased to 1200. We'll make further adjustments as necessary. Please note that this only affected cobblestones and not Challenge Score.

so you will update those results already validated and being hit by that 800-cap?

Yes, the limit was an oversight. We apologize. It has been increased to 1200. We'll make further adjustments as necessary. Please note that this only affected cobblestones and not Challenge Score.

so you will update those results already validated and being hit by that 800-cap?

That question arose to me also...

I'd like to see how I'm doing, but when I select standings, all I can see is the top three participants and the top three teams.

Most Quadcores and Dual-Quads are claiming more than 1000 credits (and are hitting the granted credit limit then, because granted ~ 1.2 claimed) only because they are experiencing a slowdown due to memory bandwidth problems (that's also the reason why some AMD Phenom II processors are that much faster than Intel this time). For example, my Q9450@3.2GHz took 28 hours for a single test WU before the challenge, claiming ~750 credits, but takes 37 hours and claims ~1000 when running 4 WUs. So I think the 1200 limit is OK although it will be hit quite often, because those hosts only need so much time due to "bad hardware". ;)
____________

Another problem occured... :|

Aborting task psp_llr_33330161_0: exceeded CPU time limit 282107.902443

Two Dual-Quads had such a slowdown due to memory bandwith (I guess) that their WUs exceeded the rsc_fpops_bound and were aborted after more than 3 days runtime, what is about 1/8 year of CPU time. :O
____________

Thanks, John, for the credit, and thanks, pschoefer, for the testing!

I'm going to try running a few PPS LLRs in parallel with the PSPs on my quad and see if I get similar PSP throughput with more total results.

Most Quadcores and Dual-Quads are claiming more than 1000 credits (and are hitting the granted credit limit then, because granted ~ 1.2 claimed) only because they are experiencing a slowdown due to memory bandwidth problems (that's also the reason why some AMD Phenom II processors are that much faster than Intel this time). For example, my Q9450@3.2GHz took 28 hours for a single test WU before the challenge, claiming ~750 credits, but takes 37 hours and claims ~1000 when running 4 WUs. So I think the 1200 limit is OK although it will be hit quite often, because those hosts only need so much time due to "bad hardware". ;)

Is this a real Pentium D or a Pentium 4 with HyperThreading?
Ought to be a Pentium D regarding the L2-Cache-size.

Aborting task psp_llr_33330161_0: exceeded CPU time limit 282107.902443

Is this a real Pentium D ?
Ought to be a Pentium D regarding the L2-Cache-size.

of course - and it was running 2 LLRs at a time..

I think i fire up my old Pentium 4 2.6 with HyperThreading as soon as i get home. Let us see what this client comes up to.

in HT-mode? little chance to finish within the challenge..

It is very mysterious to me why the Core Duo is that slow.

should i guess?

you got 2+1 GB and it is not running in dual-channel mode.

i got some E7200s (2.53 GHz) which are running with 2*1GB on one channel and need ~218 ksecs.. :(

64-bit vs 32-bit makes no difference on LLR.

An HT 2.6 P4 should run in the 100-120 hour range, resulting in 2 to 4 workunits completed within the challenge if running the full 9 days 24/7.

About 200K is exactly where my 3.0Ghz Pent D falls also. While it may seem strange that your E6550 ran about the same, I think this is likely due to two reasons. First, raw Ghz matters greatly for LLR, and the E6550 gives up about .7 Ghz in comparison (and the T8300 is even slightly faster here than either E6xxx). Second, it is not unusual to have a fair sized range in return times. So, the 197k for the E6550 might be its upper bound (and likely more of a lower bound for the Pent D's), with similar times with your E6400 more typical on the lower end--evidence for this is in the claimed/awarded credits.

The time for the T2600 is much too long. Given than this is a laptop, I would strongly suspect either 1) dropping into standby mode for power saving or 2) throttling back due to overheating.
____________
141941*2^4299438-1 is prime!

Dear Admins ;-)

as it seems to happen pretty frequently now that WUs are retracted from the challenge scores
(presumably for being determined invalid, happened to me at least three times now according to credit history),
is there any way to check which WUs were affected, and if so, where would I look?

I can´t see any WUs in my tasks list that are marked invalid, only one WU
Completed, validation inconclusive
under "pending" and 5 WUs under "error" (all of which I know about and which shouldn´t have been scored anyway).

Please enlighten me, because I may have to do something with the affected machines ...

Thx
Kai

We had some database issues and some workunits failed to show up and count. All should be fine now.
____________

(...)
Core Duo T2600 1667/667 MHz (2 MB L2) @ 82°C with 2x1 GB DDR2-667 482k runtime projected...
(...)

Yes i locked it down to 1667 because i do NOT want it to throttle since throttling doesn't help .
And since this is a Lenovo notebook i have access to all the temperature sensors. The only thing that is in the same temperature-region as the CPU is the ATI FireGL V5200 with ~77°C, the other sensors read around 38°C give or take one or two degrees - nothing bad here.
I am concerned about the multiple "killed" in the stderr.out - maybe there are some other (boinc)-problems?

(...)
Core Duo T2600 1667/667 MHz (2 MB L2) @ 82°C with 2x1 GB DDR2-667 482k runtime projected...
(...)

Hmpf 483k and unconclusive.
I am very disappointed with this one.
And no it does not drop into stand by and throttles not - the CPU-temperature is way to low for the latter one.

So it is for sure a sitting duck and i should consider buying a Core 2 Duo for around 120 Euro to swap out the Core Duo.
I haven't a Pentium M available for now to test but if yours is running in the same region this CPU is a nogo for this application.
____________

So it is for sure a sitting duck and i should consider buying a Core 2 Duo for around 120 Euro to swap out the Core Duo.
I haven't a Pentium M available for now to test but if yours is running in the same region this CPU is a nogo for this application.

For those interested in such things: here are some PSP LLR times across different CPUs from the challenge so far (*note: n=number of completed work units):

CPU & Speed..............Cores....RAM......OS........32 or 64-bit......Avg. Time (per core) in Hours

Pentium M 1.73 Ghz.......1.........1GB.....XP Pro........32..............144 (n=1)

P4 Northwood 2.00 Ghz...1.........1GB.....XP Pro........32................80 (n=4)
P4 Northwood 2.40 Ghz...1.........1GB.....XP Pro........32................72 (n=35)
P4 Northwood 2.53 Ghz...1.........1GB.....XP Pro........32................63 (n=2)
P4 Northwood 2.80 Ghz...1.........1GB.....XP Pro........32................69 (n=2)

P4 Northwood 2.60 Ghz...2(HT)...1GB.....XP Pro........32..............109 (n=10)
P4 Northwood 3.06 Ghz...2(HT)...1GB.....XP Pro........32..............113 (n=1)
P4 Northwood 3.00 Ghz...2(HT)...2GB.....Win 2000....32...............95 (n=1)
P4 Northwood 3.00 Ghz...2(HT)...1GB.....XP Pro........32...............97 (n=6)
P4 Cedar Mill 3.00 Ghz....2(HT)...1GB.....XP Pro........32.............102 (n=2)

Xeon MP 3.16 Ghz..........8(HT)...8GB...Ubuntu 9.04...64............105 (n=8)

Pent D 830 3.00 Ghz.......2..........4GB.....XP Pro........32.............59 (n=4)

C2Q 6600 2.40 Ghz........4.........3GB.....Vista HP.......32.............48 (n=4)
C2Q 6600 2.40 Ghz........4.........2GB.....XP Pro.........32.............47 (n=12)
C2D E6750 2.66 Ghz.......2.........2GB.....XP Pro.........32.............38 (n=6)
C2D E8400 3.00 Ghz.......2.........2GB.....XP Pro.........32.............34 (n=8)
C2D E8400 3.00 Ghz.......2.........2GB.....Win 7..........64.............34 (n=8)
C2D T8100 2.10 Ghz.......2.........2GB.....Vista HP......32.............49 (n=6)

Athlon X2 3800+ 2.00 Ghz...2.....2GB......XP Home....32.............81 (n=3)
Athlon X2 4200+ 2.20 Ghz...3.....3GB......XP Media....32.............78 (n=2)
Athlon X2 5600+ 2.80 Ghz...2.....2GB......Vista HP.....32.............59 (n=4)


**Vista HP = Vista Home Premium


So, some key things seem evident:
1) Within an architecture (i.e., Netburst, Core 2, etc.), the raw cpu speed is most important.
2) Hyperthreading performs extremely poorly.
3) OS, RAM, and FSB speed do not appear to have any effect. (FSB not in tables, but varies across cpu's shown considerably).
____________
141941*2^4299438-1 is prime!

Re: computation speed

I have a Q6600 with a Nvidia Nforce chipset mobo, PSP LLR times are very bad, 252k - 282k seconds.

Another Q6600 with an Intel chipset mobo, SLOWER ram, has much faster times, 172k - 182k seconds.

Another reason I hate Nvidia.

Northbridge chipset is key when it comes to multicore machines in LLR.

I am not sure about this...you may be right on the northbridge issue. But, I have another Q6600 that I did not report in the table that reports similar times to yours with the Nvidia chipset (around 260k). However, it is identical to the the Q6600 in the table with the Vista OS in all respects (we bought two identical machines at the same time last year). I did not put it in the table because something went wrong with the Vista install last month (several drivers corrupted, etc.--it is a remote machine 700 miles away that I will do a reinstall on later this summer), and I attributed the slower times to this issue.

Clearly, the mid 200k times are off...anyone else seeing this sort of issue?


____________
141941*2^4299438-1 is prime!

The board I have is a 680i nforce.

Like you, at first I thought it was an issue with drivers in XP32, so I booted into linux64, same thing, 70 hours to completion.

That box is back on sieving.

Also runs AP26 well, application does not require more memory than the CPU's onboard cache :)

AAAGGGGGGHHHHH!!!! Thunderstorm...several hours without power!

...looks like it is a freezer-clearing grill-out this afternoon. :(


____________
141941*2^4299438-1 is prime!

Just under 16 hours remain!

This post is about 36 hours late. :( That's about when the average host was receiving its last WU that could be completed by the end of the Challenge. We are well beyond the lowering cache phase...but it was not an issue for this Challenge anyway. Nevertheless, make sure you have updated your clients to get those completed WU's reported and counted.

While this will be a small cleanup in terms of WU numbers, it will be very long in terms of time. We are hoping to have it finalized before the next Challenge. If everyone can remember to either complete their cache or ABORT their WU's, then we should be able to finalize in about 12 days. Otherwise, we're looking at 24-36 days.

If you have the resources, please consider helping out. However, we fully understand the need/desire to "move on" as this has been a VERY demanding Challenge.

Good Luck to everyone as we finish these last 16 hours...

At the Conclusion of the Challenge

We kindly ask users "moving on" to ABORT their WU's instead of DETACHING, RESETTING, or PAUSING.

ABORTING WU's allows them to be recycled immediately; thus a much faster "clean up" to the end of an LLR Challenge. DETACHING, RESETTING, and PAUSING WU's causes them to remain in limbo until they EXPIRE. Therefore, we must wait until WU's expire to send them out to be completed.

Please consider either COMPLETING what's in the queue or ABORTING them. Thank you. :)

____________

Found a little bug on the preferences page which is most unfortunate.

I would have liked to cease downloading new tasks, so I selected all options off on my preferences, hit update preferences, that was okay.

When I checked my tasks a few hours later, I have a large number of new tasks, all various types (pps_llr_extended, llrCUL, psp_sr2sieve, 321_sr2sieve, llrWOO, llr321, psp_llr), instead of having a reducing number of tasks, I am now running 30 tasks which is hampering the computation of the psp_llr that I would have liked to have finished off for the challenge.

Seems when one updates the preferences with nothing checked, it basically turns everything on, when I went to check preferences again all LLR were turned on, and the sieving.

I am about 8 hours away from my home computer, no chance of aborting the now accumulated unwanted tasks.

P.S. My work around was to select the Cullen/Woodall (Sieve) as no tasks are available.