[QUOTE=MisterBitcoin;448593]Hello again.
I got some news. I decided to do some initial sieving from S66. I have splitted it into 4 parts, following below:
<snip>
These files are about 50 MB huge. I´ll start working on it in the beginning 2017. If someone want to reserve it, let me know.
I can create an extra account on one of mine servers. ;)

And one more thing:

Reserving S117[/QUOTE]

I will not reserve S66 for you until you begin working on it. Personally I recommend against sieving such large bases. There are many other efforts on the project that are much more useful.

For S117, when reserving a base for sieving, please specify the n-range that you will be sieving.

[QUOTE=gd_barnes;448646]I will not reserve S66 for you until you begin working on it. Personally I recommend against sieving such large bases. There are many other efforts on the project that are much more useful.

For S117, when reserving a base for sieving, please specify the n-range that you will be sieving.[/QUOTE]

Forgot to add the n-range: 100K-200K. (ETA: 4 days)

About S66, it will be started today on my notebook. (Range: k=<5M)
I planed as p-value 500G.
This value should be fair to remove the largest amount of k´s. It´s just to save some time for the BOINC-users and CRUS.
Less PRP´s->less time.

I can send my S66 files to @rebirther directly. Just need to create an guest account on 1 of mine servers. They are too big to upload them on the forum.

hi,
i stopped now the sieve for S742, n=25k to 100k
because rebirther has overtaken the range
and it is already running on the BOINC server
here is a sieve-file for
S742, n=25k to 100k
sieved to 4.6T

hi,
here is a sieve-file for
R742, n=25k to 100k
sieved to 7T

hi,
to gd_barnes:
please do cancel all my reservations on crus
R709, R710, R712
i will stop now sieveing for BOINC

[QUOTE=MisterBitcoin;448664]Forgot to add the n-range: 100K-200K. (ETA: 4 days)

About S66, it will be started today on my notebook. (Range: k=<5M)
I planed as p-value 500G.
This value should be fair to remove the largest amount of k´s. It´s just to save some time for the BOINC-users and CRUS.
Less PRP´s->less time.

I can send my S66 files to @rebirther directly. Just need to create an guest account on 1 of mine servers. They are too big to upload them on the forum.[/QUOTE]

I need an n-range for S66.

[QUOTE=lalera;448725]hi,
to gd_barnes:
please do cancel all my reservations on crus
R709, R710, R712
i will stop now sieveing for BOINC[/QUOTE]

Lalera,

Please see my note in the bases 501-1030 reservations thread.


Gary

[QUOTE=gd_barnes;448736]Lalera,

Please see my note in the bases 501-1030 reservations thread.


Gary[/QUOTE]

hi,
i did read your post - nice
but i will do a pause now for about one year
and i started already my own new project

S320
 

S320 sieved to 30T (P=30e12) for n=200k-500k.


Is there a list/post somewhere of the most wanted/needed bases to be sieved?

[QUOTE=gd_barnes;448729]I need an n-range for S66.[/QUOTE]

Damn, its 25K-100K.
And, p changed to 100G. Test to 500G will took about 4 month on my biggest server.
Next time I wont split the base, the amount of saving time for less k´s against all k´s <20%. (Depending Case S66)
Similar Bases (like R63) are sieved too 100G aswell.

For higher n-values there must be an different way. I send you an PM about that.


I´ll take an eye on the Riesel conjectures. ;)
Good luck to your new project Lalera.

S17 sieving finished
 

Yep, S17 is done. P=95,8T.
Time/factor passed 6000 sec.
File attached as .zip file.


Reserving R214. n=500K-1M

[QUOTE=wombatman;448750]S320 sieved to 30T (P=30e12) for n=200k-500k.


Is there a list/post somewhere of the most wanted/needed bases to be sieved?[/QUOTE]

There is not. Here is my suggestion in order of priority:

1. Sieve bases that are currently searched to n=100K with <= 5 k's remaining for n=100K-200K.

2. Sieve bases that are currently searched to n=200K with 1 k remaining for n=200K-400K or n=200K-500K.

3. Sieve bases that are currently searched to n=25K with <= 150 k's remaining for n=25K-100K.

[QUOTE=gd_barnes;448764]There is not. Here is my suggestion in order of priority:

1. Sieve bases that are currently searched to n=100K with <= 5 k's remaining for n=100K-200K.

2. Sieve bases that are currently searched to n=200K with 1 k remaining for n=200K-400K or n=200K-500K.

3. Sieve bases that are currently searched to n=25K with <= 150 k's remaining for n=25K-100K.[/QUOTE]

Thanks. I'll look at the website and see what the options are. :smile:


Edit: I'll do S688 (k=54, 67, 103) for n=100k-500k.

[QUOTE=sweety439;448769]Even can't I give a suggestion to others? He does not know which base can he sieve.[/QUOTE]

If you would please start working with me in Private Messages, I'm sure you would afterwards be allowed to offer suggestions to other users. Even I, who has been around for nearly 9 years, still takes up directions and suggestions from much never users, from time to time. As I tried telling you in my last Private Message to you, I did not understand your reply. I sure do not see why it should take months to teach you how to do productive works. I've never spend that much time on teaching either Rebirther or Pepi37 the basics of this project, as far as I know them.

I do now, more than I did when I first came to this project, know how much ressources each and every reservation will take. But almost from the first message that Mr. Barnes or Mdettweiler send me, I've produced productive work, some of my work has even helped exposing a bug to some of the first upgrades of Prime95,a bug where the software only wrote15 figures of the residue in stead of 16 figures in the resultfile. I do still believe, that you can be just as productive and welcome as I am, however it requires one thing and nothing more than that one thing:

You have to take up my offer and start working with me on learning how to use the tools we use here. That's all it really requires for you to become a welcome and great contribution to the efforts of CRUS.

Looking forward to be hearing a more detailed reply from you in response to my latest Private Message :smile:

I still have faith in you sweety439, now reach out and let me help you gain other contributors faith and trust :smile:

Take care everyone and remember:

Some times it's better to say nothing at all, if you have nothing kind or nice to say :smile:

I have deleted the last 3 posts by Sweety and most of the related responses including my own responses. I did leave KEP's one response as it is useful.

Sweety, I will now delete all future posts from you until you learn the project. You are filling up our threads with nonsense. You can no longer make suggestions for the project if you are not contributing and appear to be trolling. If you post again without anything useful I will delete it again and ask the super-mods to ban you. Let this be your final warning.

FYI, I am also the admin of the No Prime Left Behind project. You've posted some things over there that are not applicable to that project. This same warning applies over there also.

Maintenance note: I am leaving the listing of all completed sieving reservations in the first post here until the files are reserved for testing and fully primality tested. So the list could get rather large since testing takes much longer than sieving but it shouldn't be filled with obsolete sieving completions that have already been tested. It is easy for me to fail to delete a completed sieving reservation when someone completes primality testing so if anyone would like to occassionally double check the posting against the CRUS pages it would be helpful.

S117 has been sieved to 15T.

Renamed thread since the sieve files can be used by anyone doing testing at CRUS whether or not they run BOINC. I also stickied it.

[QUOTE=MisterBitcoin;448944]S117 has been sieved to 15T.[/QUOTE]

I am going to do a "wrap around" additional sieve on this. That is I am going to sieve the 8 k's for R117/n=100K-250K and also sieve the 3 k's for S117/n=200K-250K in with my sieve to increase the n-range of S117 to n=100K-250K. I will then likely sieve the entire range of both sides deeper than P=15T assuming that the timings show that it should be done, which they likely will since I'm searching a wider n-range.

There are two reasons for this: Most of the low-k bases < 200 have been searched/sieved to n=250K with a previous team effort and it is possible to sieve both sides of a base in one sieving effort using sr2sieve and gain a fair amount of efficiency in the process.

MisterB, that is something that you may not be aware of. If you want to increase efficiency even further you can sieve both sides of the same base in the same sieving effort if both sides are at the same search depth and the difference in the number of k's remaining is reasonable.

I am making a note both in the first post and on the reservations page that additional sieving is being done so that no one reserves the base for testing while all of this is going on.

R214 reached p=45T, file attached.

About the S/R-sieve:

How do you splitt the two bases after sieving? Seems like an script is needed.

[QUOTE=MisterBitcoin;449068]R214 reached p=45T, file attached.

About the S/R-sieve:

How do you split the two bases after sieving? Seems like a script is needed.[/QUOTE]

No. Srfile will do it. While the -a switch writes only one file for both sides in ABCD (sr2sieve) format, the -G switch automatically writes out two files in standard (PFGW or NewPGen) format if you are sieving both sides.

S688 k=54
 

S688 (k=54) has been sieved for n=100k-500k up to 40T. File is attached.

The other two ks (k=67 and 104) are in progress and will ready in about 3 and 6 days, respectively, barring any issues.

[QUOTE=MisterBitcoin;449068]

About the S/R-sieve:

How do you splitt the two bases after sieving? Seems like an script is needed.[/QUOTE]


srfile -G


edit: Doh! just saw Gary's response above...

[QUOTE=wombatman;449076]S688 (k=54) has been sieved for n=100k-500k up to 40T. File is attached.

The other two ks (k=67 and 104) are in progress and will ready in about 3 and 6 days, respectively, barring any issues.[/QUOTE]

Are you using sr2sieve? For > 2 k's sr2sieve is somewhat more efficient and easier to use than multiple instances of sr1sieve. It's also easier to post on the reservations pages since we don't want to post multiple files for a base unless we have to.

I am not, but I can certainly switch over. Is there a good way to combine the separated k files? I was using sr1sieve so I could multithread it on the Ubuntu bash shell in Windows 10.

srfile -G/a firstfile.txt secondfile.txt thirdfile.txt

-G writes newpgen/llr style output for posting & primality testing.

-a writes in sr2sieve format.

Your chosen method may well be a better use of your machine; with 3 k's sr2 is usually faster, but not by a whole lot. If one k is much lower weight, sr1 on each k might be quicker.

That's good to know. I've used srfile plenty but didn't grasp that it could handle multiple files like that. Thanks! :smile:

Reserving R394 for n=100-200K.
(Notice: This is my last sieve with nmax=200K, after this nmax=250K.)

S688 is sieved to P=40e12 for all 3 k's remaining for n=100k to 500k. Both the normal output from srfile and the ABC formatted file are attached.


Edit: And I'll go ahead and do S828 from n=200k-500k.

S1027 will reach 15T on 15.04.2017
S66 (1 out of 4files) will reach 100G on 30.01.17
My Riesel reservation will reach 15T today, time/factor is 1800 (if using single thread) sec, on p=14,4T.

I´ll take S86 and S87 then, booth are at n=1M, sieving too nmax=3M.

R394 sieved to p=15T, file attached.
Only 7,7K n-value´s left, for 3 k´s.

Reserving S86 to nmax=3M.

S828 is sieved to P=30e12 for n=200k-500k. File is attached.

Reserving S514 for n=100k-500k while I'm out for Christmas holidays. :smile:

[STRIKE]Would it make sense for me to take R514 from n=200k-500k as well by sieving with sr2sieve?[/STRIKE]

I'll go ahead and do R514 as well from n=200k-500k. :smile:

I have completed sieving of R117 and S117 for n=100K-250K to P=30T.

R514 and S514
 

R514 and S514 (all k's) have been sieved to P=30e12. File is attached.

Edit: Will sieve S/R564 for n=100k-500k.

S1027 is now at 4,3T.
I needed for this 1,5 months, on my biggest server...
I´d like to release it, it´s taking too long...

[QUOTE=lalera;447248]hi,
the speed is below 4 times but it scales good[/QUOTE]

I am little disappointing about speed using switch "-t 4 " on my I5-4670K
As top command reads CPU utilization, I cannot go above 76%. I can afford few % less then ideal , but 25% is too much to lost.
Any idea, how to increase utilization?

[QUOTE=pepi37;450410]I am little disappointing about speed using switch "-t 4 " on my I5-4670K
As top command reads CPU utilization, I cannot go above 76%. I can afford few % less then ideal , but 25% is too much to lost.
Any idea, how to increase utilization?[/QUOTE]

What else is using CPU? Can you use -t 5 or -t 6?

[QUOTE=rogue;450412]What else is using CPU? Can you use -t 5 or -t 6?[/QUOTE]

Nothing else use cpu

1404 pepi 39 19 7500 244 0 S [COLOR=Red][B]74.9[/B][/COLOR] 0.0 274:36.01 sr2sieve
1402 pepi 39 19 7500 244 0 S [B][COLOR=Red]74.2[/COLOR][/B] 0.0 275:20.12 sr2sieve
1403 pepi 39 19 7500 244 0 S [COLOR=Red][B]72.2 [/B][/COLOR] 0.0 274:53.23 sr2sieve
1405 pepi 39 19 7500 244 0 S [COLOR=Red][B]71.9[/B][/COLOR] 0.0 275:19.42 sr2sieve
1401 pepi 39 19 10180 4888 1952 R [COLOR=Red][B]19.0[/B][/COLOR] 0.1 70:33.86 sr2sieve

This is screenshot from top using t-4 ( Yes, I sow 5 instances of sr2sieve)

Using -t 4 switch I got aprox 48Mp/s , but if I use four separate processes I got aprox 66Mp/s

And screenshot now show 100% CPU uttilization

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1637 pepi 39 19 10128 4616 1840 R [COLOR=Red][B]100.0[/B][/COLOR] 0.1 4:01.22 sr2sieve
1639 pepi 39 19 10236 4748 1936 R [COLOR=Red][B]100.0[/B][/COLOR] 0.1 3:56.49 sr2sieve
1643 pepi 39 19 10436 5084 1936 R [COLOR=Red][B]100.0[/B][/COLOR] 0.1 3:48.91 sr2sieve
1641 pepi 39 19 10340 4924 1880 R [COLOR=Red][B]98.8[/B][/COLOR] 0.1 3:52.62 sr2sieve

[QUOTE=MisterBitcoin;450407]S1027 is now at 4,3T.
I needed for this 1,5 months, on my biggest server...
I´d like to release it, it´s taking too long...[/QUOTE]

Can you Email me the file that you have? That is a good start for a huge effort.

[QUOTE=gd_barnes;450419]Can you Email me the file that you have? That is a good start for a huge effort.[/QUOTE]

Sended, factors removed. It´s now an .prp file. ;)

Status S86: 30,5T
Status S87: 15T

S86 sieved to p=50T.
File attached.

S564 and R564
 

S/R 564 is sieved to P=30e12 for all remaining k's from n=100k-500k.

Edit: Might help to actually attach the file.

I'll do S821 for n=200k-500k.

I found that many sieve file is well under-sieved: but also , maybe is problem in sieve depth ( in header) that is not correct, and sieve was made much deeper.
So when report sieve as done, maybe is good idea to update it to true sieve depth.

[QUOTE=pepi37;450777]I found that many sieve file is well under-sieved: but also , maybe is problem in sieve depth ( in header) that is not correct, and sieve was made much deeper.
So when report sieve as done, maybe is good idea to update it to true sieve depth.[/QUOTE]

To the best of my knowledge all of the sieve depths in the files are correct. I check that what people say they are sieved to is what is in the file. That said, if someone tells me the incorrect depth then it would be incorrect. I can't check everything.

Many files are well undersieved to P=100G. If someone wants to increase the sieve depth on those, that would be helpful.

[QUOTE=wombatman;450767]S/R 564 is sieved to P=30e12 for all remaining k's from n=100k-500k.

Edit: Might help to actually attach the file.[/QUOTE]

I'm out of town for 10 days and my old laptop won't handle 7zip files. Old Windows Vista just can't handle it so I have WinZip on it. Could you do an older zip of the files so that I can post them to the pages?

[QUOTE=gd_barnes;450789]To the best of my knowledge all of the sieve depths in the files are correct. I check that what people say they are sieved to is what is in the file. That said, if someone tells me the incorrect depth then it would be incorrect. I can't check everything.

Many files are well undersieved to P=100G. If someone wants to increase the sieve depth on those, that would be helpful.[/QUOTE]

Look at [B]wombatman[/B] post, and he says that he sieved at P=30e12 or 30000000000000 ( if I understand it)
But when you open 7Z file and look at header it says only 1000000000.
In future, with so many posts, it will be nearly impossible to find this particular post, when correct sieve depth is written. And if somebody continues, he will be lost some time until reach true depth for nothing

SR 564 is in zip file now :)

[QUOTE=pepi37;450794]Look at [B]wombatman[/B] post, and he says that he sieved at P=30e12 or 30000000000000 ( if I understand it)
But when you open 7Z file and look at header it says only 1000000000.
In future, with so many posts, it will be nearly impossible to find this particular post, when correct sieve depth is written. And if somebody continues, he will be lost some time until reach true depth for nothing

SR 564 is in zip file now :)[/QUOTE]

There is a bug in srfile/sr2sieve. The header won´t display the higher sieve depht.
I use 100e6 as initial sieve depht using srsieve. After sieving to (e.g.) 15e12 and deleting factors found using srfile the value keeps at 100e6. [I change that value manually using Notepad++]
This work fine if you use sr1sieve, but somehow only creates this bug for more k-values sieving.

[CODE]ABCD 29*564^$a+1 [100037] // Sieved to 1000000000 with srsieve[/CODE]
Only with srsieve as you can see. And why is it .abcd?

Bug or not, it is easy ( like you do) to make small change in header, and then in future save a lot of time to time right sport for start.

[QUOTE=gd_barnes;450790]I'm out of town for 10 days and my old laptop won't handle 7zip files. Old Windows Vista just can't handle it so I have WinZip on it. Could you do an older zip of the files so that I can post them to the pages?[/QUOTE]

[QUOTE=pepi37;450794]Look at [B]wombatman[/B] post, and he says that he sieved at P=30e12 or 30000000000000 ( if I understand it)
But when you open 7Z file and look at header it says only 1000000000.
In future, with so many posts, it will be nearly impossible to find this particular post, when correct sieve depth is written. And if somebody continues, he will be lost some time until reach true depth for nothing

SR 564 is in zip file now :)[/QUOTE]

Thanks Pepi. I'll try and make sure to fix any future sieved files so they correctly reflect the sieve depth. I do solemnly swear that I sieved SR564 to P=30e12. :smile:

[QUOTE=wombatman;450799]Thanks Pepi. I'll try and make sure to fix any future sieved files so they correctly reflect the sieve depth. I do solemnly swear that I sieved SR564 to P=30e12. :smile:[/QUOTE]

No problem: I hope you didnot understand my critique in wrong way

Not at all! I enjoy continuing to learn more about all of this. :smile:

[QUOTE=MisterBitcoin;450796]There is a bug in srfile/sr2sieve. The header won´t display the higher sieve depht.
I use 100e6 as initial sieve depht using srsieve. After sieving to (e.g.) 15e12 and deleting factors found using srfile the value keeps at 100e6. [I change that value manually using Notepad++]
This work fine if you use sr1sieve, but somehow only creates this bug for more k-values sieving.[/QUOTE]
It's not a bug, really: sr2sieve is designed for distributed sieving. Sieving from 5e12 to 6e12 should not update the header to 6e12, as there might be a gap below 5e12. The programs leave the header untouched, relying on users to manually update when *they* know gaps are filled. sr2sieve uses a checkpoint file to track where it has actually sieved, while the header is for human use.

S821
 

S821 is sieved to P=30e12 for n=200k-500k. File is attached. :smile:

S87 reached p=50T. File attached.

[QUOTE=MisterBitcoin;451119]S87 reached p=50T. File attached.[/QUOTE]

You can also remove those candidates since they have factors

32*87^1002459+1 has a factor: 556573255368421
32*87^1006659+1 has a factor: 911268953003789
32*87^1027003+1 has a factor: 3218020792424693
32*87^1028467+1 has a factor: 291794143979017
32*87^1041187+1 has a factor: 796310494372537
32*87^1045243+1 has a factor: 5193612583315217

S66 update
 

The first part from S66 sieve is done. The next two parts are >p=80B, they should end in a few days.
The last part will be started soon.

There a lot of single Riesel k´s left on n=200K. Let´s sieve them. :) Maybe Wombatman or some else wants to jump on the train.

Taking R867 to nmax=1M. Using the "old" srsieve to avoid any problems.

For a single k, use sr1sieve?

[QUOTE=VBCurtis;451348]For a single k, use sr1sieve?[/QUOTE]

Yes. sr2sieve is build to deal more k´s.

[QUOTE=MisterBitcoin;451347]Taking R867 to nmax=1M. Using the "old" srsieve to avoid any problems.[/QUOTE]
[QUOTE=VBCurtis;451348]For a single k, use sr1sieve?[/QUOTE]
[QUOTE=MisterBitcoin;451349]Yes. sr2sieve is build to deal more k´s.[/QUOTE]
That's not what VBCurtis meant.
He meant "Are you trying to sieve with (old or whatnot) [B]srsieve[/B], not knowing that you should only sieve low n values with [B]srsieve [/B]and then switch to [B]sr1sieve[/B] which is many times faster?"

In fact one should sieve like follows (pay attention to the middle step which removes 25% of candidates and makes next step faster):
[CODE]srsieve -g -n200000 -N1000000 -P1e6 "8*867^n-1"
# optional:
# awk 'NF==2 {print $2%3}' t17_b867_k8.npg | sort | uniq -c
# and observe

[B]awk 'NF!=2 || $2%3!=0' t17_b867_k8.npg > t17_b867_k8.A.npg[/B]

sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
sr1sieve -t 4 -P 1e13 -i t17_b867_k8.1e11.npg -o t17_b867_k8.1e13.npg

# even more optimal is to sieve ranges on 1 CPU each, then combine...
# ... but you have to know how/what you are doing
[/CODE]

[QUOTE=Batalov;451350]That's not what VBCurtis meant.
He meant "Are you trying to sieve with (old or whatnot) [B]srsieve[/B], not knowing that you should only sieve low n values with [B]srsieve [/B]and then switch to [B]sr1sieve[/B] which is many times faster?"

In fact one should sieve like follows (pay attention to the middle step which removes 25% of candidates and makes next step faster):
[CODE]srsieve -g -n200000 -N1000000 -P1e6 "8*867^n-1"
# optional:
# awk 'NF==2 {print $2%3}' t17_b867_k8.npg | sort | uniq -c
# and observe

[B]awk 'NF!=2 || $2%3!=0' t17_b867_k8.npg > t17_b867_k8.A.npg[/B]

sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
sr1sieve -t 4 -P 1e13 -i t17_b867_k8.1e11.npg -o t17_b867_k8.1e13.npg

# even more optimal is to sieve ranges on 1 CPU each, then combine...
# ... but you have to know how/what you are doing
[/CODE][/QUOTE]

I always sieve to 50M using srsieve, not deeper. After sieving to this value sr1sieve catches the factors.

[Its not my first sieve I´m doing. I probably misunderstood Curtis.]

[QUOTE=MisterBitcoin;451351]I always sieve to 50M using srsieve, not deeper. After sieving to this value sr1sieve catches the factors.

[Its not my first sieve I´m doing. I probably misunderstood Curtis.][/QUOTE]

neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.

[QUOTE=VBCurtis;451354]neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.[/QUOTE]

Once the kinks are worked out of the newest srsieve, it will eliminate those terms.

[QUOTE=VBCurtis;451354]neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.[/QUOTE]


Oh, your talking about algebraic factors...............I´ll check with the script.
Your reply was so confusing, just say what you want.
Sry that I falsely understand it, I should stop sieving until all problem solved.

:sad:

[QUOTE=Batalov;451350]
sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
[/QUOTE]

When you use -t 4 what is slowdown comparing to t 1 * 4 instances?

For me on R3, -t 4 is just a bit faster than 3 instances of single-threaded. So, about 20% wasted for convenience. But that's on a hyperthreaded machine; ubuntu doesn't schedule awesomely, so even with 6 tasks running it sometimes doubles up tasks on a single core whilst leaving another core idle.

That info is same for me- one instance gives me 53Mp/s but t 4 gives me 169 Mp/s

R867 finished to p=50T. File attached.

As I stated there are a lot of under sieved files for single-k Bases.
Reserving S406 (1k) from n=200K to N=1M. planned pmax=50T

[QUOTE=MisterBitcoin;451849]R867 finished to p=50T. File attached.[/QUOTE]

1157 algebraic factors removed
corrected sieve file attached

S406 sieved to p=50T.
Checked for alg. factors, nothing found.

These file was finished 04.02, failed to upload.

Reserving S55 (n=1-3M, all k´s) for sieving.
Estimated time needed: one month
Pmax: now running to 75T; maybe deeper depending on time per factor


The last Part from S66 is in work. maybe ~3 weeks.

S66 is done, files are en route via Mail.
Also reserving S81 for n=500K-1M, P=50e12

S55 sieve reached p=75T. File attached.

Reserving S236 for n=100K-250K with pmax=20T

[QUOTE=MisterBitcoin;454759]S66 is done, files are en route via Mail.
Also reserving S81 for n=500K-1M, P=50e12[/QUOTE]

Is the sieve depth for S66 P=100G ? You originally said that you would sieve it to P=500G and then said you would sieve it to P=100G. The depth is not specified here or in your Email. It is also not correct in the files that you sent me.

P=100G is not nearly a deep enough sieve for n=25K-100K for any base except maybe base 3. I suppose that BOINC doesn't care though.

[QUOTE=gd_barnes;454787]P=100G is not nearly a deep enough sieve for n=25K-100K for any base except maybe base 3. I suppose that BOINC doesn't care though.[/QUOTE]

For base 3, optimal sieve is (dependent on your computersystem) somewhere from 35G-50G ... on my system (both Haswell and Sandy Bridge) optimal sievedepth for n=25K-100K for R3 was 35G per 1G range :smile:

[QUOTE=gd_barnes;454787]Is the sieve depth for S66 P=100G ? You originally said that you would sieve it to P=500G and then said you would sieve it to P=100G. The depth is not specified here or in your Email. It is also not correct in the files that you sent me.

P=100G is not nearly a deep enough sieve for n=25K-100K for any base except maybe base 3. I suppose that BOINC doesn't care though.[/QUOTE]

I´m trying to combine these 4 files into 1 file and will sieve deeper, depending of time needed.

[QUOTE=MisterBitcoin;454804]I´m trying to combine these 4 files into 1 file and will sieve deeper, depending of time needed.[/QUOTE]

Too much k´s for sr2sieve. (all 12.000 k´s in one file)
I´m not going to work on S66 for now.

Gary, can you add the current user working on a base listed in the table (extra column)? There is an upcoming stress test on SRBase soon so I can pickup some more bases not reserved by anyone else yet.

[QUOTE=MisterBitcoin;454814]Too much k´s for sr2sieve. (all 12.000 k´s in one file)
I´m not going to work on S66 for now.[/QUOTE]

I'm confused- you reported S66 done, but rather than state the exact depth you searched you tell us you won't work on it. Huh?

As for sr2 not liking so many k's: you may wish to try the -x flag. sr2sieve runs more slowly under -x, but with a fair bit less memory; it's still roughly twice as fast as srsieve when run this way. I haven't tried 12000 k's, though!

[QUOTE=VBCurtis;454828]I'm confused- you reported S66 done, but rather than state the exact depth you searched you tell us you won't work on it. Huh?

As for sr2 not liking so many k's: you may wish to try the -x flag. sr2sieve runs more slowly under -x, but with a fair bit less memory; it's still roughly twice as fast as srsieve when run this way. I haven't tried 12000 k's, though![/QUOTE]

I splitted the base in 4 smaller parts, in the hope it will be faster (hehe, it isn´t).
I was just thinking that it will be faster to sieve p-Range: 100-250G with all 12000 k´s in 1 sieve file.
So: sr2sieve -i input.abcd -p 100e9 -P 250e9 -x -vv
And surprise: "sr2sieve stopped working" right after he tried to start sieving, so 12K might be too much k´s.
Any part should be at 100G.

PS: I use -x for sieves with >100 k´s, its skipping the lookup tables with is time consuming.
PSS: I´m on travel and wont have a good network connection, I´ll answer any questions on 17/03/2017.

We do not need any additional sieving done for S66 for now. What you have done is a good starting point. I am aware that all files have been sieved to P=100G. They do need to be sieved more deeply by someone if they decide to work on S66 although BOINC may choose not to do so.

The files are too large for me to manipulate. Per my email I do need you to convert one of the files from -G format to -a format so that they are all in a consistent format. I also need all of the sieve depths corrected to 100G.

It is too time consuming for me to manipulate everything that I get into a consistent format, especially large files, before I post them on the pages.

In the future I am going to ask that we not work on sieving these monsterous bases individually except maybe base 3. Such efforts should be undertaken by the project when we decide that the bases are worth pushing further.

[QUOTE=rebirther;454820]Gary, can you add the current user working on a base listed in the table (extra column)? There is an upcoming stress test on SRBase soon so I can pickup some more bases not reserved by anyone else yet.[/QUOTE]

No. You can refer to the regular reservations pages for reservations. It's already a big effort to keep all of the threads synced up between the 1k bases and recommended bases and the main reservations pages. I attempt to make sure that the bases shown in the first post here are removed when someone completes primality testing on them but I don't want to add reservations to it.

[QUOTE=gd_barnes;454908]We do not need any additional sieving done for S66 for now. What you have done is a good starting point. I am aware that all files have been sieved to P=100G. They do need to be sieved more deeply by someone if they decide to work on S66 although BOINC may choose not to do so.

The files are too large for me to manipulate. Per my email I do need you to convert one of the files from -G format to -a format so that they are all in a consistent format. I also need all of the sieve depths corrected to 100G.

It is too time consuming for me to manipulate everything that I get into a consistent format, especially large files, before I post them on the pages.

In the future I am going to ask that we not work on sieving these monsterous bases individually except maybe base 3. Such efforts should be undertaken by the project when we decide that the bases are worth pushing further.[/QUOTE]

I´ll do that at Friday (if I´m back at home on that Day).
Anyway I´ll do some single k´s-bases (57 bases left with no sieve file) in the next months.

The new s66.7z is en route to your mail.

S236 has been sieved to pmax=20T, file attached

Reserving R1024 with n=1M-3M and pmax=75T
Reserving R1029 with n=1M-3M and pmax=75T

Can I get a file with k´s-remain at n=10K for Base S361?
I´d like to start sieving on it.

Attached are S361 k's remaining that have only been searched to n=10K. All others are being searched by S19 and have been searched to n=80K.

[QUOTE=gd_barnes;455334]Attached are S361 k's remaining that have only been searched to n=10K. All others are being searched by S19 and have been searched to n=80K.[/QUOTE]

Thanks. Reserving S361 for sieving n=10K N=25K.

Much faster then suggested I reached R1024 with the sieve limit p=75T, the sieve file is attached.

Reserving R347 for sieving n=400K-1M with p=50T. (sr1sieve said this only takes 3 days.:smile: )

R347 reached p=50T, file attached.

R549 reached p=50T, file attached.

Reserving S212 from n=200K-500K, pmax=30T.
There only 1112 canidates left on this n-range for k=68 (@500G).

R1029 reached p=75T, file attached.
Reserving R549 for n=400K-1M and pmax=75T

Sieving for Bases S81 and S212 is finished, files attached.

S212, p=30e12
S81, p=79e12

Reserving S214 (n=200K-500K) and S504 (100K-250K)

And there we go, one more sieve file is done.
S504 reached p=15T, file attached.

Reserving S48 for n=100K-250K.

R27
 

Double Secret Probation Edit:

Let's try this again. I sieved R27 from n=2M to 3M up to P=30e12 on the RPi. File is attached.

I'll sieve R702 from n=200k-400k.