The GCW-LLR project is now live on BOINC. You may select it on the PrimeGrid preferences page, same as any other subproject.

The tasks are, initially, very short. On my Haswell, they're taking about 90 seconds each, with four running simultaneously (one on each core.) Due to the small tasks, they don't do multi-threading efficiently, so I recommend that you leave them single threaded.

There's a new badge for GCW-LLR.

Initially, we are double checking the work that was previously done on PRPNet, so there's residues for most of the tasks currently being sent out. Most tasks will therefore validate within a minute or two since you won't have to wait for wingmen.

____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

So far, one person has a silver badge and another 12 have bronze badges.

20720 tasks have been validated so far (not including the fake double check tasks), of which 7848 are from the silver badge holder.

The rest of us have to step it up or that poor soul is going to run out of wingmen! :)

(Actually, that's not really true because at this point most tasks are double checks of the PRPnet work, so no wingman is necessary. Including the fake double check tasks, 39984 tasks have been validated.)
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

(Actually, that's not really true because at this point most tasks are double checks of the PRPnet work, so no wingman is necessary. Including the fake double check tasks, 39984 tasks have been validated.)

(Actually, that's not really true because at this point most tasks are double checks of the PRPnet work, so no wingman is necessary. Including the fake double check tasks, 39984 tasks have been validated.)

How many double check tasks are there?

At most 172877, though it's possible some of those candidates were sieved out.

(Actually, that's not really true because at this point most tasks are double checks of the PRPnet work, so no wingman is necessary. Including the fake double check tasks, 39984 tasks have been validated.)

How many double check tasks are there?

Funny you should ask that. I was just looking up the details on the double check.

Each base is different. For bases 13 through 101, PRPNet testing ended at n=1M. However, while PRPNet testing was done to a specific n for each base, on BOINC we're sending tasks out in size order. For base 13, that means the DC ends at around 1.1 million digits, while for base 101 it ends at around 2.0 million digits.

Base 109 stops at about n=828K (about 1.7 million digits). Bases 116 and 121 end at n=500K (about 1.0 million digits.)

Some of you have seen some tasks that are not double checks. That's because some residues are missing, particularly on base 13.

There's 172877 total residues from PRPNet to be double checked.

Phase 1 of the GCW sieve was sufficient to efficiently LLR test GCW candidates of up to 4 million digits. N varies by base, of course.

The full GCW sieve, when completed, will be sufficient for testing GCW candidates of up to 15 million digits. The sieve file therefore contains all candidates of up to 15 million digits. Why 15 million digits? That's approximately the same size as the largest candidates in the SOB, PSP, ESP, and TRP sieve files. For those base 2 projects, that corresponds to n=50 million.

Hopefully we'll find primes for the 14 remaining bases long before we get anywhere close to testing 15 million digit numbers.

Also, when a prime is found, further LLR testing as well as sieving will be stopped on that base.

EDIT: I probably should have read the next message before replying. :)
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

At this rate, how long would it take to do all double checks?
No need for exact calculation like SoB or PSP, estimate is ok.
Not all participants are chasing nice new badge(s)...yet, and tasks are getting bigger.
Weeks, months?
____________My statsBadge score: 1*1 + 5*2 + 8*9 + 9*6 + 12*3 = 173

Things certainly have slowed down overnight. Units on my main system are estimating around 45 minutes and it wont be long before I wonder if multi-threading is worth trying.

On assumption more credit = bigger unit, the higher scoring units I've done are 320k FFT, so I think this is bigger than MEGA.

What's the project name needed for app_config? I'm wondering if -t 2 is already worth trying.

Edit: on "bigger than MEGA" the front page suggests GCW is still smaller in prime size, but if my memory isn't too bad before my 1st coffee, MEGA was 256k FFT. Something to do with the number bases perhaps? In performance terms, the FFT size is more interesting than numeric size.

Why estimate? I will rerun an existing task at some point and get data that way. My thinking is, 320k is already past the cpu cache size of most, so we might be entering into the zone where multi-threads starts to help.

At this rate, how long would it take to do all double checks?
No need for exact calculation like SoB or PSP, estimate is ok.
Not all participants are chasing nice new badge(s)...yet, and tasks are getting bigger.
Weeks, months?

I don't know. It's really hard to guess on questions like that because the tasks grow in duration so rapidly as the size increases. That's the reason I like to do the exact calculations; the estimates are terribly inaccurate. Unfortunately, the way the data is structured for GCW makes it a lot more complicated to do those calculations. I'm guessing we'll get to 1 million digits, where the double check ends for some bases, fairly quickly. Getting to 2 million digits should take a lot longer not only because the numbers are larger but because as we complete the double check on each base we need to do more and more tasks.

So, my really, really, rough guess would be another 2 days to get to 1 million digits, and maybe 2 weeks to get to 2 million. I wouldn't be surprised if those numbers are off by a lot.

At what size can we expect the task size to "stabilize"? Along the lines of SR5 or larger?

For projects where n is increasing, which includes both SR5 and GCW, it never really does stabilize. The numbers grow rapidly over time. They just grow more rapidly at the beginning. That's also true, albeit to a lesser extent, with projects where b is growing (i.e., GFN). The only really stable type of projects are those where it's only k that is increasing, and the only project like that is SGS.

The answer to your question is therefore mostly dependent on how much computer power is kept on GCW. It will stabilize when people start moving computers to other projects. So the most likely answer to your question is probably, "At the start of the next challenge."
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Was that single threaded test running on one core with three cores idle, or were there 4 copies running independently on all 4 cores (simulating normal BOINC utilization)?
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Running 4 single tasks at the same time took 2263s average. In throughput, that puts 2x2t as 5.4% slower, and 1x4t as 9.5% slower.

I'd expect things to swing in the favour of more threads as the size increases, but at 288k FFT, we're not there yet.

Note above is based on my specific i5 system. Results may vary with CPU model and ram configuration. As i5, I'd expect it to hit the cache penalty earlier than an i7 would, but the faster than average ram would help offset that.

I must have the wrong project selected
Generalized Cullen/Woodal Prime Search LLR
Or is it this one: Generalized Cullen/Woodall Sieve (I guess this one)
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community.

<app_config>
<app>
<name>llrGCW</name>
<max_concurrent>4</max_concurrent>
<fraction_done_exact/>
</app>
<app_version>
<app_name>llrGCW</app_name>
<cmdline>-t 8</cmdline>
<avg_ncpus>8</avg_ncpus>
<max_ncpus>8</max_ncpus>
</app_version>
</app_config>
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community.

Sorry I have been looking, still cannot find if HT should be on with multi-threads of off.
I always have trouble with setting up new PG Projects.
Sorry
Not really a Math person and that might be why I have a hard time.
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community.

Edit: This reply is a mistake, see apology below. Leaving so quoted messages below aren't confusing.

Infinitely unhelpful and bordering on rude given I'm trying to donate to this project. Search for HT on this thread. Many HTTP and a few overnight's and ZERO HT or mention or hyper threading. My HT is the first one you'll find.

Plus, this forum is the link that the "Generalized Cullen/Woodall Prime Search (Sieve)" It's a sieve for an LLR task. Sieve or LLR? I'm not a bleeping expert on primes, I just want to know how to setup my damn system.

And, still no direct answer. Wouldn't have been easier for you to say:
HT or No HT?

Infinitely unhelpful and bordering on rude given I'm trying to donate to this project. Search for HT on this thread. Many HTTP and a few overnight's and ZERO HT or mention or hyper threading. My HT is the first one you'll find.

Plus, this forum is the link that the "Generalized Cullen/Woodall Prime Search (Sieve)" It's a sieve for an LLR task. Sieve or LLR? I'm not a bleeping expert on primes, I just want to know how to setup my damn system.

And, still no direct answer. Wouldn't have been easier for you to say:
HT or No HT?

It's almost easier to switch back to WCG.

Your call on a friendly direct answer or not.

My apologies for this rant. I got the messages screwed up and thought this was a reply to my HT question.

Sorry I have been looking, still cannot find if HT should be on with multi-threads of off.
I always have trouble with setting up new PG Projects.
Sorry
Not really a Math person and that might be why I have a hard time.

Aha. Not how does LLR work with MT but how does HT works with MT.
*Generally, there is no benefit to have HT on while doing LLR tasks (yes, this thread is about LLR). I would say this apply to MT scenario as well.

* I can imagine some benefit with single-core, HT CPU.
Running 6-core with HT would probably hit bottle-neck on memory.
Xeon CPU might be a bit different, have no experience with latest AMD Ryzen.
And it depends on number of memory channels, RAM speed.
Most probably slower on multi-socket CPUs systems.
FFT size plays some role as well - so generally no HT while doing LLR, be it single-threaded or MT task.
____________My statsBadge score: 1*1 + 5*2 + 8*9 + 9*6 + 12*3 = 173

On the HT question, it was better turned off in the single thread era, but testing in another thread was suggesting a possible not insignificant throughput improvement in using those extra threads. It isn't giving more peak potential, just offsetting some of the losses so you get closer to ideal scaling. Further testing is required to understand where it will help or not.

It hasn't been long enough yet for the stats to be generated. Also, even when they are, the task sizes are growing so quickly that they're not going to provide meaningful information for a few days. The project only started yesterday and some of the systems take a while to ramp up.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Another question: Under http://www.primegrid.com/show_badges.php?userid=388469, I don't see a GCW LLR line. Yes, I don't have any badge right now since none of my tasks completed. I don't know if that is the reason, or just that the new project didn't make it to that page, yet. If the former, I think there is value in listing the projects in there for which the user has no badge, but has tasks in progress and/or pending credits. The CurrentCredit and CurrentBadge would be blank, but all other fields would have useful info.

Another question: Under http://www.primegrid.com/show_badges.php?userid=388469, I don't see a GCW LLR line. Yes, I don't have any badge right now since none of my tasks completed. I don't know if that is the reason, or just that the new project didn't make it to that page, yet. If the former, I think there is value in listing the projects in there for which the user has no badge, but has tasks in progress and/or pending credits. The CurrentCredit and CurrentBadge would be blank, but all other fields would have useful info.

It will show up as soon as you get credit. Thanks for your suggestion, but I don't know how feasible it is, so no promises.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Another question: Under http://www.primegrid.com/show_badges.php?userid=388469, I don't see a GCW LLR line. Yes, I don't have any badge right now since none of my tasks completed. I don't know if that is the reason, or just that the new project didn't make it to that page, yet. If the former, I think there is value in listing the projects in there for which the user has no badge, but has tasks in progress and/or pending credits. The CurrentCredit and CurrentBadge would be blank, but all other fields would have useful info.

It will show up as soon as you get credit. Thanks for your suggestion, but I don't know how feasible it is, so no promises.

It turns out that's a deliberate design choice. We don't want rows showing with merely pending or in-progress tasks. Amongst other reasons, there's no guarantee that credit will actually be granted, and we don't want rows blinking in and out of existence.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

I turned on the new app yesterday, and today i have BOINCstats credit for it. I run WUProp, and the new app doesn't show up. It's early days. If there is an error here, i've no idea where it might be - PrimeGrid or WUProp. I expect to see WUProp (counts hours contributed) before BOINCStats, since WUProp works on an every six hours, whereas BOINCStats waits until units are validated and are awarded credit. I've checked. The machine running the new app has gotten credit, and in the right amount...

I turned on the new app yesterday, and today i have BOINCstats credit for it. I run WUProp, and the new app doesn't show up. It's early days. If there is an error here, i've no idea where it might be - PrimeGrid or WUProp. I expect to see WUProp (counts hours contributed) before BOINCStats, since WUProp works on an every six hours, whereas BOINCStats waits until units are validated and are awarded credit. I've checked. The machine running the new app has gotten credit, and in the right amount...

Stephen.

Its a wuprop problem. You'll need to take it up with them. It's already been discussed on their forums.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

* base 116 has sent out all of its double check tasks and is now sending out leading edge tasks. Base 121 isn't far behind.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

With the bigger units I think I'll revisit the thread scaling testing later. A quick look at some recent units shows FFTs up to 480k. I suspect 2x2 might be faster than 4x1 now based on expected cache usage.

Even without such data, I've decided to go -t 4 on my quads purely to keep unit times down, even if it means I'm not maximising throughput.

With the bigger units I think I'll revisit the thread scaling testing later. A quick look at some recent units shows FFTs up to 480k. I suspect 2x2 might be faster than 4x1 now based on expected cache usage.

Even without such data, I've decided to go -t 4 on my quads purely to keep unit times down, even if it means I'm not maximising throughput.

I've decided to do the same thing. Since we're now starting to get leading edge tasks with real wingmen, I'd rather be the guy who finishes first, even if I'm doing a couple fewer tasks per day. Someone is going to find a prime sooner or later. And, of course, when the tasks get large enough, multithreading will be more efficient as well.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

With the bigger units I think I'll revisit the thread scaling testing later. A quick look at some recent units shows FFTs up to 480k. I suspect 2x2 might be faster than 4x1 now based on expected cache usage.

Even without such data, I've decided to go -t 4 on my quads purely to keep unit times down, even if it means I'm not maximising throughput.

I've decided to do the same thing. Since we're now starting to get leading edge tasks with real wingmen, I'd rather be the guy who finishes first, even if I'm doing a couple fewer tasks per day. Someone is going to find a prime sooner or later. And, of course, when the tasks get large enough, multithreading will be more efficient as well.

Likewise. Increased chance of being the original finder and shorter run times more than offsets a small drop in throughput, and tasks will soon enough be large enough that throughput benefits.
____________

With the bigger units I think I'll revisit the thread scaling testing later. A quick look at some recent units shows FFTs up to 480k. I suspect 2x2 might be faster than 4x1 now based on expected cache usage.

Even without such data, I've decided to go -t 4 on my quads purely to keep unit times down, even if it means I'm not maximising throughput.

I've decided to do the same thing. Since we're now starting to get leading edge tasks with real wingmen, I'd rather be the guy who finishes first, even if I'm doing a couple fewer tasks per day. Someone is going to find a prime sooner or later. And, of course, when the tasks get large enough, multithreading will be more efficient as well.

Definitely, with my i5-4670K, it was the right time to switch. Equivalent tasks (based on credit) are running more than 4 times faster running with -t 4 than when running 4 separate tasks.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Michael, this is awesome. Thanks! I was just gonna make time this morning to read through the lengthy http://www.primegrid.com/forum_thread.php?id=7348, and create my own, but this helps a bunch! I guess one remaining question would be, although unrelated to this thread: What other app names could be used to replace llrGCW above in the app_config.xml? In other words, what other apps can take in a "-t n" param that are currently active?

Michael, this is awesome. Thanks! I was just gonna make time this morning to read through the lengthy http://www.primegrid.com/forum_thread.php?id=7348, and create my own, but this helps a bunch! I guess one remaining question would be, although unrelated to this thread: What other app names could be used to replace llrGCW above in the app_config.xml? In other words, what other apps can take in a "-t n" param that are currently active?

Take a look here. Anything that starts with "llr" is up for multithread grabs.

Michael, this is awesome. Thanks! I was just gonna make time this morning to read through the lengthy http://www.primegrid.com/forum_thread.php?id=7348, and create my own, but this helps a bunch! I guess one remaining question would be, although unrelated to this thread: What other app names could be used to replace llrGCW above in the app_config.xml? In other words, what other apps can take in a "-t n" param that are currently active?

You already received the link to the app name list. The only thing I would add is that you probably don't want to use multithreading on PPS-MEGA or smaller (PPS, PPSE, SGS). It's inefficient with smaller numbers. Furthermore, performance varies a lot depending on the size of the number, CPU and cache configuration, etc.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

It took some rather insane SQL-fu, but I came up with a way to generate reasonable double check statistics for GCW. While the database query is ridiculously long and complicated, it runs very quickly, which is the important thing.

b is self explanatory.
Candidates is the count of all the numbers that are part of the double check.
Residues is the count of residues for those candidates. As you can see, about 18000 candidates didn't have any residues.
Done is the number of candidates that have been proven prime or composite. In BOINC terms, that means at least two tasks have been validated.
Work is the amount of computing power required. "1.0" is the amount of computing power necessary to test a single 1-million digit number twice. This implies that 0.5 is the amount of computing power required to test a 1-million digit candidate if a residue already exists.
Work % is, for each base, its portion of the total work.
Done % is, for each base, how much is completed (validated) out of the total work.

As of right now, we're 44% done. Note that done means "validated". If you look at what's been sent out, we're at a higher percentage. I may add that data to the chart later.

Note that unlike the PSP and SoB double checks, we're still sieving GCW. It is about 100% likely that as the double check proceeds, the sieve will remove candidates that are part of the double check. The statistics in this chart take into account unprocessed candidates that have been removed by the sieve. As a result, as I publish updated versions of this chart, you will notice that some of the numbers will drop over time. "Candidates", "residues", and "work" will slowly drop as factors are found, and "work %" will fluctuate.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

We have passed the end of the double check (n=1M) for base 29. New leading edge tasks are now being sent for base 29. That's the 5th base to reach the end of the double check.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

The 6th base, 41, has now progressed beyond the double check of PRPNet work and is sending out new leading edge tasks. 8 bases are still sending out double check tasks.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

The double check of prior PRPNet work is now 85% complete and another base, 47, is past where the search ended on PRPNet and is sending out new leading edge tasks. Seven bases are sending out leading edge tasks and 7 are sending out double check tasks.

Base 109 is now beyond the double check and is sending out new leading edge work. Six of the 14 bases are still double checking prior PRPNet work.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Base 49 is also now beyond the double check point and is sending out new leading edge tasks. Five bases (53, 55, 69, 73, and 101) still have more PRPNet candidates to double check.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Base 53 has surpassed its double check high water mark and is sending out leading edge tasks. Four bases remain in double check territory: 55, 69, 73, and 101.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

The double check is now 96% completed. Only 3 bases are still sending out new double check tasks while 11 are sending out leading edge work. Of those 11, 6 are completely done with the double check (every candidates' tasks are complete), while 5 still have some DC tasks in progress.

So far so good - tasks have 5 days deadline.
Any plan ye on this as we go forward?

Looks like I overlooked this question from a few weeks ago. The deadline is 4 days (plus a 25 hour grace period), and yes, that will increase as the numbers get larger. 4 days is sufficient for fairly large numbers, however, so it will stay at 4 days for the entire double check, and then for a while after that as well. The maximum extended deadline for these tasks is 30 days. (For more information about extended deadlines, please read this forum discussion.)
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Base 69 has surpassed n=1,000,000 and is now sending out leading edge tasks. Of the 14 bases, only 73 and 101 remain exclusively sending double check tasks.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Out of over 150 thousand candidates originally processed on PRPNet, less than 400 remain to be verified. Only base 101 is still sending out new double check tasks, although there's still some double check tasks in other bases that are in progress (3 in base 69, and 1 each in bases 73 and 109).
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

What was the rate of wrong residues in PRPNet? Was it about the same level as you see now on BOINC (GCW-LLR), or higher, or lower?

In case it is not clear, I am referring to workflow results that have been returned in the normal and correct way, but turn out to be flawed once enough double checks have been performed to establish the "true" value.

What was the rate of wrong residues in PRPNet? Was it about the same level as you see now on BOINC (GCW-LLR), or higher, or lower?

In case it is not clear, I am referring to workflow results that have been returned in the normal and correct way, but turn out to be flawed once enough double checks have been performed to establish the "true" value.

/JeppeSN

Interesting question. As it happens, there is enough information available to get the answer.

There were 155905 residues from PRPNet for which we ran tests on BOINC.(*) 155191 of them were correct. That's an error rate of 0.46%. That's pretty good. You would expect the error rate to be low when small numbers are involved, and the PRPNet tests started very low. However, if I limit the comparison to just tests over 1 million digits, the error rate is 0.20%. So it's just a very low error rate.

(*) There were some PRPNet tests which we did NOT test on BOINC because the candidate was removed by the more extensive sieving we did prior to starting GCW on BOINC.

Note 1: The error rate may be skewed because Jim may have manually run a lot of the problematic residues, or excluded obviously bad residues. The error rate may therefore be higher than what my data shows.

Note 2: Don't bother asking this question about SoB. That's much more complex because the residues come from different software -- in fact, multiple different software programs -- and comparing them to our residues is somewhat convoluted. Furthermore, many candidates have multiple and different residues from the SoB project. It would be difficult, bordering on impossible, to distinguish between "error" and "the residues don't match because the software is incompatible". Additionally, some candidates were double checked at SoB (and we have sufficient information on both tests), and fully double checked SoB candidates were excluded from our own double checks. That also would skew the statistics.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

Interesting question. As it happens, there is enough information available to get the answer.

There were 155905 residues from PRPNet for which we ran tests on BOINC.(*) 155191 of them were correct. That's an error rate of 0.46%. That's pretty good. You would expect the error rate to be low when small numbers are involved, and the PRPNet tests started very low. However, if I limit the comparison to just tests over 1 million digits, the error rate is 0.20%. So it's just a very low error rate.

Thank you for the answer. When using PRPNet, you do not immediately see if you have a computer where all the residues are bad (because no double checking occurs on PRPNet), so it is amazing that the error rate is so low. Maybe PRPNet users are careful and "advanced", on average. /JeppeSN

With GCW now above 2 million digits, when will the next prime be found?

At this size and assuming ~45-50-bit pre-factoring, 1 in ~150,000 tests may find a prime.
(Of course, once 150,000 tests will be done, the size will increase, and the goal posts will move further...)
How many units are processed per week on average? Divide one by the other and you will have the answer (+-90% CI).

With GCW now above 2 million digits, when will the next prime be found?

At this size and assuming ~45-50-bit pre-factoring, 1 in ~150,000 tests may find a prime.
(Of course, once 150,000 tests will be done, the size will increase, and the goal posts will move further...)
How many units are processed per week on average? Divide one by the other and you will have the answer (+-90% CI).

Last time I looked it was about 4000 candidates per week (8000 tasks, since each is double checked.) That works out to 37.5 weeks.

The number varies, of course. Not only do the tasks get larger over time, but people shut off computers during the summer, decide to participate in the latest challenge, want to get SGS primes while they're still in the top 5K, etc. And, of course, there's going to get a GCW-LLR challenge, which will significantly increase the number for a few days.

____________Please do not PM me with support questions. Ask on the forums instead. Thank you!