NPLB on BOINC?

[mdettweiler]

Originally Posted by gd_barnes

That will never go away as long as I'm one of the moderators anyway. I personally have limited machines that can be connected. But I have a much larger arsenal of machines that cannot be connected without great risk or expense.

My objective is to appeal to the most prime searchers possible in the long run but that those searchers understand things well enough to be able to talk about them.

Carlos and Anon and others if you're interested, there is ONE main thing that I could perhaps see BOINC being used for in the future and it would not be for NPLB (for the foreseeable future anyway). It would be for the extremely high n-ranges at CRUS. For instance, for n>2M for bases that are powers of 2 or for n>~500K for non-powers of 2 bases, I could see that being a possibility. For instance, I see base 6 as an extremely important base in the future to be proved; on par with base 5. But with 49 k's remaining at n=50K on the Sierpinski side, it's almost guaranteed that we'll be searching that well past n=1M (perhaps upwords of 10M or higher to knock out the very last one). And for a base that isn't a power of 2, we're looking at many hours per test at n=1M.

I feel that once testing gets into the many hours per test range, the more that we just need raw computing power. It becomes less fun and more work at that point. That's when I think BOINC becomes more useful.

My two cents anyway. Of course that's a long-time off yet. Any input is always welcome.


Gary

Yes, I agree, BOINC would be quite useful for high-n CRUS testing, more so than NPLB. As for how far we might need to go to prove some of the conjectures, just look at Riesel Sieve and SoB.

[jasong]

Originally Posted by gd_barnes

...I feel that once testing gets into the many hours per test range, the more that we just need raw computing power. It becomes less fun and more work at that point. That's when I think BOINC becomes more useful.

My two cents anyway. Of course that's a long-time off yet. Any input is always welcome.


Gary

Yeah, about that...

You probably won't be too worried about that in the next 6 months to a year. There's this little thing called a graphics card LLR testing program that's in pre-alpha right now.

It's going to blow the present stuff out of the water.

[em99010pepe]

A prime time challenge is underway on PrimeGrid Project so I decided to give it a try last Thursday on my Quad. The challenge is for Proth Prime search LLR beyond 340k for BOINC users.
One thing I noticed, for small numbers like the ones tested llrnet is far away better than BOINC. Here are the reasons:

1º - At least one core is wasted when downloading new tasks. Boinc.exe gets busy. This means that I had 3 cores at 25 % and the last one busy on Boinc.exe.
2º - You have at least 2 programs running at the background per core, the llr application and the wrapper. Double memory wasted when compared with llrnet.
3º - There's a delay of 3-4 seconds everytime a new test is started because the previous programs have to shutdown and restart. On llrnet the delay can be minimized by increasing the cache size to at least 2.
4º - They have a limit of candidates to cache so you can't make huge dumps (DPC way)

I suppose for big numbers the sum of delays by the end of the day is much much smaller.

Carlos

[Lennart]

Originally Posted by em99010pepe

A prime time challenge is underway on PrimeGrid Project so I decided to give it a try last Thursday on my Quad. The challenge is for Proth Prime search LLR beyond 340k for BOINC users.
One thing I noticed, for small numbers like the ones tested llrnet is far away better than BOINC. Here are the reasons:

1º - At least one core is wasted when downloading new tasks. Boinc.exe gets busy. This means that I had 3 cores at 25 % and the last one busy on Boinc.exe.
2º - You have at least 2 programs running at the background per core, the llr application and the wrapper. Double memory wasted when compared with llrnet.
3º - There's a delay of 3-4 seconds everytime a new test is started because the previous programs have to shutdown and restart. On llrnet the delay can be minimized by increasing the cache size to at least 2.
4º - They have a limit of candidates to cache so you can't make huge dumps (DPC way)

I suppose for big numbers the sum of delays by the end of the day is much much smaller.

Carlos

You can't compare like that on a challange

I dont think you understand the amount of work in two days !!

We have done all odd k 5-1199 from n=393k to n= 435k !!! In 2 days !!
and all is dubblechecked !

How many LLRNet server do you think you need todo that in 2 days


No First of all you need to have a cache You cant download wu every time they are finnished.

I think you have to see this in another point of wiev when we run a challange

/Lennart

[em99010pepe]

I am talking about the behave of BOINC application. Open the task manager and watch the waste of processing time when you test small candidates.

[Lennart]

Originally Posted by em99010pepe

I am talking about the behave of BOINC application. Open the task manager and watch the waste of processing time when you test small candidates.

Even if you have some delay its much faster then LLRNet becuse we use a later version of LLR. I have never thought that Boinc should do LLR faster and i don't see a way to get Boinc LLR faster then LLR. We use same LLR that you use when you run manuell LLR.

I do use LLR 371 when i do test and i cant see that its faster.

/Lennart

[em99010pepe]

Originally Posted by Lennart

Even if you have some delay its much faster then LLRNet becuse we use a later version of LLR. I have never thought that Boinc should do LLR faster and i don't see a way to get Boinc LLR faster then LLR. We use same LLR that you use when you run manuell LLR.

I do use LLR 371 when i do test and i cant see that its faster.

/Lennart

Once again I am talking about the waste of CPU time. If llrnet gets 3.7.1c version boinc is beaten.