Bases 251-500 reservations/statuses/primes

[em99010pepe]

Originally Posted by gd_barnes

People make way too big of a deal about a 10-20% boost in speed. Anon and I had a PM exchange about this. My motto:

Slow and steady wins the race.

In the long run, if your machines are always running, you will outpace most searchers whose computers spend at least 10-20% of their time idle because of reserving manual ranges or deciding what to do next. I suspect that for many people, it is longer than that because they are trying to decide what to do.

It's why I keep finding primes day-in and day-out at NPLB with almost no effort since I moved 5+ quads to drive 1. Those babies never stop! I'm out of town right now and I can't do anything with my machines. They just crunch away and suck my electricity while I'm gone. lol

So my opinion: Ignore the speed boost and put over half of your machines on LLRnet from some project. For less than half that you can always quickly add manual files to: Use those for manual reservations.

The best of both worlds...


Gary

10-20 % idle times?! Where did you get that? It's stupid.
Make a test with different bases and ranges for llrnet and llr standard client and then don't come with that crap of ignoring the speed boost. That's the talk of someone who is ignorant on this matter.

You would get a lot of primes if you run the standard client in all your cores. Leave one to llrnet and the probability will low, you have all your cores in there! You know what's the problem with llrnet for NPLB? Waste of time by running llrnet and doublecheks at the same time.

A few timings for base 2 high n:

llrnet:
64494*2^1937858+1 is not prime. RES64: 069AD8EFB4AA8A0A Time: 7396.367 sec.
64494*2^1938146+1 is not prime. RES64: 560645A6CB1D4FD7 Time: 7139.231 sec.
64494*2^1938506+1 is not prime. RES64: FF5B25D71A310702 Time: 7514.914 sec.


llr 3.7.1c

64494*2^1955306+1 is not prime. Proth RES64: D1E445EF4A40DF51 Time : 6389.697 sec.
64494*2^1955426+1 is not prime. Proth RES64: 57365A75AE2CB681 Time : 6380.260 sec.
64494*2^1955954+1 is not prime. Proth RES64: A22BFC12F6A94C7A Time : 6381.957 sec.

If you have Win XP install logmein free to remotely control all your cores and use the standard client for testing.

[mdettweiler]

Originally Posted by em99010pepe

10-20 % idle times?! Where did you get that? It's stupid.
Make a test with different bases and ranges for llrnet and llr standard client and then don't come with that crap of ignoring the speed boost. That's the talk of someone who is ignorant on this matter.

You would get a lot of primes if you run the standard client in all your cores. Leave one to llrnet and the probability will low, you have all your cores in there! You know what's the problem with llrnet for NPLB? Waste of time by running llrnet and doublecheks at the same time.

A few timings for base 2 high n:

llrnet:
64494*2^1937858+1 is not prime. RES64: 069AD8EFB4AA8A0A Time: 7396.367 sec.
64494*2^1938146+1 is not prime. RES64: 560645A6CB1D4FD7 Time: 7139.231 sec.
64494*2^1938506+1 is not prime. RES64: FF5B25D71A310702 Time: 7514.914 sec.


llr 3.7.1c

64494*2^1955306+1 is not prime. Proth RES64: D1E445EF4A40DF51 Time : 6389.697 sec.
64494*2^1955426+1 is not prime. Proth RES64: 57365A75AE2CB681 Time : 6380.260 sec.
64494*2^1955954+1 is not prime. Proth RES64: A22BFC12F6A94C7A Time : 6381.957 sec.

If you have Win XP install logmein free to remotely control all your cores and use the standard client for testing.

That's all fine and good for base 2, but actually there's no speed difference at all between LLRnet and manual LLR (or even PRP, for that matter) when doing non-base-2 numbers. No changes were made to LLR's PRP code between LLR 3.5 (i.e. LLRnet) and LLR 3.7.1c.

So, for non-base-2 stuff, LLRnet truly is the best way to do it (unless, of course, your machine is offline, in which case you have to use manual LLR).

[em99010pepe]

Originally Posted by Anonymous

That's all fine and good for base 2, but actually there's no speed difference at all between LLRnet and manual LLR (or even PRP, for that matter) when doing non-base-2 numbers. No changes were made to LLR's PRP code between LLR 3.5 (i.e. LLRnet) and LLR 3.7.1c.

So, for non-base-2 stuff, LLRnet truly is the best way to do it (unless, of course, your machine is offline, in which case you have to use manual LLR).

Put here the comparison, I believe seeing. In base 5 llr is quicker than llrnet.

[Lennart]

156511*2^4771128+1 is not prime. Proth RES64: E519F45588C4D5C9 Time: 5753.949 sec.

156511*2^4771128+1 is not prime. Proth RES64: 3B4D28175B337C21 Time: 2998.044 sec.

156511*2^4771128+1 is not prime. Proth RES64: E7844006985CE642 Time: 7437.252 sec.

156511*2^4771128+1 is not prime. Proth RES64: FD85563B91194E69 Time: 4925.604 sec.

Just to give you something more to think on

/Lennart

[em99010pepe]

Originally Posted by Lennart

Just to give you something more to think on

What about some clues about the llr version?!

[Lennart]

Originally Posted by em99010pepe

What about some clues about the llr version?!

3.7.0 on all.

This is from Boinc and it shows that you need to check res64 !

The 5th is out now.

/Lennart

[gd_barnes]

Originally Posted by em99010pepe

10-20 % idle times?! Where did you get that? It's stupid.
Make a test with different bases and ranges for llrnet and llr standard client and then don't come with that crap of ignoring the speed boost. That's the talk of someone who is ignorant on this matter.

You would get a lot of primes if you run the standard client in all your cores. Leave one to llrnet and the probability will low, you have all your cores in there! You know what's the problem with llrnet for NPLB? Waste of time by running llrnet and doublecheks at the same time.

A few timings for base 2 high n:

llrnet:
64494*2^1937858+1 is not prime. RES64: 069AD8EFB4AA8A0A Time: 7396.367 sec.
64494*2^1938146+1 is not prime. RES64: 560645A6CB1D4FD7 Time: 7139.231 sec.
64494*2^1938506+1 is not prime. RES64: FF5B25D71A310702 Time: 7514.914 sec.


llr 3.7.1c

64494*2^1955306+1 is not prime. Proth RES64: D1E445EF4A40DF51 Time : 6389.697 sec.
64494*2^1955426+1 is not prime. Proth RES64: 57365A75AE2CB681 Time : 6380.260 sec.
64494*2^1955954+1 is not prime. Proth RES64: A22BFC12F6A94C7A Time : 6381.957 sec.

If you have Win XP install logmein free to remotely control all your cores and use the standard client for testing.

I'm not referring to mega-tests. Of course it makes sense to do what you did regarding the mega-tests you did here. I'm referring to the amount of time people let their computers sit idle because they are reserving manual ranges and those ranges finish in the middle of the night or while on vacation. Once again...slow and steady wins the race.

It happened to me; I know. It takes tremendous effort to make sure that 20-25 cores are busy constantly with no idle time when running manual processes. Invarabily there would be 2-3 that I would forget about and they would finish in the middle of the night or while I was on vacation.

Of course you can use remote access to control things while you are on vacation but who really wants to mess with that in a tropical resort somewhere? If I'm on a TRUE vacation such as I was in Mexico in March, the last thing I want to be doing is managing my machines.

If you like playing with your machines a lot, I suppose the manual system is the way to go. For me, I like some of both with a majority LLRnet because it takes too much of my personal time otherwise.

Why don't you take a survey of people with 50+ cores and see which they prefer?


Gary

[gd_barnes]

Originally Posted by Lennart

156511*2^4771128+1 is not prime. Proth RES64: E519F45588C4D5C9 Time: 5753.949 sec.

156511*2^4771128+1 is not prime. Proth RES64: 3B4D28175B337C21 Time: 2998.044 sec.

156511*2^4771128+1 is not prime. Proth RES64: E7844006985CE642 Time: 7437.252 sec.

156511*2^4771128+1 is not prime. Proth RES64: FD85563B91194E69 Time: 4925.604 sec.

Just to give you something more to think on

/Lennart

HUH?? OK, which is the right residue and which program correctly computed the correct residue? This does not look good.


Gary

[em99010pepe]

Originally Posted by gd_barnes

HUH?? OK, which is the right residue and which program correctly computed the correct residue? This does not look good.


Gary

That's the problem of using BOINC...

[KEP]

Originally Posted by em99010pepe

That's the problem of using BOINC...

LLR at BOINC is not the problem. The code is somewhat the same for LLR for BOINC as for the manual version. Only the few changes needed to make LLR work with BOINC was added (according to my memory). But the coding giving the outputting the residues is the same in BOINC LLR aswell as in manual LLR. So if something is wrong with the Residuals, it is most likely a hardware issue on the machines testing it or maybe it is just the result of an extreme summersday or to much overclocking. So to sum up, if the input is the same in BOINC LLR aswell as in manual LLR, the Residual should always looks the same, unless mistakes has occured during calculation of the LLR task.

Regards

Kenneth!

[em99010pepe]

Originally Posted by KEP

LLR at BOINC is not the problem. The code is somewhat the same for LLR for BOINC as for the manual version. Only the few changes needed to make LLR work with BOINC was added (according to my memory). But the coding giving the outputting the residues is the same in BOINC LLR aswell as in manual LLR. So if something is wrong with the Residuals, it is most likely a hardware issue on the machines testing it or maybe it is just the result of an extreme summersday or to much overclocking. So to sum up, if the input is the same in BOINC LLR aswell as in manual LLR, the Residual should always looks the same, unless mistakes has occured during calculation of the LLR task.

Regards

Kenneth!

It's BOINC guilt because the people who run it don't understand nothing about what they are doing. They don't know they need to have a stable machine to test numbers, they just run BOINC for the stats, to help their teams climb in the stats. It's intrinsic. Of course with the amount of CPU power they have they can easily doublecheck 3, 4, 5 times but that's ridiculous. By 3 or 4 clicks you can easily change BOINC projects even when you are an ignorant on the matter. That should not be like that. People should understand what they are doing, study a little bit of LLR and prime stuff.
Do you want to know the lastes problem of BOINC? It's possible to hijack the teams...true, check here.