New SGS primes are entering the T5K list in the 4888th position. This means that when 113 more primes larger than 388342 digits (the size of an SGS prime) are discovered, SGS primes will no longer be eligible for T5K.

During the last year, 929 primes larger than SGS were found. Extrapolating that rate, you get 113*365/929 = 44 days until SGS is pushed off the T5K list.


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

So for the race, GO GO GO GO

I suppose a little prognostication is in order: 44 days would be July 23rd. We'll see how close we come to that date.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I feel like a last 5k pool should be formed here. I bid July 19.
____________
Eating more cheese on Thursdays.

I feel that now the river of tears will start flowing: and user will start screaming : why, how, I have no prime in Top 5000 , etc etc etc :)
____________
92*10^^1439761-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

I feel that now the river of tears will start flowing: and user will start screaming : why, how, I have no prime in Top 5000 , etc etc etc :)

Jul 18, with the birthday challenge I expect a big push that 24 hours that takes a few days off.

Since the challenge is a Sophie Germain prime search, I guess it will not push anything greater than our Sophie Germain range onto the Top 5000 list? Replacing the 113 Sophie Germain positions with 113 new (and a bit larger) Sophie Germain primes over and over, will not move us towards "the end"?

/JeppeSN

I am going to say end of June, so my guess is 30 June.
I have noticed my team's prime for the challenge enter in position 4901 and now its at 4911, so it won't be long now...

Is the finish at the last leading edge leaving and\or returns at 4999 which means either the DC might cause 5000 if it comes in minutes later the last leading edge is returned at entering ~5000. If the former is it than June 27 AM UTC or latter scenario at noonish UTC. Of course the more time passes the former then could another leading edge come in before DC from the original leading edge. Then of course a different higher ranking Prime(s) can change all of this. If so than it could be June 27 PM UTC before the last SGS is no longer.

EDIT: And to why I first started to post here. I predict June 27th, with finer details above.

NeoMetal*
____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713

Surprisingly, at least to me, today was the day the first SGS prime couldn't be reported.

I overlooked something.

Leading edge SGS primes can still be reported. They're currently going in at position 4922.

What happened was that an SGS prime was found by someone who had not granted us permission to report the prime on their behalf, and did not respond to our emails/PMs. We give them 19 days to do so. During that time period, subsequent SGS primes (which are VERY slightly larger than previous SGS primes) pushed that particular prime below 5000. So that prime can't be reported to T5K.

We'll try to prevent that from happening with the remaining primes by not waiting a full 19 days in similar circumstances. That way, at least the prime will still be put on the list before dropping below 5000. But this is a manual process, and we can't be watching 24 hours a day, so a few more will probably miss the list under similar circumstances.

At least if you have your settings set to give us permission to report (and your real name), SGS still has a little ways to go.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Illustrates that a lot of SGS-project primes are found in 19 days ... /JeppeSN

When these primes drop out of the top5000, will there be a list of the primes found afterwards for people to search for arithmetic progressions?

That might be difficult to parse. Can we have a plain text dump similar to http://primes.utm.edu/primes/lists/all.txt? Or the results of using http://primes.utm.edu/primes/search.php where "Text" is selected.

Anyone who is trying to get their first SGS prime before it's too late to get it reported to T5K, make sure you have your prime reporting enabled with your real name.

SGS primes are falling off the list very quickly, and there isn't time anymore for us to contact you about setting up your preferences. If you haven't given permission for us to report the prime for you, we'll skip you and report the prime under the DCer's account. If the DCer also hasn't granted permission, we'll skip both parties and report the prime anonymously.

It would be a shame if you found your first prime and yet didn't get your name on the T5K list because you didn't check a box on a webpage.

Instructions from the news announcement:

To enable prime reporting, please go to "Your account" on the menu on the left, then select "PrimeGrid Preferences". Scroll down a bit to where it says "Primary (default) preferences:" and select "Edit PrimeGrid Preferences".

Scroll down to "Reporting primes to the Prime Pages" and click the two checkboxes for granting permission to report primes and to send you an email when a prime is found. You must enter your real name. T5K will not accept fake names or user names. Please enter your name as "given-name surname". (Note that even in cultures where the surname is normally put first, we need the given name first and the surname last.)

If for any reason you don't want us to use your name, we can report anonymously for you -- just check the permission box and enter something like "report anonymously" in the name box.

Finally, scroll down to the bottom and click on the "Update preferences" button.

Looks like the top SGS prime is down to 4929th place now. If it's taken 4 weeks to go down 40 positions it might take another 8 weeks to be completely out.
____________
1 PPSE (+2 DC) & 5 SGS primes

Looks like the top SGS prime is down to 4929th place now. If it's taken 4 weeks to go down 40 positions it might take another 8 weeks to be completely out.

I'm joining the SGS T5K blowout with all crunching on SGS until #5000 is non-SGS.

I'm joining the SGS T5K blowout with all crunching on SGS until #5000 is non-SGS.

I'm joining the SGS T5K blowout with all crunching on SGS until #5000 is non-SGS.

Ironically, the more people who do this (and I'm one of them too), the longer it will take until SGS falls off the list.

Dang! I was DC on the latest SGS by DeleteNull and I had it first.

EDIT: I was using 1 thread and DeleteNull was using 2.

To MT or not to MT, that is the question.

MT is largely regarded as too inefficient with SGS.
Lower efficiency, so less throughput.
But using MT, when you stumble upon a prime, you will almost certainly be credited with the find.
For example, this SGS prime:
http://www.primegrid.com/workunit.php?wuid=532935602

To MT or not to MT, that is the question.

MT is largely regarded as too inefficient with SGS.
Lower efficiency, so less throughput.
But using MT, when you stumble upon a prime, you will almost certainly be credited with the find.
For example, this SGS prime:
http://www.primegrid.com/workunit.php?wuid=532935602

To MT or not to MT, that is the question.

MT is largely regarded as too inefficient with SGS.
Lower efficiency, so less throughput.
But using MT, when you stumble upon a prime, you will almost certainly be credited with the find.
For example, this SGS prime:
http://www.primegrid.com/workunit.php?wuid=532935602

I have my doubts that multithreading really made the difference, there.

Based on run times, I would say that the other user is putting all 12 threads of their 5820k to work (my AVX i5 3570 prime checks in 1500).

Additionally, I think that the winning 6700k is gaining maybe a minute (if that) by dual-threading the tasks.

I will stand slightly corrected then. I'm actually surprised that my 3570 without FMA handily beats your 5820k with it. (Even adjusting for clockspeed-mine is OC'd a couple bins to 4GHz-if you are at 3.3 all the time, your performance is within a few percent of parity to mine).

I think you misunderstand my argument against multithreading. I did see the times in the task, the elapsed being roughly half of the CPU, which is nice, something I like to see on my own MT tasks when scaling threads, despite it not actually meaning much vs. single thread time. What I am saying is that the CPU is using 2 cores for a total of 1073 seconds to complete a prime task that, were it executed in a single thread, wouldn't take significantly longer. Consider the task I linked for my 7700k: 977s single threaded. For S&G's, I just ran the exact same task (a prime task) again double-threaded (twice concurrently to load the CPU) and came up with mid-700s for both runs, add a little more for Boinc overhead and I was actually surprised at the result. I was expecting near 900 or so. But still, it's a ~23% reduction not to be heavily sneered at. Lightly sneered at, yes, because that is so horribly inefficient, I'm not even going to try -t4. Since Skylake and Kabylake are identical IPC, I estimate a single thread run time of around 1300-1350s, which doesn't even sound right to me given at most a 15% clock difference (assuming the 6700k is staying at 4 GHz, I know mine is solid at 4.6x4c), and comparing against the IVB 3570 at 1500s (again, for a prime result). Checking all the tasks from the host, I can't fathom why there is the mix of 550s and 1000s non-prime runtimes (check the credits!) without seeing the full LLR output, maybe Michael can, but it shouldn't take twice as long to still not be prime (the time from sent to report is also extended by the extra time). My only thought is it's related to the funny MT "start fresh" behavior when multiple MT tasks are downloaded and the reported elapsed times just go up until the last one equals the CPU time, but there are a lot of them.
____________
Eating more cheese on Thursdays.

I will stand slightly corrected then.

CPU is using 2 cores for a total of 1073 seconds to complete a prime task that, were it executed in a single thread, wouldn't take significantly longer.

When I look at the task list for the 6700k, all I saw were composite results of either ~550s or ~1000s, so I'm not sure where the 899 figure you're quoting is coming from (I do see a couple now, but it's just a variation of the 1000s times I think)? I see the times around the prime are rather all over the map, but mostly in line with other tasks, and I know tasks of the same size won't run the same time all the time, but I wouldn't be happy if some were randomly taking twice as long as others when they shouldn't be. Looking at my own MT tasks of other subprojects, I found several tasks that didn't correspond to the ~1/threads ratio, but examining my logs, those were at times when computation was suspended, and the actual compute time was in line with expectations, but the weird MT time reporting feature described in another thread shows up. I suspect it's involved here, but I lack info on how task downloads occur when multiple multi-threaded units are in play, so I dunno.

In regards to my 7700k, I wish I could bang out the primes like that. Those were prime finds around the time of the challenge, and all the composites have long since been purged. 8 days seems to be the max time a composite WU sticks around. I've switched it back over to SGS, so once the CUL is done in about 5 hours, there will be plenty of fresh data to examine, and maybe a new prime or two if those horseshoes are properly oriented :). I might throw in a bunch of 2 threaded ones, too just for some fun of my own branding, it's my weekend and I've got time to kill.

In the end, we all make our own decisions about how to run our tasks, and SGS is on my list of subprojects more efficient to run single threaded, seems to be serving me well, and that's what matters, right?
____________
Eating more cheese on Thursdays.

Re: 899s run time; I was looking at this WU which was returned just before the prime. It might have something to do with the work queue size or some other CPU occupancy that was happening to extend the real time so my conclusions are invalid. Micheal needs to add BBCode tags for emojis. The specific ones I need right now are [observer-bias/], [deflated-balloon/], [egg-on-face/].

It's all good :).

My little Ivy i5 is on a hot streak! 3 finds in the last 7 days, got one today with under a minute's separation in reporting. Yowza!
____________
Eating more cheese on Thursdays.

I suppose a little prognostication is in order: 44 days would be July 23rd. We'll see how close we come to that date.

once SGS is off the top 5k are we interested in push the limit 23 digits further to put it back on the list.

how many years will it take exactly?

4990
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

4991

There's also two primes in the pipeline which, once reported, will push SGS to 4993.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

4997


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Who will have the last SG prime to enter onto T5K?

4999

Note that we can still report at position 5000, but not at position 5001. Two more primes larger than SGS will knock SGS off the list.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

5000

Next prime larger than an SGS prime will do it.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I've just reported a PPSE that pushed ordinary primes found in the SGS search off the list completely. Of course, any twin or Sophie Germain pairs of primes are still reportable because there are separate short lists for those and ours would be the largest known in either case.

I've just reported a PPSE that pushed ordinary primes found in the SGS search off the list completely. Of course, any twin or Sophie Germain pairs of primes are still reportable because there are separate short lists for those and ours would be the largest known in either case.

Who will have the last SG prime to enter onto T5K?