![]() |
n=496K-500K results have been verified and processed. The range is now considered complete.
|
485.3-.4 and .8-.9 complete no primes
I'd like to reserve 530.0-531.0, even though there's more available between there, if that's ok, because of the FFT size cutoff for the varying k's (I use a spreadsheet I made to keep track of times and it doesn't support different timings for different pairs, so for timing and management purposes of keeping my cores balanced, I'd rather have it all in the same FFT for the whole range; the cutoff for k=400 is just under 530K). I'd like it in two evenly split files. |
[quote=Mini-Geek;137922]485.3-.4 and .8-.9 complete no primes
I'd like to reserve 530.0-531.0, even though there's more available between there, if that's ok, because of the FFT size cutoff for the varying k's (I use a spreadsheet I made to keep track of times and it doesn't support different timings for different pairs, so for timing and management purposes of keeping my cores balanced, I'd rather have it all in the same FFT for the whole range; the cutoff for k=400 is just under 530K). I'd like it in two evenly split files.[/quote] Reserving ahead of the leading edge is fine with a relatively small gap like this. What's your ETA for an n=1K range at n=530K? If it's more than ~5 weeks, then how about an n=600 range? Quick question...How low of an n-range would it need to be to be ("to be to be" lol, I think that's correct grammar here!) fully below the fftlen change? I haven't tracked that on this project although I could start doing so. I ask because if it's not too low, I can consider pulling the first or last part of a range out of a server; preferrably port 400, since I've been generally the only one running that one for a while now. That and we're still ~1 week from getting into the higher testing ranges that are loaded into the 2 ports (assuming current resource allocation). Gary |
[quote=gd_barnes;137941]Reserving ahead of the leading edge is fine with a relatively small gap like this.
What's your ETA for an n=1K range at n=530K? If it's more than ~5 weeks, then how about an n=600 range? Quick question...How low of an n-range would it need to be to be ("to be to be" lol, I think that's correct grammar here!) fully below the fftlen change? I haven't tracked that on this project although I could start doing so. I ask because if it's not too low, I can consider pulling the first or last part of a range out of a server; preferrably port 400, since I've been generally the only one running that one for a while now. That and we're still ~1 week from getting into the higher testing ranges that are loaded into the 2 ports (assuming current resource allocation). Gary[/quote] Well, I'd be about 1.345 ms (at 40K) instead of 0.969 (at 32K), coupled with the higher number of iterations, it would be a good bit longer than the 485 range, which will take about six weeks total. I'll take n=600 instead. To be fully 32K, it would need to be below 508086, for fully 40K, above 529770. I use some LLR-Tools that someone posted on the forums (I don't remember where exactly) to calculate that. |
[QUOTE=Mini-Geek;137943]I use some LLR-Tools that someone posted on the forums (I don't remember where exactly) to calculate that.[/QUOTE]
look here: [url]http://www.mersenneforum.org/showpost.php?p=129893&postcount=28[/url] |
Thanks for the reference Karsten. Just to clarify, I'm using the fft_len program of that. I had some trouble with the other timing programs, and like my spreadsheet better, unfortunately it's rather simplistic and can only handle a single timing.
[quote=Mini-Geek;137943]...485 range, which will take about six weeks total...[/quote] Correction: about 5.4 weeks total. I started it 15 June and the estimate is 23 July. This is 38 days, or 5.428571... weeks. I'll still take smaller (n=600) files, as, with all the other things to make future ranges take longer, will probably take about a month. |
[quote=Mini-Geek;137949]Thanks for the reference Karsten. Just to clarify, I'm using the fft_len program of that. I had some trouble with the other timing programs, and like my spreadsheet better, unfortunately it's rather simplistic and can only handle a single timing.
Correction: about 5.4 weeks total. I started it 15 June and the estimate is 23 July. This is 38 days, or 5.428571... weeks. I'll still take smaller (n=600) files, as, with all the other things to make future ranges take longer, will probably take about a month.[/quote] Great, thanks for the analysis. I've used the tool you talked about and it works well. Anon, can you send him n=530K-530.6K when you get a chance? I'll update the known primes list early morning Fri. Gary |
[quote=Mini-Geek;137949]Thanks for the reference Karsten. Just to clarify, I'm using the fft_len program of that. I had some trouble with the other timing programs, and like my spreadsheet better, unfortunately it's rather simplistic and can only handle a single timing.
Correction: about 5.4 weeks total. I started it 15 June and the estimate is 23 July. This is 38 days, or 5.428571... weeks. I'll still take smaller (n=600) files, as, with all the other things to make future ranges take longer, will probably take about a month.[/quote] The n=530K-530.6K range has been sent to you. Gary |
1 Attachment(s)
521.3K-521.8K complete, 1 prime previously reported. lresults attached. :smile:
|
Beyond's range 486K-496K is complete, lresults emailed to Gary. :smile:
|
Beyond is releasing his range of 510K-520K. I'll take 510.0K-510.5K for me, 510.5K-516K will go to LLRnet AES300, and 516K-520K will go to LLRnet IB400. :smile:
(Edit: knpairs sent to Adam and David for their respective servers.) |
| All times are UTC. The time now is 22:54. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.