[QUOTE=pinhodecarlos;434325]KEP,

Can you share the files through torrent? If so you can send me the files and I'll share/store them on my cloud.

Kind regards,
Carlos[/QUOTE]

Thanks for the offer. I haven't looked into the torrent thing yet, however Pepi37 send me a website explaining how to create a torrent and distribute the huge datafiles through a torrent file system. It seems very helpfull and a usefull tool for the future. Unless Gary objects on using torrents for the future sending of resultfiles for 0-25K and hundreds of millions of k's :smile:

Must say, that Dropbox, helped me solve the problem I had uploading the final 2 datafiles, since GoogleDrive kept failing to complete the upload, I tried using dropbox and everything worked as it used to do on GoogleDrive.

Should I ever start up huge ranges in the future and have problems uploading and send to Gary, I'll remember your offer (I hope) :smile:

[QUOTE=Mini-Geek;434326]You might try torrents to transfer the data directly to Gary (or whoever else is supposed to receive it or, as Carlos offered, an intermediary).[/QUOTE]

Thanks for your advice. I might very well do so in the future, should I have any problems sending 1 or 2 GB huge starting new ranges resultfiles.

[QUOTE=VBCurtis;434331]srsieve is barely more efficient for tens of thousands of k's instead of mere thousands. So, the optimal sieve depth hardly changes. For instance, on my sieves from 100k to 500k for R3, working a 2G range means optimal depth about 10% deeper than working a 1G range. If each doubling remains 10% deeper, 64G is 5 doublings of 2G, so optimal depth would be around 60% deeper than it is for 2G. I doubt there's 10% efficiency to gain above ~5G, though, so it could be as low as 15-20% deeper than optimal for 2G.

Of course, there's no reason to sieve the entire 64G range for 25-100k, since quite a bit is already done to 100k. Also, KEP is correct that testing part of a range before finishing the sieve both reduces the time spent sieving and increases the optimal depth; a plan such as sieve to 15G, test 25-35k, remove k's, sieve to 30G, test 35-50k, remove k's, sieve to 45G and test the rest is likely to reduce the total time to complete 25-100k sieving + testing combined vs sieving to 35G and then testing the entire file.

KEP- File transfers for 25-100k work will be orders of magnitude smaller than your 0-25k work. I bet google drive will be fine for working 2G or 4G ranges from 25-100k.[/QUOTE]

Just to confirm, I completely agree with your statement.

If you need my support in the future please PM me.

[QUOTE=pinhodecarlos;434396]If you need my support in the future please PM me.[/QUOTE]

I sure will. Especially since the torrentsystem is a whole new world to me (especially from creating a new torrent and start sharing some of my own work).

Unzipped a prime for all remaining k is only about 5 MB. That will be smaller zipped and easily sent via e-mail. Does anyone have an estimate for how long it would take to test (presuming sieving is already done) 10,000 k for R3 from n=25000 to n=100000? Maybe individuals should just test to n=50000 and have rebirther put the 50000 to 100000 range on BOINC like he has for R63.

I have a backlog of 100k-500k files for BOINC. Tests under 100k are so short, combined with the data management overhead for such large files, that I hope we'll stick to 100k-up on BOINC, with 25k-100k as individual tasks. I think it would be unhelpful to delay the 100-500k testing by adding lower tests to BOINC.

BOINC is doing 1G to 6G from 100k to 500k, with me doing all the sieving (3 separate sieves, so I have sieving to do while BOINC runs another region). I am likely to add 6G-8G once one of the regions completes to 500k.

When 1G-2.147G completes to 500k, I will begin sieving 0-2.147G from 500k to 3M, to generate some top-5000 size tests. This is the largest region that can be sieved with sr2sieve. In the long run, it would be nice to also sieve 500k-3M for 2-6G, but I would need help with that since it's srsieve and half the speed or worse (and not multi-threaded).

[QUOTE=KEP;434392]Unless Gary objects on using torrents[/QUOTE]
He does, we kicked each other in the nose few times until I was able to send him, and he successfully received, the low-primes for R66 :razz:
(which is still progressing, but at a much slower rate now, due to Thai torrid summer days, which we hope will end soon, in a week or two, then the rainy season starts)

[QUOTE=VBCurtis;434422]I have a backlog of 100k-500k files for BOINC. Tests under 100k are so short, combined with the data management overhead for such large files, that I hope we'll stick to 100k-up on BOINC, with 25k-100k as individual tasks. I think it would be unhelpful to delay the 100-500k testing by adding lower tests to BOINC.

BOINC is doing 1G to 6G from 100k to 500k, with me doing all the sieving (3 separate sieves, so I have sieving to do while BOINC runs another region). I am likely to add 6G-8G once one of the regions completes to 500k.

When 1G-2.147G completes to 500k, I will begin sieving 0-2.147G from 500k to 3M, to generate some top-5000 size tests. This is the largest region that can be sieved with sr2sieve. In the long run, it would be nice to also sieve 500k-3M for 2-6G, but I would need help with that since it's srsieve and half the speed or worse (and not multi-threaded).[/QUOTE]

I have loaded the last range 450-500k for 1G-2.147G but Iam still having trouble with bluescreens in the last week, maybe a RAM module is broken. Before I can load more work I must fix this nasty thing. I will further working on the R3 and R63 ranges until they are complete but they have millions of tests.

@Rogue: On a Sandy Bridge i5-2300 @ 2.8 GHz, it could propably be done for 10000 k's in about 150-200 days. Unfortunantly running below n=100K will cost us a lot of CPU time, when BOINC results has to be compressed before the next test begins. For PRPnet, more time will be spend communicating with the server, to send and recieve work, than actual crunching would be done (For n<=50K).

I really wish that more people would join the effort and start working the range n=25K-100K on their own computers using LLR. The fastest is simply to run a non-PRPnet and non-BOINC solution for base3 for n<=100K, due to the very small and fast tests. If people do not want to test 10's of thousands of k's by them self, we could maybe have someone organize a 100 or 1000 k's search for n=25K to n=100K. That is even for those easily bored a manageable task.

@VBCurtis: I'm not sure I'm gonna be able to help you on the sieving. I'm still considering weather to skip my base 16 reservation and focus 100% on testing the n=25K-100K range, but I still haven't decided on that part yet. What I am sure though, is that my Sandy Bridge will stay on R3, however the Haswell may not get back to R3 :smile:

@LaurV: Wow that sounds harsh... I really hope that both of you still have safe and sound noses :wink: ... Well the problem may not occur again, that I have to use google drive again. I'm keeping my dropbox and I'm most likely not going to start up new ranges that produces 1-2GB large result files, anytime soon (if ever). Thanks for your input anyway :smile:

KEP
I do test on 13000014446*3^n-1 at 50 K and on 4GHz Intel LLR time is 2.68 seconds
So sieve will be fast because it is easy to sieve to the point where exclusion rate is 3 seconds or more.

If I take for example 1000 candidates on 12 cores then it is easy to give each core 84 K and start LLR .

If this can help your effort I will be glad to help.
Of course in mean time I will stop all my activities on reserved CRUS base ( but I assume nobody will blame me for that)
All is effort :)