Phew, again some finished sieve files for the Sierpinski-Site. :smile:

So, lets start with S48; reached 20T. (attached)

S214 reached 30T. (attached)

S361 reached 51,7G (Time per factor>time for prp-test) (via Mail)

Reserving S579 for n=200K-1M
Reserving S22 for n=2M-5M (This is going to be funny, testing to at least 100T)
Reserving S522 for n=10K-25K. (I need to ask for an k´s remain file...)

[QUOTE=MisterBitcoin;457508]Phew, again some finished sieve files for the Sierpinski-Site. :smile:

So, lets start with S48; reached 20T. (attached)

S214 reached 30T. (attached)

S361 reached 51,7G (Time per factor>time for prp-test) (via Mail)

Reserving S579 for n=200K-1M
Reserving S22 for n=2M-5M (This is going to be funny, testing to at least 100T)
Reserving S522 for n=10K-25K. (I need to ask for an k´s remain file...)[/QUOTE]

The Riesel bases have fallen well behind the Sierp bases in their searching and sieveing. Some of the biggest deficits are for n=25K-100K. Therefore after this I'd like to suggest that we start working on more Riesel bases.

One more thing: Please update your sieve depth in the sieve files before posting them. When it is incorrect it is misleading for future searchers. I had to correct 2 out of the 3 here.

Attached are the k's remaining for S522 at n=10K.

[QUOTE=gd_barnes;457533]The Riesel bases have fallen well behind the Sierp bases in their searching and sieveing. Some of the biggest deficits are for n=25K-100K. Therefore after this I'd like to suggest that we start working on more Riesel bases.

One more thing: Please update your sieve depth in the sieve files before posting them. When it is incorrect it is misleading for future searchers. I had to correct 2 out of the 3 here.

Attached are the k's remaining for S522 at n=10K.[/QUOTE]

Thanks for the file, starting sieve now.
I was focusing on the Sierp-Site, but taking a few Rieselbases isn´t a problem. :smile:
I´d like to get remain-files for: R226; R675, R880 and R999.
(OR: If possible add k´s-remain in a txt on the Base-Page. Like on S/R3. :smile:)
Thanks.

If I may noticed, many S and R bases are same ( and both side) has not sieve files. So when reserving and doing S side, it can in same time be sieved R side. Two bases with same time and same resources :)

[QUOTE=pepi37;457607]If I may noticed, many S and R bases are same ( and both side) has not sieve files. So when reserving and doing S side, it can in same time be sieved R side. Two bases with same time and same resources :)[/QUOTE]

+1

[QUOTE=pepi37;457607]If I may noticed, many S and R bases are same ( and both side) has not sieve files. So when reserving and doing S side, it can in same time be sieved R side. Two bases with same time and same resources :)[/QUOTE]

Yeah, I now that. I prepared some bases with the same n-values (e.g. 30).
I was taking bases were only one side is needed, after this bunch focusing on 25-100 and bases with same n-value. :smile:

S579 reached p=50T, file attached.

Reserving S/R 218.

[QUOTE=MisterBitcoin;457948]S579 reached p=50T, file attached.

Reserving S/R 218.[/QUOTE]

n-range: 200K-500K. :smile:

R702 sieved to P=50e12 for n=200k-400k. File attached.

R549 reached p=75T, file attached.

Reserving R/S 30; n=500K-1M.

S/R 218 reached p=35T, booth files attached.

Reserving S646 for n=10-25K.

Sieve file for S646 finished, no need for update because I´m testing these base.

Reserving R995 from n=200K-500K.

There is also an sieve file attached for S522, factor/time just passed prp canidate. (75G)

R995 reached p=30T, file attached.

Reserving S/R 1017 for n=100K-250K.

[QUOTE=MisterBitcoin;458746]R995 reached p=30T, file attached.
[/QUOTE]

In sieve file 50000000 is stated as sieve depth. So is it 50000000 or 30T? :razz:

[QUOTE=pepi37;458782]In sieve file 50000000 is stated as sieve depth. So is it 50000000 or 30T? :razz:[/QUOTE]

Fixed.

S22 reached p=100T, file attached. It was way faster than I suggested.

Reserving R523 from n=500K-1M.

[QUOTE=MisterBitcoin;458999]S22 reached p=100T, file attached. It was way faster than I suggested.

Reserving R523 from n=500K-1M.[/QUOTE]

R523 has already proven XDDD...

The largest prime of this base is 126*523^222906-1.

[QUOTE=sweety439;459053]R523 has already proven XDDD...

The largest prime of this base is 126*523^222906-1.[/QUOTE]

Typo, typos everywhere.

I meaned R253.

Reserving R27 for some more sieving; I have Wombatman's 2M-3M file, which I'll be extending.
If anyone is sort-of-interested in testing this one-k base, perhaps we could split up the file and team up when LLR time arrives.

S/R 1017 reached p=15, booth files attached.

Reserving S263 from n=350K-1M.

Could i reserve S825 from n=100k to n=300k?
Pre-thanks

Still having problems with my network access...

Well, two more sieve files done.

S263 reached 50T, attached.

R253 reached 50T, attached.

Reserving S332 from n=200K-500K, and S148 from n=1M-3M.

S/R 30 passed 50% from there route to 50T. :smile:

I´d like to get an k´s remain file for R880 (309 k´s remain)

[QUOTE=MisterBitcoin;459680]
I´d like to get an k´s remain file for R880 (309 k´s remain)[/QUOTE]

Attached.

R702 can be removed from the list.

S332 sieve finished a few days ago. There is no need to upload it because Pepi got the file via FB.

S148 reached p=75T, file attached.

Reserving R880 from n=25K-100K.

Unreserving SR30.
Some kind of bug happend again. Sieving was nearly complete. :(


I was unable to reproduce the problem. Well, there is only one possibility left: I setted a "+" instead of a "-" and other wise.
This makes me angry about myself. Wasted more than 3 CPU months for nothing.



I was 100% sure that nothink could go wrong...what a shame.

After the big shame on SR30 and 218 I´m restarting SR218. (reserving on SR218, all k´s with n=200-500K)



[CODE]50014193 | 53*218^238831+1
50025581 | 17*218^281480-1
50061247 | 2*218^475076-1
50077361 | 59*218^460949+1
50077397 | 17*218^343062-1[/CODE]


It hurts that such an stupid thing an occur twice. I hope you still thrust me.

[QUOTE=MisterBitcoin;461410]
It hurts that such an stupid thing an occur twice. I hope you still thrust me.[/QUOTE]
What is it that happened, twice? Can you explain more detail than "some kind of bug"? I'm not aware of any bugs in the srsieve family.
Edit: Never mind, I saw the discussion in the 100-250 reservation thread. Strange.

[QUOTE=VBCurtis;461437]What is it that happened, twice? Can you explain more detail than "some kind of bug"? I'm not aware of any bugs in the srsieve family.[/QUOTE]


After some tests I can say it wasn´t a bug. While making the sieve-init file (which holds the sequences) I must have a "+" setted instead of an "-".

My first guess was, that this was caused by a bug, because I was sure that I haven´t maked any typos. (Well, I´m also douple checking my files. In this two cases I must have missed that.)


Anyway it´s not a bug.

I wasted 3 month worth CPU time.

I´ll restart my work on SR30, this might take some time.

OK I have changed RS218 back to "in progress" in the first post here. I have left RS30 as "in progress". I have removed RS218 sieve files from the pages.

Reserving R708 for sieving from n=30k to 50k.

Quick update on my sieving work.

I was focusing on my R3 reservation, so any other reservations were a bit delayed.
The new SR 218 should be done in a few days (74,6%) and SR30 will be restarted after this is finished.
R880 is running, I´ll also check for alg. factors which seems to occur on that base. (using the script from batalov.)

SR 218 reached p=35T, booth files attached.

Restarting SR 30, this should take 2-3 months.

R708
 

R708 is sieved to P=5e12. The sec/factor from sieving is sufficiently high to warrant switching to prp testing.

[QUOTE=MisterBitcoin;463151]SR 218 reached p=35T, booth files attached.

Restarting SR 30, this should take 2-3 months.[/QUOTE]

MisterBitcoin,

I/we have been noticing some various problems with your sieve files. Most of the time it is incorrect sieve depths. The first time with Riesel/Sierp base 218, you had the k's reversed and the files had to be completely resieved. This 2nd time it appears that you only have the headers in the files flipped. The k's for the Riesel file should be for the Sierp file and the k's for the Sierp file should be for the Riesel file. This is the second time that BOINC has tried to test base 218 and it was still incorrect.

As an FYI 35000000000000:P:1:218:257 is for Sierp base 218 and 35000000000000:M:1:218:258 is for Riesel base 218.

Unfortunately I must reject your base 218 files once again and remove them from the pages. It appears that they might be correct if the headers are flipped but I cannot accept them as they may contain other problems. I'll leave it up to you if you want to sieve them a 3rd time starting from scratch.

Please take more time and be more careful when posting things as it causes BOINC and me more work. I'm going to suggest that you not reserve so much work at a time. In the future I will be inspecting your sieving work much more closely before posting it on the web pages.


Thank you,
Gary

[QUOTE=gd_barnes;464992]MisterBitcoin,

I/we have been noticing some various problems with your sieve files. Most of the time it is incorrect sieve depths. The first time with Riesel/Sierp base 218, you had the k's reversed and the files had to be completely resieved. This 2nd time it appears that you only have the headers in the files flipped. The k's for the Riesel file should be for the Sierp file and the k's for the Sierp file should be for the Riesel file. This is the second time that BOINC has tried to test base 218 and it was still incorrect.

As an FYI 35000000000000:P:1:218:257 is for Sierp base 218 and 35000000000000:M:1:218:258 is for Riesel base 218.

Unfortunately I must reject your base 218 files once again and remove them from the pages. It appears that they might be correct if the headers are flipped but I cannot accept them as they may contain other problems. I'll leave it up to you if you want to sieve them a 3rd time starting from scratch.

Please take more time and be more careful when posting things as it causes BOINC and me more work. I'm going to suggest that you not reserve so much work at a time. In the future I will be inspecting your sieving work much more closely before posting it on the web pages.


Thank you,
Gary[/QUOTE]

Luckily no tests were being made. I only tested some runtimes of different ranges on local side.

Can I reserve that ranges ( both S/R) side: it is too hot for me to make LLR but sieve is much colder: It will be done in 10-15 days from now

[QUOTE=pepi37;465029]Can I reserve that ranges ( both S/R) side: it is too hot for me to make LLR but sieve is much colder: It will be done in 10-15 days from now[/QUOTE]

OK I am reserving sieving only for R218 and S218 for n=200K-500K for you.

Sieve started :)

Since I put sieve on 8 CPU cores, new ETA is 12.8
Best regards

S/R 218 sieve is over
Files sent to Gary

Meaningless drivel moved to:
[url]http://mersenneforum.org/showthread.php?t=22511[/url]

Sieve file S75, n=1,3M-3M.
p=75T

Reserving R1019 for sieving n=400K-1M, pmax=50e12.

[QUOTE=MisterBitcoin;465724]Reserving R1019 for sieving n=400K-1M, pmax=50e12.[/QUOTE]

R1019 reached p=50e12, file attached.

Reserving S185 from n=1M-3M, p=75T.

R880 reached p=11,86T. (I planned 15T, but this value fits too.)

Reserving S411 from n=25K-100K with p=7,5T.

Notice: I have my future scope on Riesel. I´d like to get the remain files for R301 and R303.

S185 reached p=75T, attached.
I have to add that SR 30 also reached his sieve limit. (P=50T)

Reserving R392 from n=200K-500K.
Reserving R46 from n=300K-500K.

R392 reached p=30T, file attached.

Reserving R213 from n=200K-500K.

S618
 

Reserving S618 to sieve for n=100k-200k. Already at 1e12. I will continue until the sec/factor rate is appropriately high (would estimate around P=30e12 or so).

There we go,

R213 is done (p=30e12) and attached.

Reserving R321 for n=200K-500K.

R321 is done (P=30e12), file attached.

Reserving S68 for n=1-3M.

S411 reached p=7,5T, file attached.

Reserving R102 from n=200K-500K.

S68 reached p=100T, file attached.

R46 reached p=30e12, file attached.

Reserving R1027 from n=100K-250K.

There is a link to a sieve file for S27 for n=1.211M-2M that is sieved to only P=7.5T. P=7.5T is way too low even for BOINC.

Recommendation: Continue sieving this file to a minimum of P=100T. Test times for this file are so long that P=300T or higher would be better but P=100T is a good starting point.

Sieved enough, we could use the S27 file for loading into our port 1300 for a PRPnet team effort. The port currently has R23 loaded into it and will likely be finished within a month.

[QUOTE=gd_barnes;468069]There is a link to a sieve file for S27 for n=1.211M-2M that is sieved to only P=7.5T. P=7.5T is way too low even for BOINC.

Recommendation: Continue sieving this file to a minimum of P=100T. Test times for this file are so long that P=300T or higher would be better but P=100T is a good starting point.

Sieved enough, we could use the S27 file for loading into our port 1300 for a PRPnet team effort. The port currently has R23 loaded into it and will likely be finished within a month.[/QUOTE]

After my sieve-file for Masser (R6) is done I could sieve up to p=100T. (or Curtis if he finishes his R27 works. Masser´s work will take 2 months until finished.)

For PRPnet we could use S17 or S22 as well, booth sieved up to 100T.

I stopped R27 a month or so ago, because Rebirther put R27 on BOINC with the old sieve file and told me he wasn't willing to restart the job using my sieve (at 90T rather than 30T).

The only sieve I run for public consumption is R3, and after the R27 experience that's not likely to change.

[QUOTE=MisterBitcoin;468095]After my sieve-file for Masser (R6) is done I could sieve up to p=100T. (or Curtis if he finishes his R27 works. Masser´s work will take 2 months until finished.)

For PRPnet we could use S17 or S22 as well, booth sieved up to 100T.[/QUOTE]

S17 and S22 are well under-sieved for n=2M-5M. They need to be sieved to P=250T or higher. Besides those have already been tested to n=2M. S27 is the only unreserved 1k base < 40 that has not been tested to n=2M so it is higher priority.

We will choose something different for PRPnet.

Edit: Because of (now) two different people's experience with trying to sieve under-sieved files when BOINC reserves them in the middle of such efforts, I have decided to no longer accept well under-sieved files for posting on the pages. The original idea behind posting under-sieved files on the pages is that they would be a starting point for people to continue sieving before beginning testing. That is not working out very well.

[QUOTE=gd_barnes;468111]S17 and S22 are well under-sieved for n=2M-5M. They need to be sieved to P=250T or higher. Besides those have already been tested to n=2M. S27 is the only unreserved 1k base < 40 that has not been tested to n=2M so it is higher priority.

We will choose something different for PRPnet.

Edit: Because of (now) two different people's experience with trying to sieve under-sieved files when BOINC reserves them in the middle of such efforts, I have decided to no longer accept well under-sieved files for posting on the pages. The original idea behind posting under-sieved files on the pages is that they would be a starting point for people to continue sieving before beginning testing. That is not working out very well.[/QUOTE]

I´ll rethink about sieving over p>100T. (R6 150T.) because of the time needed.
Sofar I know PG is using sieve apps for there searches, may that something for SRBase as well? (I talked about that with reb for k-rich bases like 66, but not for single-k.)
I´m nearly alone making sieve files (+Curtis with R3 and wombatman) and will focus on bases up to nmax=25K/100K/250K/500K. Taking a single-k base up to 200T or more will took ~4-6 months (depending on resources.)

Don´t get me wrong, I can understand the background. If the base would be taken by reb, it´s not that bad instead of user who has to sieve first. How many factors will we find in 100T-250T?

[Theory]Maybe 100-200, which is not sooo much for BOINC. It take a few days more for SRBase, but months for sieving.[/Theory]

[QUOTE=gd_barnes;468111]S17 and S22 are well under-sieved for n=2M-5M. They need to be sieved to P=250T or higher. Besides those have already been tested to n=2M. S27 is the only unreserved 1k base < 40 that has not been tested to n=2M so it is higher priority.

We will choose something different for PRPnet.

Edit: Because of (now) two different people's experience with trying to sieve under-sieved files when BOINC reserves them in the middle of such efforts, I have decided to no longer accept well under-sieved files for posting on the pages. The original idea behind posting under-sieved files on the pages is that they would be a starting point for people to continue sieving before beginning testing. That is not working out very well.[/QUOTE]

I could look at doing S27. I'll check the speed tonight and see what kind of timeframe I'd be looking at.

[QUOTE=gd_barnes;468111]Edit: Because of (now) two different people's experience with trying to sieve under-sieved files when BOINC reserves them in the middle of such efforts, I have decided to no longer accept well under-sieved files for posting on the pages. The original idea behind posting under-sieved files on the pages is that they would be a starting point for people to continue sieving before beginning testing. That is not working out very well.[/QUOTE]

One possible remedy is to take down the posted sieve file when someone makes a sieve reservation. Future sieve efforts are only going to get deeper as more bases are tested past 500k, and it's reasonable for someone to sieve to, say, 50T and send it to you for someone else to finish. That doesn't seem to happen all that often, but if I were you I'd reject files sieved to less than half of what you'd want to reduce your workload.

Alternately, you could add a text line in the sieve file itself "DO NOT TEST WITHOUT FURTHER SIEVING", which could act as a signal to BOINC to not pick that file.

I'm going to go ahead and start on S27. It's possible I may need to give it up at some point, but I can at least give it a significant boost. I grabbed the current sieved file.

[QUOTE=VBCurtis;468142]One possible remedy is to take down the posted sieve file when someone makes a sieve reservation. Future sieve efforts are only going to get deeper as more bases are tested past 500k, and it's reasonable for someone to sieve to, say, 50T and send it to you for someone else to finish. That doesn't seem to happen all that often, but if I were you I'd reject files sieved to less than half of what you'd want to reduce your workload.

Alternately, you could add a text line in the sieve file itself "DO NOT TEST WITHOUT FURTHER SIEVING", which could act as a signal to BOINC to not pick that file.[/QUOTE]

The former is along the lines of what I was thinking for future sieve files. Good idea.

The latter is an excellent idea. I'll do that immediately for S27 while wombatman works on it.

[QUOTE=wombatman;468145]I'm going to go ahead and start on S27. It's possible I may need to give it up at some point, but I can at least give it a significant boost. I grabbed the current sieved file.[/QUOTE]

Great. I'll reserve it for you in the first post here and post a message on the page that the current file is not yet sieved deeply enough.

Suggestion at least P=100T or possibly P=250T if you have the resources. Thanks!

[QUOTE=gd_barnes;468155]Great. I'll reserve it for you in the first post here and post a message on the page that the current file is not yet sieved deeply enough.

Suggestion at least P=100T or possibly P=250T if you have the resources. Thanks![/QUOTE]

I'll definitely go to at least P=100T. Current ETA for 20T is the morning of the 21st, just to give some idea of the time. I'm sure it'll speed up a bit as candidates are removed.

S618 100-200k
 

Here's S618 sieved to P=12T. I stopped there because it had reached the needed time per factor to make it competitive with PRP testing (~250 sec/factor).

I can make it official:

We (Yoyo from RKN and me) are atm testing an potential BOINC effort on sieving bases.
They are 1,7K tests available, (atm only Win64) and your welcome to test the app.

Just download BOINC and add "yoyo@Home" as project. On the website go to "Your profile->Yoyo settings and mark "sieve" as project.


Anyway, reserving S320 from n=500K-1M.

As long as you have a system for confirming reported factors are actually factors, it seems this could help. Missed factors due to unreliable BOINCers aren't a big deal, but false factors are.

Note that you should run any sieve yourself up to some fairly-high level, to guarantee all small factors are found; something like 5% of expected sieve depth should do it. Also, the nature of the sieve programs lends itself well to sieving large ranges of exponents at once; if you're going to bother with BOINC, I suggest a maximum exponent 3-5x the minimum exponent. For instance, I'm sieving 500k to 3M for R3, and 300k to 2M for R327. Merely doubling n each sieve is a waste of sieve resources for these low-weight k values.

[QUOTE=VBCurtis;469216]As long as you have a system for confirming reported factors are actually factors, it seems this could help. Missed factors due to unreliable BOINCers aren't a big deal, but false factors are.

Note that you should run any sieve yourself up to some fairly-high level, to guarantee all small factors are found; something like 5% of expected sieve depth should do it. Also, the nature of the sieve programs lends itself well to sieving large ranges of exponents at once; if you're going to bother with BOINC, I suggest a maximum exponent 3-5x the minimum exponent. For instance, I'm sieving 500k to 3M for R3, and 300k to 2M for R327. Merely doubling n each sieve is a waste of sieve resources for these low-weight k values.[/QUOTE]

Yoyo decided to generate 2 tasks/WU, he is now working on a validator. The risk of missing/false factors should be really low.

For single-k bases I´ll sieve up to P=500G or 1T before loading it on BOINC server.
For the first 1-2 months I´ll focus on sieving "finished" sieve files deeper.
(e.g. S1009; S1004; etc)
The file for S320 just passed 20T, nearly the half from the goal. In just 1 day!

[QUOTE=MisterBitcoin;469230]The file for S320 just passed 20T, nearly the half from the goal. In just 1 day![/QUOTE]

I think you need to work on your computations of optimal sieve depth. For R327, I'm closing in on 400T while testing is under n=500k. If you're sieving 500k to 1M, I think you ought to be at 500T or higher so that the seconds per factor removed is roughly equal to the time a single primality test takes at roughly the midpoint of the file (in this case, n=750k, maybe 800k*).

A single test for S320 at n = 750k takes a *long* time. Check it out!

*tl;dr version: For sieve files where every candidate will be tested, the sec/factor rate is compared to the average test length for the entire file. A side effect of tests scaling with the square of exponent is that the mean test length is equal to the time for a test at 70% of the way from n-min to n-max; in S320 case, 850k is 70% of the way from 500k to 1M. However, we don't expect to test the entire file, since finding a prime means not using the later tests. I don't have a precise way to compensate for this, so I just reduce the sample-n primality test to something below 850k. Thus, 750 to 800k as the sample n.

Keep in mind that this is sieving being done for our BOINC efforts. The BOINC testing folks are not much concerned about sieve depth. Therefore I have generally suggested (and allowed) that files for them only be sieved to 10-30% of their typical optimal depth since we are using non-BOINC efforts to sieve for BOINC testing.

Alternatively I suppose if it is a BOINC effort doing the sieving then the BOINC sieving folks wouldn't mind getting additional work-unit credits for sieving so, MisterBitcoin, perhaps we could attempt to sieve those to close to optimal depth.

For this project, I generally suggest testing a candidate at 60% of the n-range for comparison when determining what factor removal rate should be optimum for sieving. MisterBitcoin if you want to run a partial test at n=800K for S320 to see what the optimal removal rate should be that might not be a bad idea. All you need to do is run a few 1000 iterations of either LLR or PFGW and see what the average iteration time is. LLR will display this. Then multiply that iteration time times the number of total iterations to determine total test time. That should be your optimum sieving factor removal rate for the range. You might find that the optimum is P=500T for n=500K-1M. This would be a huge task for a non-BOINC sieving effort but a mostly trivial one for a BOINC sieving effort.

[QUOTE=gd_barnes;469277]
Alternatively I suppose if it is a BOINC effort doing the sieving then the BOINC sieving folks wouldn't mind getting additional work-unit credits for sieving so, MisterBitcoin, perhaps we could attempt to sieve those to close to optimal depth.
[/QUOTE]

This is exactly what I had in mind- if BOINCers are doing both the sieving and the testing, then we should make decisions that minimize the total project length (sieve computations + LLR computations). This maximizes the productivity of BOINC, and finds primes sooner!

[QUOTE=VBCurtis;469295]This is exactly what I had in mind- if BOINCers are doing both the sieving and the testing, then we should make decisions that minimize the total project length (sieve computations + LLR computations). This maximizes the productivity of BOINC, and finds primes sooner![/QUOTE]

So, what do we have here.
The sieve depth:

For this test I´ve choosen 50e12 because we need two important things before sieving deeper:

-Validator
-post-processing to generate a file containing factors found

Yoyo is working on the validator, it might a few days until is working.

I asked pepi if he needs deeper sieve files for his searches, I´m offering the same to anyone working on a base too. The values will be around 1-5P (depends on N).

For BOINC-Bases I suggest to sieve them to a lower value then on user Bases. Something like that should be a good starting point:

10K-25K: 1e12
25K-100K: 15e12
100K-250K: 50e12
250K-500K: 150e12
500K-1M: 500e12
1M-3M: 2e15

I also want to focus on sieve files that are undersieved, see a few posts before.

Notice: For now 1 WU sieves a range of 50e9, if the project is out of beta we will sieve a range of 500e9. Yesterday we had 339 WUs running at the same time, just awesome!

For your calculations about sieve depth you must also consider base. It is not same sieve depth for base 9 and exponent 1M and base 1000 with exponent 1M :)

As soon you make validator is working OK I will sent you my sieve files for futher sieving and will join project with all my cores. Since you help me, I will help project :)

[QUOTE=MisterBitcoin;469302]Notice: For now 1 WU sieves a range of 50e9, if the project is out of beta we will sieve a range of 500e9. Yesterday we had 339 WUs running at the same time, just awesome![/QUOTE]

The time it takes to sieve 50e9 varies with sqrt(number of k values); a base with 300 k's remaining will take 10x as long as a base with 3 k's remaining. If it's OK for a WU length to vary by 10x, I suppose you don't have to care. But BOINC power allows you to sieve bases like R19 with ~1000 k's; you don't want to assign 100e9 per WU there!

The time also varies with sqrt(n-range); sieving 500k to 2M will be much slower than 25k-100k, even if the number of k's is the same. You'll struggle to make a one-size-fits-all approach for this project, if WU length matters.

S27
 

S27 has been sieved to P=250e12 for n=1.211-2M. I believe that was considered sufficient. There are 13,295 candidates remaining. File is attached!

We have done testing on R667.
R667 is sieved up to 20e12, factors are checked (all ok).
Booth sieve files attached.


I´ll take R93 to pmax=200e12.

[QUOTE=VBCurtis;469313]The time it takes to sieve 50e9 varies with sqrt(number of k values); a base with 300 k's remaining will take 10x as long as a base with 3 k's remaining. If it's OK for a WU length to vary by 10x, I suppose you don't have to care. But BOINC power allows you to sieve bases like R19 with ~1000 k's; you don't want to assign 100e9 per WU there!

The time also varies with sqrt(n-range); sieving 500k to 2M will be much slower than 25k-100k, even if the number of k's is the same. You'll struggle to make a one-size-fits-all approach for this project, if WU length matters.[/QUOTE]


I´m splitting each base into single sequences. That makes more WU´s, but it will reduce the size of upload and download files.


New record: 747 WU´s running overall, each contains a 500e9 range.

Taking S256 to pmax=150e12.

S320 reached p=100e12, file attached.


Notice: Factors checked with check-factors. No errors found.


Reserving R800 from n=500K-1M.

[QUOTE=MisterBitcoin;469451]Reserving R800 from n=500K-1M.[/QUOTE]

This base was already completed to n=1M. I've done it to n=800k and BOINC did the rest.

[QUOTE=unconnected;469456]This base was already completed to n=1M. I've done it to n=800k and BOINC did the rest.[/QUOTE]


It´s range n=1M-3M.

R93 reached P=200e12.
434 factors found, new sieve file attached.

S256 reached P=150e12
387 factors found, new sieve file attached.

Reserving the next bases:

[CODE]R103
R368
R1019
R1024
R1029[/CODE]

@Gary I didn´t reserved R102. :)

[QUOTE=MisterBitcoin;469679]@Gary I didn´t reserved R102. :)[/QUOTE]

Yes you did:
[URL]http://mersenneforum.org/showpost.php?p=467504&postcount=344[/URL]

Would you like to release it?

[QUOTE=gd_barnes;469683]Yes you did:
[URL]http://mersenneforum.org/showpost.php?p=467504&postcount=344[/URL]

Would you like to release it?[/QUOTE]

Ups. :smile:
R102 is sieved up to 30e12, file attached.

I´d like to have k´s remain for

R431
R598

Instead of continuing to sieve and test very difficult bases with a lot of k's remaining or that have already been tested to a deep depth, I would like to suggest this for a project direction for the time being:

Sieve and test the bases with the lowest difficulty on this list:
[URL]http://www.noprimeleftbehind.net/crus/vstats_new/crus-unproven.htm[/URL]

Just click on the "relative difficulty" column to sort them ascending by difficulty. Specifically I suggest sieving the bases with difficulty < 10000. There are 4 Riesel and 7 Sierp bases. None of them have more than 4 k's remaining.

For the bases tested to n=100K, sieve n=100K-250K. For the bases tested to n=200K, sieve n=200K-500K. S263 is the only base that has already been sieved. It has already been sieved for n=350K-1M to P=50T. You could just sieve that one further.

These bases will give us the best "bang for our buck" in that they can be tested fairly quickly and there may be several proofs of them.

[QUOTE=gd_barnes;469719]Instead of continuing to sieve and test very difficult bases with a lot of k's remaining or that have already been tested to a deep depth, I would like to suggest this for a project direction for the time being:

Sieve and test the bases with the lowest difficulty on this list:
[URL]http://www.noprimeleftbehind.net/crus/vstats_new/crus-unproven.htm[/URL]

Just click on the "relative difficulty" column to sort them ascending by difficulty. Specifically I suggest sieving the bases with difficulty < 10000. There are 4 Riesel and 7 Sierp bases. None of them have more than 4 k's remaining.

For the bases tested to n=100K, sieve n=100K-250K. For the bases tested to n=200K, sieve n=200K-500K. S263 is the only base that has already been sieved. It has already been sieved for n=350K-1M to P=50T. You could just sieve that one further.

These bases will give us the best "bang for our buck" in that they can be tested fairly quickly and there may be several proofs of them.[/QUOTE]

I´ll follow that route. Anyway rebirther requested to make some files for n=25K-100K.
For now the sequences I reserved are running. If that is finished I´ll load R6 for Masser.

How did you generate the Difficulty?

[QUOTE=MisterBitcoin;469721]How did you generate the Difficulty?[/QUOTE]

Mark (Rogue) came up with it. It's based on the number of tests remaining for an n=25K range on a sieve to P=1T multiplied by the size of a test at the current test limit.

Reb, we already have plenty of bases already tested to n=100K now. All bases with < 200 k's remaining have now been tested to n=100K or are reserved by others and are close. How about we use more resources to test bases with few k's remaining (perhaps < 10 k's remaining) that are only tested to n=100K or 200K. Let's get a lot of those tested to the n=250K to 500K range.

Bases with > 200 k's remaining at n=25K will not be proven in our lifetimes.

[QUOTE=gd_barnes;469746]Mark (Rogue) came up with it. It's based on the number of tests remaining for an n=25K range on a sieve to P=1T multiplied by the size of a test at the current test limit.

Reb, we already have plenty of bases already tested to n=100K now. All bases with < 200 k's remaining have now been tested to n=100K or are reserved by others and are close. How about we use more resources to test bases with few k's remaining (perhaps < 10 k's remaining) that are only tested to n=100K or 200K. Let's get a lot of those tested to the n=250K to 500K range.

Bases with > 200 k's remaining at n=25K will not be proven in our lifetimes.[/QUOTE]

@Gary: Add them to the recommended list.

Error in sieve file for R1029
 

There is an tiny error in the sieve file for R1029.

[CODE]26 1602635
26 1602651
26 16 2653
26 1602705[/CODE]

Line: 17126

I´ve fixed it for yoyo@home so the sieve should run without probs.

Reserving S497 for sieving, n = 200k to n = 500k.

There are a few more factors found from S256. There is an updated version attached.
Notice: We are using version 1.4.1 sr1sieve for Win, so far there no false factors found.

R800 has been sieved up to P=500e12, factors checked. Sieve file attached.

[QUOTE=MisterBitcoin;470005]There are a few more factors found from S256. There is an updated version attached.
Notice: We are using version 1.4.1 sr1sieve for Win, so far there no false factors found.

R800 has been sieved up to P=500e12, factors checked. Sieve file attached.[/QUOTE]

For S256, the sieve depth is the same as what you previously posted. Why were there more factors found? Was the previous file incorrect?

[QUOTE=gd_barnes;470016]For S256, the sieve depth is the same as what you previously posted. Why were there more factors found? Was the previous file incorrect?[/QUOTE]

No, the file and factors are correct.
There is an delay_bound which tolds the server to generate a file with all found factors after some time without new results returning from users. That bound was 24h. If no new results are coming back within 24h the server will generate an factors_found file.
Now we are using 72h.

Sieve depth is the same.

[QUOTE=MisterBitcoin;470017]No, the file and factors are correct.
There is an delay_bound which tolds the server to generate a file with all found factors after some time without new results returning from users. That bound was 24h. If no new results are coming back within 24h the server will generate an factors_found file.
Now we are using 72h.

Sieve depth is the same.[/QUOTE]

That sounds like a bad way to determine if all factor ranges are complete. In what other manner are you checking to see if all factor ranges are complete? In other words, how can you guarantee that there will not be some more factors that might be returned a week from now?

The BOINC software is checking if all results from the WU´s are comming back or not.

The WU-Generator generates ~10.000 WUs with each 2 Tasks/WU. The software checks if all Tasks are comming back in time, if not new tasks will be generated and sended.

It´s all automatic, like srbase. The software behind it is the same, it´s only speciefied.