Next Available Range

[Matt]

The manual reservation system (http://www.sierpinskisieve.com) has now reached the end of it's current segment of work at 13,000,000. PrimeGrid has reserved all of the ranges from there to 100,000,000, so unless we can have some of that area back from PrimeGrid then I would suggest that jumping that far ahead is a bit of a waste of time - correct?

I would appreciate if a range could be nicked back from PrimeGrid ASAP please?

Also it should be noted that people took up the reservations from 12.8 - 12.9 in a very short space of time (about 2 weeks). Obviously several of these ranges are still in progress but I would appreciate someone else's input on the situation please?

[hhh]

I guess you can just claim some range you want and notify PG; they are nice people and very comprehensive. Just take 50P-51P, for instance; PG should reach that level in half a year or so. H.

[Matt]

Have liased with Joe O and agreed that jumping to 100P is not a problem.

[opyrt]

Just thought I'd mention that moving from 13P to 100P seems to have increased the memory usage per instance of sr2sieve.exe from 80MB to 200MB.

Don't know if others have seen the same, but it might be smart having this in the back of your heads before starting 8 instances of sr2sieve.exe on your dual quad core. :-)

[Death]

how about some double check?

[Nasdaq]

Have liased with Joe O and agreed that jumping to 100P is not a problem.
You guys are nuts - there's no point in sieving at that high level, and you'll break even at best. This is getting extremely close to the point where the average time it takes to find a factor is longer than the time to finish a PRP test.

Unlike GIMPS, we're not trying to find all the primes in the range being sieved. A prime for one of the six k's at 17M, for example, means that all the factors for that k above 17M are now useless, since that k is eliminated. When you take this into account, the optimal sieve depth will be lower: around 50-75P.

[Razor_FX_II]

Just thought I'd mention that moving from 13P to 100P seems to have increased the memory usage per instance of sr2sieve.exe from 80MB to 200MB.

Don't know if others have seen the same, but it might be smart having this in the back of your heads before starting 8 instances of sr2sieve.exe on your dual quad core. :-)

With the amount of memory in a modern day computer I don't see where this is a problem.
Most computers have at least 2gig if not 4-8gig in them from conception.
The introduction of Windows 7 and the availability of 6 ram slot on new I7 motherboards lets these ranges easily fall within the range of any modern day computer.

[opyrt]

With the amount of memory in a modern day computer I don't see where this is a problem.
Most computers have at least 2gig if not 4-8gig in them from conception.
The introduction of Windows 7 and the availability of 6 ram slot on new I7 motherboards lets these ranges easily fall within the range of any modern day computer.

I did not mean in any way that this is a problem. I just wanted to share a fact that is "nice to know". :-)

[Death]

anybody see me? third question at SoB forums and totally ignored by everyone.

[opyrt]

how about some double check?

I'm no guru when it comes to this, but in my mind it does not seem worth it to double check sieving. It would cost alot of CPU time and save very, very, very little CPU time.

In a way, you could say that the PRP tests are double checking the sieving effort anyways.

And from what I understand, all reported factors are validated upon reporting, so it will not happen that a kn-pair is falsely excluded. A double check sieve would then only be useful for finding factors that was lost the first time around, and I doubt there are many.

[opyrt]

You guys are nuts - there's no point in sieving at that high level, and you'll break even at best. This is getting extremely close to the point where the average time it takes to find a factor is longer than the time to finish a PRP test.

From what I see on my testrange above 100P this seems correct. Having 8 cores running for 3 days without a result feels demoralizing.

Matt: Any chance we could get a lower range back from PrimeGrid? In that way we could actually contribute. ;-)

[runesk]

From what I see on my testrange above 100P this seems correct. Having 8 cores running for 3 days without a result feels demoralizing.

Matt: Any chance we could get a lower range back from PrimeGrid? In that way we could actually contribute. ;-)

I've done my last manual sieve range above 100P. Crunching all weekend without a hint of a factor gives me no joy.

My thoughts is that if you want to continue supporting manual sieveing, you should get back some of the range received by PrimeGrid. The other solution is to only support PrimeGrid... (and then you should be removed from DC-Vault as well). I might join PrimeGrid, but at the moment, my focus is non-boinc, and I get some strange satisfaction doing just that (some might consider this some kind of insanity, I'm sure)...

.R

[Matt]

I've messaged Joe O to let him know your concerns.

[Joe O]

I've messaged Joe O to let him know your concerns.




Available: 70000000 -> 80000000

[opyrt]

Thank you guys!

Seems much better.

[wolfemancs]

In the last year (according to the comments on http://www.sierpinskisieve.com/complete.php?all=1 PrimeGrid has gone from 31,587,913 on March 15, 2009, to very near 70,000,000 with the challenge that concluded today.

The manual effort was given back 70-80P on March 31 last year and is currently at 70.96P (last reserved). Would it make sense to give some of this range back to PrimeGrid? Maybe leave the manual sieve another years worth of work and return 72-80 to PrimeGrid?

At the current pace PrimeGrid will be working on the 100P range that you guys didn't think was very profitable before the manual effort even breaks 71.5P leaving 8.5P of "useful" work unsieved while PrimeGrid is doing less useful work.

Even at 65-70P, and even with a 64 bit AMD machine (much better siever than LLR machine), if I decide that all I care about is SoB, and not PSP, it's becoming very close to a push as to whether it's more efficient to sieve or LLR. If PrimeGrid has to bump to 80P it tips even more toward LLR tests.

In the interests of full disclosure, I'm a PrimeGrid siever, not a manual siever, so feel free to ignore me. :-)

[Joe O]

71000000 72000000 is being held for the manual sieve effort.
We've already assigned
72000000 73000000 PrimeGrid
and
73000000 74000000 OnHold will go to whoever needs it first

[Joe O]

73000000 74000000 has just been marked for PrimeGrid

74000000 75000000 is the next available block

If PrimeGrid gets another block done in 4 days, then I will consider giving them 71000000 72000000 and assigning the manual sieve effort 75000000 76000000
Perhaps I should have done that today.