[quote=IronBits;129086]Which is best for sieving, AMD or Intel?
What do we need to run it?
How do we go about doing it?
-newbie[/quote]
AMD's generally do the best at sieving, though the Intel Core2's aren't half bad sievers, either. Essentially, the difference isn't [i]that[/i] terribly great, so I wouldn't consider it much of a deciding factor. On my primary machine (currently Core 2 Duo, used to be a P4), I've done both LLR and sieving.

For the software you need, as well as how to use it, see the first post of this thread--it's got complete instructions for using sr2sieve. (Please note: make sure to get the x86-64 version of sr2sieve if you have a 64bit OS, it's twice as fast!) :smile:

[quote=Mini-Geek;129087]Speaking of that, I started my sieving today, just a few minutes ago. :smile:
Already eliminated about 12 candidates.
If I finish this one in 3 days I'll probably want another 20G-worth (though I realize it may not be one full 20G range).[/quote]
Okay, cool! When you're ready for another range, just give me a holler and I'll get you one. :smile:

Does anybody know if the cpu_secs count in checkpoint.txt is accurate? When I try to compute the p/CPUsec with that, it gives me a very low amount (currently 64404) compared to what I can observe in sr2sieve (currently 95891).

[quote=Mini-Geek;129094]Does anybody know if the cpu_secs count in checkpoint.txt is accurate? When I try to compute the p/CPUsec with that, it gives me a very low amount (currently 64404) compared to what I can observe in sr2sieve (currently 95891).[/quote]
I forget whether sr2sieve computes p/sec using elapsed or CPU time; that might have something to do with it.

[quote=Anonymous;129097]I forget whether sr2sieve computes p/sec using elapsed or CPU time; that might have something to do with it.[/quote]
Well, the checkpoint.txt has both cpu_secs and elapsed_secs, so...it should be full CPU seconds only.

[quote=Mini-Geek;129099]Well, the checkpoint.txt has both cpu_secs and elapsed_secs, so...it should be full CPU seconds only.[/quote]
I [i]think[/i] it uses CPU time to determine p/sec., but I don't know for sure. I think if you look at the end of the "a multiple k/c sieve for Sierpinski/Riesel problems" in the Sierpinski/Riesel Base 5 forum and work your way backwards, you might be able to find out; there was a discussion a little while back about the elapsed vs. CPU time thing.

[quote=Anonymous;129108]I [I]think[/I] it uses CPU time to determine p/sec., but I don't know for sure. I think if you look at the end of the "a multiple k/c sieve for Sierpinski/Riesel problems" in the Sierpinski/Riesel Base 5 forum and work your way backwards, you might be able to find out; there was a discussion a little while back about the elapsed vs. CPU time thing.[/quote]
I couldn't find it in that thread, but maybe it has to do with that I'm using a 1.7.x (experimental builds) instead of 1.6.x. I know it has CPU time issues with multi-threading, but it should still work single-threaded, right?

I've heard that 64-bit OS/CPU can run sieving and TFing far faster than 32-bit. I run 32-bit Windows on a 64-bit capable CPU. Is there any way to run a VM of a 64-bit OS and get the speed increase, or am I limited because I'm running it on top of a 32-bit OS?

[quote=Mini-Geek;129113]I couldn't find it in that thread, but maybe it has to do with that I'm using a 1.7.x (experimental builds) instead of 1.6.x. I know it has CPU time issues with multi-threading, but it should still work single-threaded, right?[/quote]
Aha, that's it. I remember reading that in order to get the timing to work with the multi-threading, Geoff had to switch it to using elapsed time--which unfortunately affects single-threaded mode as well as multi-threaded. :sad:

[quote=Mini-Geek (cont.)]I've heard that 64-bit OS/CPU can run sieving and TFing far faster than 32-bit. I run 32-bit Windows on a 64-bit capable CPU. Is there any way to run a VM of a 64-bit OS and get the speed increase, or am I limited because I'm running it on top of a 32-bit OS?[/quote]
No, unfortunately the only way to get 64-bit speed increases is by running a 64-bit OS. Some virtualization software, such as qemu, can run 64-bit VM's on a 32-bit host OS, but they run reeeeaaaalllly sllllllooooow. Thus, if you want the 64-bit speed benefits, you have to run a 64-bit OS.

Well, floundering around, I managed to download both links and put them into one directory on the 64bit quad.
I see something about a sr2work.txt file (which I don't have)
and a command line of (and I put it in startup.bat)
sr2sieve -p 10e9 -P 20e9 -i nplb-doublecheck-sieve_10G.txt but I don't have that .txt in that directory.
Now what?

03/13/2008 01:10 AM 8,995,261 sr2data.txt
02/29/2008 10:14 PM 71,680 sr2sieve.exe
03/18/2008 07:03 PM 60 startup.bat

310G-550G is available
Let me have 549-550 and see how that goes.
How do I put it in the directory and make it work?

[quote=IronBits;129126]310G-550G is available
Let me have 549-550 and see how that goes.
How do I put it in the directory and make it work?[/quote]

No, only part of 310G-550G is available. See post 1 in thread. Anon will have to tell you what is available.

I still think it make sense to post the exact ranges that are available. When I look at the first post, it's very easy to think that the entire range of 310G-550G is still available.

One option, Anon, is for you and I to complete the odd-ball parts of the various ranges so that only ranges that are even multiples of 1 billion are left. That might be the easiest thing for everyone unless you have a lot of reservations in the partially completed ranges that would make it more difficult to start that at this late juncture.

You're still running the show on this one. I'm just throwing in my two cents here.


Gary