DAAYUMM!At the mid-day update, I have 4.25M on Einstein, so I thought maybe I would be in the top ten at Free-DC...uhm, nope, the top producer (from XtremeSystems), at the MID-day update, is nearly 1.5 BILLION.
This could be due to the GDPR change. The user may have produced continuously during the past days, but flipped the privacy switch only today. (If you are curious, you could investigate the task lists of his four computers.)the top producer (from XtremeSystems), at the MID-day update, is nearly 1.5 BILLION.
One way to find out:Does this option affect team credits?
On January 10 Michael Goetz said:321 is currently sieved up to n=25M. The current leading edge is n=14.6M. We're going to sieve 25M < n < 50M. That would bring the 321 sieve up to the same point to which we've sieved the conjecture projects. The sieving should take several years, and we'd like to get the sieving done before LLR reaches 25M. 321, having just a single k, and the smallest of all possible k's, could advance very quickly if people concentrated on it.On January 10 tng* said:Would anyone from the project care to comment on why the 321 sieve is being restarted?
Additionally, with GCW sieve likely to be ending sometime this year, we did want to have another CPU sieve project to take its place. It's a good time, therefore. to reopen 321 sieving.
On March 16 Michael Goetz said:Before anyone asks, I'm guessing 321-Sieve will last about 2 years, with two big caveats:
1) This assumes I didn't make a huge error in the calculations and be off by a factor of 10 or 100.
2) Even if I did it correctly, the calculations are based on a lot of rough estimates, so it's likely to be off by a factor of 2 or more. Realistically, I expect it to last somewhere between 1 and 5 years, with 2 years being the most likely.
On February 18 JimB said:As of the moment, I'm planning on starting 321 sieving right after the TdP, probably on March 1st, though I still have some work to do before that.
On GCW sieving there are eleven different b values. The optimal point is different for each of them, depending on how long it takes to sieve and how long it takes to run LLR on those bases.
Bases 13, 25, 55, 69 need a relatively significant amount of sieving.
Bases 29 and 49 need a bit more but are close to being stopped.
I stopped 47 and 101 a few days ago. 73, 109 and 116 were already stopped.
With just six bases still generating new sieving jobs, I don't expect 29 and 49 to last long. It all depends on how many people are still sieving GCW when that new 321 Sieve badge becomes available on March 1. My current thinking is that GCW might last until May, but I can't guarantee it. If you want to upgrade a GCW badge, don't wait.
I found a SETI.Germany forum post referring to a boinc.berkeley.edu forum post referring to an unnamed Russian forum:No one running Acoustics, for a 2nd week in a row? Hmm, no stats since April the 1st, and I can't reach the site...
Vitalii Koshura said:There is some issues with University Data Center. Currently unknown how long it will take to restore availability of the server. No worries, no data was lost. Just server of this project and probably some others that are hosted in the same University Data Center.
Both good and bad indeed.Eric Driver said:GPU app status update
So there have been some new developments over the last week. It's both good and bad. [...]
The next GPUGrid app will include turing card support. The first beta app will be linux, then a windows app will follow. No ETA yet though.They won't fix it in the present application version anymore; Linux users are asked to wait for the next major version update:
Pretty much the end of this project, because they say the next step (10 space squares) would generate about 7M times more tasks then 9 space squares did, and they "...don't want to run an endless search without any results, because many other interesting and useful projects exist." They will have a small test batch though, to see if they get lucky and find any 10 space thingys.
Rake search of diagonal Latin squares: Future of the RakeSearch project
Two days ago the project reached a milestone of 95% of completion. As part of the current search, it remains to process about 1100 000 workunits. In the next few days, we plan to generate one or several bunches of workunits for new search - in space of diagonal Latin squares of rank 10. Initially, tasks only under Linux x86-64 platform will be available, if their processing is successful, the application for Windows will be released.
A few words about the new search. We expect that an typical task will process more squares for the same time (on average). In the application for a new search, we implement some optimizations and it will be significantly faster than default application for search in space of rank 9. Another interesting thing - the search space, itself. We increase a square rank by only one stage - from 9 to 10. Currently, for workunit names we use a format R9_<8 digits> (R9_022248939 for example) and first digit from tuple - always 0. But for the naming of workunits for a new search, if we try to count all of them, we must use a format like _0000000000000001! (We don't know the number of workunits for full search in space of rank 10 precisely, but rough estimate - about 160 millions of millions of workunits). The current search comprises 23 000 000 workunits, but the full search in rank 10 space targets about 7 000 000 searches of rank 9! Of course, we cannot perform a search like this. Even with new Ryzens.
Also, today we do not know whether or not "permutational" orthogonal diagonal Latin squares of rank 10 exist.
For the reasons listed below, we plan to perform a search over a tiny part of entire search space - may be 1 million of workunits, may be larger, but we don't want to run an endless search without any results, because many other interesting and useful projects exist.
Thank you for attention and participation!