Dual CPU perfomance hit
 

I know that it has been discussed at length in the past, but when a dual cpu has both processors running an LL test each exactly what perfomance hit is seen?

I was just thinking that if you have one cpu on an LL test and another factoring, then as the factoring credit is so much less (10%?), it would make more sense to have both cpu doing LL tests even if the perfomance dipped by 20% for each cpu.

Anyone have any thoughts?

Does facotring take 10% of the time of a LL?

If that is the case, then you wouldn't want a 20% decrease by running two LLs.

well, it depends.. the bottleneck on multiprocessor systems is memory bandwith. Each processor is attempting to constantly access memory. On a multipipeline rambus system, I found I could run 2 instances LL testing with very little performance hit. any more than that and all instances dropped drastically (took twice as long for each processor to finish)

When factoring, the code will fit in the cache of most modern processors, so it doesnt need to access memory very much. Therefore you are in fact getting twice as much work done.. (man, if we could just set it up so that one processor would factor an exponent, and then pass it to the second processor for LL test would be keen.. :) )

Sorry, I can't have explained myself very well.

More than once in the past I have read that factoring gets about 1/10th the p90 cpu years credit that perfoming an LL/DC would get.

My question was that if you only get 10% of the cpu yrs credit for running a second processor on factoring whilst the other is running on an LL test, then it must make better sense to take the slight performance hit you get from both cpu on LL tests.

Or can someone substantiate this better with some benchmarks and cpu yrs credited on a multi cpu setup.

I do think that is an important statistic to be known as the number of multi cpu boards is increasing, and we want to be able to use them to crunch at their maximum cpu yr throughput.

I think what bayanne means is this...

Pretend you have two computers... Each runs for one month... One is running a LL test... The other is running a factoring test... After a month, the LL computer gets 5 years of credit and the factoring one gets ½ year of credit... This is because the credit is weighted to give the LL test more credit...

Anyways, everyone suggests that you run one LL test and one factoring test on a dual CPU system, because running a factoring test on the second CPU causes no performance drop. If you do this, after a month you would have 5.5 years of credit...

But, if the second CPU runs a LL test at ½ speed, due to contention for memory bandwidth, you would get 7.5 years... That is 5 years for the first CPU and 2½ years for the second... Or maybe 3¾ years for each of them...

So it would make more sense to run 2 LL tests even though there is a bottleneck...

IMO, it would be cheaper and more sensible to run two single processor boxes... Then you would get 10 years...

Or maybe I am looking at it wrong?

:D :D

We have never confirmed that time spent factoring is weighted less - hence my question if it gets 10% credit is it because it takes 10% of the time.

Confusion came from one of George's pages that I think we probably misinterpreted. If you ask me now, I'd say that the 10 to 1 ratio mentioned, was probably more about how to climb up the ranks early in the game than about credit weighting.

From the FAQ held at heretics site
[url]http://ws9.jobnegotiator.com/index.html[/url]
in the section entitled Assignments, Testing and Test Results one of the questions is:
"I have been told that you get 1/10th the credit for factoring work. Is this true?" [url]http://ws9.jobnegotiator.com/html/faqs/faq21.html#036[/url]
to which the answer is: "You are correct on the credit for factoring work. "

Could George maybe clarify what the position is?

I have been tracking the performance of my machines, and I have determined that the ratio of TF to LL credit is about 70% on most of them, although IIRC it is slightly worse for the athlons than for P2s or P3s. (That is, a machine that will do 3 P90 years per month LL testing will only do about 2.1 yrs/mo trial factoring.) On a P4 it is much worse, at least before v22. But on a K6 it is reversed; the ratio is about 160%, due to the lack of a decent FPU for LL testing. My 475MHz-K7 was running LL tests slower than my 233Mhz-PPro; now I have them both trial factoring and the K7 is almost twice as fast as the PPro. I wish I had known that all along!

[quote="Digital Concepts"]...hence my question if it gets 10% credit is it because it takes 10% of the time.

[/quote]

From my understanding of whats on the mersenne site, this is how it is. I could be wrong but thats how I take it from reading the site.

Say if Factoring took your Pentium 90 30days of CPU time to complete. Only 3 days of that 30 will be credited. It will be as if it took your CPU 3 days to complete the factoring. Therefore, 3 days of CPU time added instead of 30 in the database.

Hyper Threading
 

:question: I have a quick question about dual CPU's. You can smack me around and call me whatever, but I was interested in something that intel is going to do in the near*(being relative) future with their desktop processors. They are going to put hyperthreading into them, which i am giong to imagine someone is going to build a motherboard that uses dual P4's on it. I know this would seriously put a dent in the Xenon/Itaniuam area seeing as how the only advantage is that it will be able tto address an obscene amount of memory. So enough of that and to my quesion is hyperthreading between multiple CPU's going to affect speeds any? I would imagine so since the processors are working on the same processes and instructions, but then again i don't have much experience with dual CPU's so any insight would be greatly appreciated.
Thanks,
Mivacca2
(I thought about starting a new thread, but there was already one here about dual CPU's so...)

Mivacca2 wrote:

[quote]i am going to imagine someone is going to build a motherboard that uses dual P4's on it. [/quote]and

[quote]is hyperthreading between multiple CPU's going to affect speeds any?[/quote]1. Don't count on it. I doubt Intel will enable SMP on hyperthreaded P4's - or on any P4 for that matter. Why? Two reasons a) Xeon; and b) Xeon. Remember, that since the introduction of the P4, we've seen a determined effort by Intel to deny SMP to the masses - if you want P4 power in SMP .. buy Xeon .. or go back to the P[I]!!!.[/I]
Remember how scared Intel was when those who cared realize the first Celeron's were SMP capable? (I'm writing this from a BP6 w/ 2xCel366 @550 which has performed without incident since 1999). Even P[I]!!![/I] SMP was barely tollerable .. because it was affordable to the masses. SMP P4? Not a chance. Hyperthreading is the closest thing we'll see to SMP on the P4 for the masses.
Besides, think about it - two hyperthreaded P4s = four (potential)processes. You'd need to be running a multi-processor kernal of Linux (are they all multi-processor kernals?) or Win2k/XP $erver. Win2k/XP Pro would only be able to take advantage of one CPU which is "fooling" it into thinking there are two .. the second physical CPU would be occupying wasted space. So don't hold your breath for dual-P4's .. you might turn a very deep shade of purple ;)

2. Hyperthreading - at first glance - in and of itself will only benefit multithreaded applications - those written to take advantage of SMP. Remember hyperthreading "fool's" the OS - and any multithreaded application - into thinking that there are two processors in a single CPU system.
Since Prime95 is a single process application - at present - I doubt you'll see any more of a performance improvement other than that of raw speed - 3GHz+ - mind you, would you be able to get away with running two processes of Prime95 on a hyperthreaded P4?
I can only imagine one thing .. can you say [I]overhead[/I]?
This is because even with multithreaded applications, Intel claims the performance improvement would only be only 25-30% greater than a non-hyperthreaded CPU at the same speed - not that there will be any.
[URL]http://www.theregister.co.uk/content/3/27039.html[/URL][URL="https://oddslot.co.uk/analysis/"]oddslot[/URL]
However, if George or someone else at GIMPS where to write into Prime95 the ablility to "split" a LL test between two processes - which if I recall he indicated was not either workable or inefficient on SMP systems - that was efficient and was at least able to take full advantage of hyperthreading, then I can only imagine some brilliant benchmarks indeed :D

In the final analysis it appears that hyperthreading will be the P4's SMP for the masses or at the very least, the poor person's version - if not a test - of multithreading CPUs which Intel will introduce within the next 24 months +/- to the Itanium core .. in the end .. wouldn't you really prefer a multithreaded IA-64 processor:question: 8) ... with a really, really big cache? :D
[/url]

Stormblade ran some benchmarks on a dual cpu Xeon system earlier this year... He ran benchies with hyper-threading enabled and disabled... I can't remember the exact result, but I think the hyper-threading turned out to not be a good idea... I'll email him the link to this post and maybe he can clarify it for us...

Edit:

Here is what I can find from the mailing list...

[quote]Date: Thu, 7 Mar 2002 17:14:33 -0500
Subject: RE: Mersenne: Hyper-threading

As far as Hyperthreading goes, It is already available in the P4 Xeon chips.
I have personally tested the effectiveness with Prime95, and it does nothing
for our testing. The 2 instances ran normally, but each one took twice as
long as 1 instance would have. I think the only benefit Hyperthreading adds
to any application, is that if a pipeline becomes stalled, another thread
can use the 2nd pipeline, where on a standard P4, if one pipeline is
stalled, the other has to wait for it.[/quote]

And here is from Ars Technica...

[quote]Notes:
we used Advanced:Time rather than the benchmark.
0 and 1 are the physical CPUs, 2 and 3 are the "virutal" CPUs created by hyperthreading
System = 2 2.2GHz P4 Xeon "Prestonia" CPUs. 4GB PC800 Rambus memory. OS=Win2k
Exponent =10M (8.97M to 10.24M(512K) on Mersenne benchmark page)

Test Case 1: Running a single instance of Prime95 on each CPU

CPU # Iteration Time(average in ms)

0 24.081
1 24.024
2 24.042
3 24.044

Test case 2: Running 2 instances of Prime95 on various CPUs

CPU # Iteration Time(average in ms)

0 25.188ms
1 25.161ms

0 25.217
2 25.127

0 48.380
3 47.821

1 47.538
2 46.838

1 25.185
3 25.126

2 25.161
3 25.191

Test Case 3: Running 3 instances of Prime 95

CPU # Iteration Time(average in ms)

0 25.603
1 50.352
2 50.807

0 50.386
2 25.591
3 50.849

Test Case 4: Running 4 instances of Prime95

CPU # Iteration Time(average in ms)

0 56.343
1 55.881
2 55.795
3 56.448

Test Case 5: Running 4 instances of Prime95, Running LL on "Primary" CPUs and factoring on "Virtual" CPUs.

CPU # Iteration Time(average in ms)

0 39.589
1 39.667
2 Factoring
3 Factoring

Test Case 6: Running 4 instances of Prime95, Running LL on 1 CPU, and Factoring on the rest.

CPU # Iteration Time(average in ms)

0 39.003
1 Factoring
2 Factoring
3 Factoring[/quote]

:shock:

Xyzzy found all the info I had on the testing. If anyone doesnt understand the results, I would be glad to explain them.

:)

Edit:

Woot! I got a Shrek Pic! cool! (I do need to stop by more often....)

Duel CPU performance hit
 

I understand that 2 prime LL's running under hyperthreading run twice as fast but how about 1 LL plus 1 factoring will the LL take a hit or not.... THE USER WITH XENON PLEASE LET ME KNOW...THANKS....Larry

Larry-

Look at test case 2 and 5 in Stormblade's chart...

[quote]Test case 2: Running 2 instances of Prime95 on various CPUs

CPU # Iteration Time(average in ms)

0 25.188ms
1 25.161ms

0 25.217
2 25.127

0 48.380
3 47.821

1 47.538
2 46.838

1 25.185
3 25.126

2 25.161
3 25.191

Test Case 5: Running 4 instances of Prime95, Running LL on "Primary" CPUs and factoring on "Virtual" CPUs.

CPU # Iteration Time(average in ms)

0 39.589
1 39.667
2 Factoring
3 Factoring[/quote]

So it looks like running the CPUs as if they were *not* hyperthreaded, by running a single LL test on each physical CPU, results in ~25ms... If you add factoring to each physical CPU, by using hyperthreading, the LL iteration rate drops to ~40ms...

This just illustrates that hyperthreading doesn't do much for a CPU that is already maxxed out... It is more geared for a CPU that is stalled waiting for I/O...

The reason we asked Stormblade for all possible combinations was due to our belief that the multiple processes would also slow down due to bandwidth limitations... The Xeon bus is identical to the P4 bus, which means that a single P4 running Prime95 has 3.2GB/s available to it, but the dual Xeon only has 1.6GB/s per CPU...

But, if I remember right, Earnst Mayer is still working on the dual floating/integer LL tester program. If I understand his approach correctly, he's doing the 'hyperthreading' manually--by interleaving the code for the two tests.

I think he expects some speed improvement. Is that just due to the processors he's targeting? AXP and such?

[quote]
wouldn't you really prefer a multithreaded IA-64 processor:question: 8) ... with a really, really big cache? :D
[/url][/quote]


Would I prefer one, hell yes who wouldn't? :) Unfortunately.... I would prefer the price of a P4 to that of a Ia-64 chip *cringes in fear* :( It'll be ok though... We will just have to see what happens when they change the core and the new socket configuration with the next pentium....

MiVacca2

If we're just dreaming, I'll take a 2Ghz EV8. Hyperthreading? Naw, SMT. More execution units need more issueable instruction. *drool*

To bad it's dead. Thank you Compaq/HP. HP, putting the risk in RISC.

[quote="willmore"]But, if I remember right, Ernst Mayer is still working on the dual floating/integer LL tester program. If I understand his approach correctly, he's doing the 'hyperthreading' manually--by interleaving the code for the two tests.

I think he expects some speed improvement. Is that just due to the processors he's targeting? AXP and such?[/quote]

David. see my recent posting on this topic in the Math section.

-Ernst

Best mix for Dual P4?
 

I was reading earlier in this thread about memory contention with dualies and wanted some suggestions for the best mix of crunching for my situation.
I have 5 dual P4 Xeon boxes from Dell. 2 are 2.2GHz with 1Gb RAM and 3 are 1.7GHz with 512Mb RAM. All RAM is PC-800. Nothing is overclocked (or very overclockable since they're Dells). Everything's running RedHat Linux with 2.4.x kernels.
My goal is to have good LL stats and have a chance of finding a prime number. It'd be nice to find a 10 million digit prime too but I'm not holding my breath. I'm not eager to do a lot of manual work moving exponents around after P-1 checking but I could be persuaded to. I'm not currently a member of TPR but could be convinced to join if it would make my life easier.
I've also got 7 single CPU P4s that use the older PC-133 RAM and 3 dual P3s. I'd been running regular LL tests on both processors of all the duals. For the moment I've switched to one LL and one double check for those boxen.
So, any suggestions for the best mix of tests to maximize use of my available CPU power?

If you are interested in finding a prime go with 2 LL test on each of the P4 duallies. A DC is just like an LL test in terms of the performance penalty on dualies. The optimum mix is one CPU on factoring and the other on LL test but on P4's it might just be better to go with 2 LL tests.

Re: Best mix for dual P4
 

garo said:
If you are interested in finding a prime go with 2 LL test on each of the P4 duallies.

Yeah, if I'm interested in finding a prime then the best thing to do is nothing but regular LL tests. Let's assume I know my chances of finding a prime are minimal and I'm motivated by my stats. I've got 25 machines and I'm showing over 10000 P90 CPU hrs/day. Is the PC-800 RAMBus fast enough to minimize memory contention with 2 LL tests going on?
Factoring on the P4s would be good to make best use of all their RAM?

Re: Best mix for dual P4
 

[quote="BigRed"]
Factoring on the P4s would be good to make best use of all their RAM?[/quote]

AFAIK Factoring is more RAM consuming than LL tests...

Luigi

No Trial Factoring usually works in 8MB or so.

Primenet keeps two kinds of stats LL test CPU years and Factoring CPU years. Depends which one you want to ace at. If you run two LL test in parallel your output would be about 150% of what it would be if you ran only one test. If you run 2 factoring tests in parallel your output would be 200% but in factoring. If you ran one factor and one LL test you would get 100% in factoring and 100% in LL tests. So the choice is yours.

The thing is that would you rather get 150% cpu times recorded at primenet or would you rather to have 110% recorded?

Remember factoring only accounts for 10% of the ACTUAL time used.

Also I believe when you have faster memories, bigger caches, the 150% figure will increase substantially. From my understanding, the original recommendation of running 1LL + 1Fact is based on the Pentium 1 times where memory bandwidth was very low. Now that we have PC1066 or PC3200 I suspect we can give 2LL another try.

[quote="xtreme2k"] Remember factoring only accounts for 10% of the ACTUAL time used. [/quote]
I keep seeing this 10% figured mentioned, and I would like to know from where it comes, since it is incorrect. It's more like 70%.

Yes the 10% figure is incorrect. The actual figure is closer to 100% but varies depending on whether you were lucky enough to find a factor.

The 10% figure comes from George's comment that one should spend 10% of one's CPU time factoring. That was the project ideal as he had envisaged.

It isnt incorrect.

Factoring is only WORTH 10% of the time used in P90 years. That is, if factoring a number took your computer 1 P90 year, only 0.1 P90 year will be credited. Thats where the 10% comes from.

[quote]Why is factoring CPU time not ranked with equal weight as primality (Lucas-Lehmer) test CPU time?

Primality test time is purposefully biased. Here is the rationale behind the the ranking system used on the Top Producer Awards page:

We all know GIMPS finds Mersenne primes by systematic elimination of non-prime Mersenne numbers. A LL test returns a not-prime/prime result, but factoring can only at best produce a not-prime result. One might then say finding a factor eliminates a Mersenne candidate, so its CPU time should be weighted the same as a not-prime LL test's CPU time.

Yet in practice, the amount of CPU time attributed to having found factors is a small fraction of the total factoring effort. (I think this is because by the time exponents get into the PrimeNet database, all the easy factors have been found.) It is such a small fraction I just lump it together with the trial-factoring CPU time, which does not result in a not-prime/prime result.

Even if people choose factoring or primality test work, the ranking encourages a pattern of applied CPU time that is like a air-fuel combustion mixture, about a 10:1 ratio of LL CPU time to factoring CPU time.

I needed a way to balance the zoom-ahead factoring so those machines don't run out of things to do, which is easy to do until stronger factoring programs are available. The best way to do that is not to reward the time spent on it as much as the necessary but slow LL tests.

I think most people who start out factoring zoom ahead for a while, notice they only get partway up the list, then switch many of their machines to LL tests. It seems to work out as planned, but it's too soon to know how well it will continue. At the moment, I do not plan to change the ranking system from favoring primality tests.[/quote]

Taken from http://mersenne.org/ips/faq.html

Re: Best mix for dual P4
 

[quote="BigRed"]Let's assume I know my chances of finding a prime are minimal and I'm motivated by my stats[/quote]

Well, if you are only motivated by stats, the way to maximise the production from your P4's is to do Double Checks. Double Checks will give the maximum return in P90 years.

Xyzzy, could I please have a different avatar, something from the Simpsons would be great :D

[b]BigRed[/b]
As you are motivated by the stats, but also willing to find a new Mersenne Prime, I think that definitely the best move is to choose but First-time primality tests, and keep away from the 33M exponents. This way every new test stands some chances of finding a prime, and you´ll be moving faster up the charts, which is more motivating. You have fast enough machines for LL testing, leave the TF work for slower ones.

Re: Best mix for dual P4
 

[quote="Hades_au"]Xyzzy, could I please have a different avatar, something from the Simpsons would be great :D[/quote]
Is Barney okay? :shock: :D

[quote="xtreme2k"]It isnt incorrect.

Factoring is only WORTH 10% of the time used in P90 years. That is, if factoring a number took your computer 1 P90 year, only 0.1 P90 year will be credited. Thats where the 10% comes from.[/quote]

For over three years I have been getting about 0.7 P90 year credit for every 1 P90 year spent factoring (if no factor is found). That's where my 70% figure comes from; you still haven't shown me where the 10% comes from. If you are getting that from the quoted section where it says "encourages a pattern of applied CPU time... about a 10:1 ratio of LL CPU time to factoring CPU time" then you misunderstand what that says. George was just hoping we would spend 10 times as much time on LL as on TF.

I would like George to actually clarify the weighting in terms of CPU years. My understand and RESULTs is that factoring is only worth 10% of the time taken. There is no point arguing as I cannot be 100% I am currect but from experience that seems true for me.

[quote="xtreme2k"]factoring is only worth 10% of the time taken.[/quote]

But in the time needed to complete a LL-test you can do many TF...
If you complete 7 TF in the time you would complete one LL, you should have a 70% efficiency.

Or maybe I am wrong...

Luigi :shock:

I will state my understanding again. It might not be true but this is what I understand. And I seriously hope George can enlight me with some real info.

If your computer, say it is a Pentium 90, took 1 complete year to run a LL test, submit the results and you will get 1 year credited to your account.

If the same computer, ran 20 factors and took 1 year in total. Your account will be credited 10% of that, that is 0.1 year is credited in your accounts total.

THis is MY understanding and may or may not be correct. That is why I want someone who actually knows and tell me whats going on.

Until this is cleared up, I personally DO NOT recommend anyone to run Factoring if all they want is to get points to climb up the ladder.

Test mix for Pual P3s
 

[quote="lycorn"][b]BigRed[/b]
I think that definitely the best move is to choose but First-time primality tests, and keep away from the 33M exponents. This way every new test stands some chances of finding a prime, and you´ll be moving faster up the charts, which is more motivating. You have fast enough machines for LL testing, leave the TF work for slower ones.[/quote]

I'll be moving the Dual P4s with PC-800 to pairs of 1st time tests. That is what I get with WorkPreference=0, right?
The dual P3s with PC-133 will do one factoring and one 1st time test. The slow RAM should contrain things were I to do a pair of LLs.
The single P4s will do 1st time tests.
The slower boxes (down to Pentium II (Deschutes)) will do double checking.
Sound reasonably optimal?

xtreme2k,
You understanding is incorrect. Anyway, Factoring CPU time is on a different list than LL test CPU time so climbing up those two lists are totally different matters.

You are misinterpreting George's recommended mix. Obviously, no amount of explenation from me will convince you so we will wait for George. But chew on this fact. Back in March when TPR did it's first gauntlet we worked mostly on factoring. At that time, we were able to get approx 10 Factoring CPU years per day. Now if your 10% estimate was correct, when we switched back to LL tests we should have been at 100 CPU year per day. But we were infact nowhere near that number. The stats are available on the TPR website for you to see.

But it might just be easier if George comes by.....

Yes BigRed,
That is ideal. It is optimal from the project's point of view and also from the pov of optimizing your machines.

[b]BigRed[/b]

If you are so inclined, would you post your result times of the dual P4s running 2 LL tests. Let's see if RDRAM does minimize the bandwidth bottleneck.

As I said I would love George to clarify it for us. :)

Anyway post some benchmarks about running LL/F mix and LL/LL and F/F on dual systems. I think Double checking is exactly the same as LL therefore Dual P2 might benefit from F/F or LL/F on both cpu.

Posting result times
 

[quote="outlnder"][b]BigRed[/b]

If you are so inclined, would you post your result times of the dual P4s running 2 LL tests. Let's see if RDRAM does minimize the bandwidth bottleneck.[/quote]

So, what's needed for the result times? Just the couple of timestamped lines from results.txt showing the end of the previous factoring and then the completion of the next factor? Do we care about P-1 times too?

I would like to see the times for the completed work, i.e. -times for 2 concurrent LL tests and then times for multiple TF tests during a LL test.

ex- 2 LL= 11 days 13 hrs 56 min. for 15M and 12 days 2 hrs 05 min for 15.2M

ex- 1 LL 14 TF = 10 days 12 hrs 16 min for 15M and 14 TF in 10 days 18 hrs 11 min.

Re: Best mix for dual P4
 

[quote] Xyzzy:
Is Barney okay? :shock: :D[/quote]

Barney covers it perfectly :D Thanks

[quote="xtreme2k"]If your computer, say it is a Pentium 90, took 1 complete year to run a LL test, submit the results and you will get 1 year credited to your account.

If the same computer, ran 20 factors and took 1 year in total. Your account will be credited 10% of that, that is 0.1 year is credited in your accounts total.

THis is MY understanding and may or may not be correct. That is why I want someone who actually knows and tell me whats going on.[/quote]

I do actually know and I did tell you, but for some reason you don't want to believe me.;)

Using your example: if you set the P90 to trial factoring for the second year then it WILL get credited about 0.7 years of TF by the end of that year. If you don't believe me then try it for yourself. As an example: I still have a 233Mhz Pentium Pro which used to run DCs and ran a consistent 80 P90-hrs/day. About a year ago I changed it to TF and it now runs at a steady 57 P90-hrs/day. I noticed a similar ratio on other types of machines, but not exactly the same (it's more like 60% on an athlon, IIRC). One glaring exception is my 475Mhz K6 which actually earns more hours/day factoring than it does running LL tests (LL=55 h/d; TF=87 h/d), but that's only because the FPU is so bad. As you can see, it ran LL tests slower than the P-pro but is faster than it at factoring. SSE2 optimization has probably had an effect on the ratio as well, since it speeds up LL testing so much. I've never done a comparison on those as I figured running TF on such a machine would surely be a waste of time.

Maybe the FP improvement of the Ppro was bigger then the integer?
What if you let a real p90 trail factor for a year? This should be closer to 1 then the ppro. I guess when you let a P4 factor you'll get a lot less then 0,6 * LL years

The Pentium Pro vs. the Pentium 166 made some major improvements across the board - but the single biggest improvement was a MUCH bigger cache amount.

Essentially, though Intel doesn't like to talk about it, the Pentium-II was a P-Pro core with some minor "tweeks" to work better with older code. A lot like they really need to do to the Itanic to get any reasonable acceptance for it.

One of the tweaks in the Pentium II was MMX... The Pentium Pro was the last Intel CPU to not have MMX...

That said, I'd rather have a Pentium Pro at 233MHz than a Pentium II at 233MHz... (Yeah, I'd have to overclock the Pro a bit!)

And for most usage, I'd rather have a K5 that did 233 Mhz than any Intel at that clock speed.

Would be horrible for Prime95/mprime, but for everything else it would rock....

I have a 200MHz 64-bit UltraSPARC CPU in my Ultra 1 that runs real well for it's MHz... It sucks on mlucas, but it excels in I/O operations...

Dual P4 results
 

[quote="outlnder"][b]BigRed[/b]

If you are so inclined, would you post your result times of the dual P4s running 2 LL tests. Let's see if RDRAM does minimize the bandwidth bottleneck.[/quote]

This box is a dual:
cpu family : 15
model : 2
model name : Intel(R) XEON(TM) CPU 2.20GHz
stepping : 4
cpu MHz : 2193.365
cache size : 512 KB

Mem: 1052626944

The box does get used for some non-Gimps work by the owner. It looks like all these were while the box was running LL tests on both processors.
Results.txt:
[Sat Mar 16 22:07:59 2002]
UID: cmarble, User: Chris Marble, cmarble@hmc
[Thu Mar 21 10:18:51 2002]
UID: cmarble/Jortner, M11331577 is not prime
[Tue Mar 26 19:01:26 2002]
UID: cmarble/Jortner, M11439511 is not prime
[Sun Mar 31 09:41:09 2002]
UID: cmarble/Jortner, M11956837 is not prime
[Mon Apr 8 19:39:01 2002]
UID: cmarble/Jortner, M13412753 is not prime
[Wed Apr 24 08:49:44 2002]
UID: cmarble/Jortner, M15304477 is not prime
[Sat May 4 15:15:58 2002]
UID: cmarble/Jortner, M15396919 is not prime
[Tue May 14 10:01:55 2002]
UID: cmarble/Jortner, M14525843 is not prime
[Tue May 21 06:57:45 2002]
UID: cmarble/Jortner, M14776589 is not prime
[Thu May 30 19:45:17 2002]
UID: cmarble/Jortner, M15675523 is not prime
[Tue Jun 11 20:42:49 2002]
UID: cmarble/Jortner, M15715457 is not prime
[Tue Jun 25 01:08:11 2002]
UID: cmarble/Jortner, M15783679 is not prime
[Sat Jul 6 12:46:54 2002]
UID: cmarble/Jortner, M15866687 is not prime
[Wed Jul 17 01:49:30 2002]
UID: cmarble/Jortner, M15974333 is not prime
[Fri Jul 26 23:00:24 2002]
UID: cmarble/Jortner, M16058719 is not prime
[Fri Aug 2 18:33:28 2002]
UID: cmarble/Jortner, M14169767 is not prime
[Tue Aug 13 02:14:22 2002]
UID: cmarble/Jortner, M16196387 is not prime
[Thu Aug 22 16:45:10 2002]
UID: cmarble/Jortner, M15607783 is not prime
[Sat Sep 7 02:55:40 2002]
UID: cmarble/Jortner, M16350739 is not prime

And resu0001.txt:
[Sat Mar 16 22:08:57 2002]
UID: cmarble, User: Chris Marble, cmarble@hmc
[Sat Mar 23 21:58:17 2002]
UID: cmarble/Jortner, M11721527 is not prime
[Thu Mar 28 22:02:15 2002]
UID: cmarble/Jortner, M11932229 is not prime
[Tue Apr 2 14:53:32 2002]
UID: cmarble/Jortner, M11983219 is not prime
[Sat Apr 20 11:55:20 2002]
UID: cmarble/Jortner, M15276089 is not prime
[Mon Apr 29 16:28:49 2002]
UID: cmarble/Jortner, M15352483 is not prime
[Sun May 12 06:20:45 2002]
UID: cmarble/Jortner, M15487861 is not prime
[Sun May 12 14:34:21 2002]
P-1 found a factor in stage #1, B1=195000
UID: cmarble/Jortner, M15555703 has a factor: 58689613794405579319231
[Wed May 22 10:04:51 2002]
UID: cmarble/Jortner, M15668431 is not prime
[Mon May 27 00:51:51 2002]
UID: cmarble/Jortner, M11950909 is not prime
[Sun Jun 2 15:23:23 2002]
UID: cmarble/Jortner, M13245691 is not prime
[Thu Jun 13 13:46:06 2002]
UID: cmarble/Jortner, M15021521 is not prime
[Mon Jun 24 09:51:47 2002]
UID: cmarble/Jortner, M15789497 is not prime
[Fri Jul 5 20:27:05 2002]
UID: cmarble/Jortner, M15904069 is not prime
[Tue Jul 16 16:20:39 2002]
UID: cmarble/Jortner, M15970807 is not prime
[Fri Jul 26 04:01:12 2002]
UID: cmarble/Jortner, M15390877 is not prime
[Fri Aug 2 14:00:12 2002]
UID: cmarble/Jortner, M14643457 is not prime
[Sun Aug 11 22:55:05 2002]
UID: cmarble/Jortner, M15430973 is not prime
[Thu Aug 22 00:10:50 2002]
UID: cmarble/Jortner, M16265621 is not prime
[Tue Sep 10 22:20:38 2002]
UID: cmarble/Jortner, M16345261 is not prime
[Tue Sep 24 14:02:17 2002]
UID: cmarble/Jortner, M16428437 is not prime
[Fri Oct 11 22:01:54 2002]
UID: cmarble/Jortner, M16630087 is not prime

[quote="garo"]Yes BigRed,
That is ideal. It is optimal from the project's point of view and also from the pov of optimizing your machines.[/quote]

Here's a question, for a dual P3 machine, one proc doing LL, the other doing factoring, would changing the max amount to factor to ^67 or higher make sense since the proc is dedicated to factoring? My machine completes a ^66 factor in the 21M range every couple of days.

I'm thinking of increasing it to ^67 to increase my chance of finding a factor (out of 10 TF's, I haven't found a factor).

Increasing it to 2^67 will increase your chances of finding a factor very minimally. You will have an additional 1.5% chance for twice as much processing power expended. . It is best to stick with the limits Prime95 adopts. You would be WAY better off doing more exponents to 2^66 than doing fewer till 2^67.

Assuming your starting bits are 59 your chances of finding a factor currently are about 1 in 9 or thereabouts. A bit more patience and you will be rewarded :D

[b]Paulie wrote:[/b]

I'm thinking of increasing it to ^67

That´s an interesting point. I assumed that the TF upper bound was, for a certain range of exponents, limited by the client, so for example in the 21M range we could only TF to 2^66. Regardless of being a good option or not (and I agree with [b]garo [/b]that it´s not) how *could* we change the TF upper bound?

[quote="lycorn"][b]Paulie wrote:[/b]

I'm thinking of increasing it to ^67

That´s an interesting point. I assumed that the TF upper bound was, for a certain range of exponents, limited by the client, so for example in the 21M range we could only TF to 2^66. Regardless of being a good option or not (and I agree with [b]garo [/b]that it´s not) how *could* we change the TF upper bound?[/quote]

in the UNDOC.txt file, you can set the upper range. It also states that it's not recommended to be used with PrimeNet.

The reason I was thinking about it is since there is a performance hit doing dual LL's on an older P3 dual, since it's doing only factoring on one of the processors, I'd be willing to spend say 1/3 of the time of an LL trying to find a factor to save a future LL test.

I'm thinking from a project point of view vs. stats. Are DC's more useful to GIMPS or is finding factors during TF? :)

[quote] I'd be willing to spend say 1/3 of the time of an LL trying to find a factor to save a future LL test.[/quote]

But in the same time you can test one exponent from 66 to 67 bits you can do 2 from 59 to 66 bits, so in the same time you can TF 3 instead of 1 number with something like 15 times more chance of finding a factor.

Besides using factoroverride you can not use primenet.

The limits to which prime95 trail factors are carefully chosen. Maybe not optimal anymore due to changes in speed of the client. But optimal depts to trail factor differ on each processor

Paulie,
From the project point of view don't touch a thing. The limits are carefully calculated and the amount of time you spend doing the extra bit of factoring will not translate to any savings for the project. It will REDUCE and not increase the overall project throughput.
Garo.

Cool. Thanks everyone.

I think I'm going to change the lab server borg to be TF on both processors and find another P4 to borg for the DC's. I'll find more factors doing twice the work, but still get the DCs done.

It's a plan. :) :)

Did a quick test
 

Just to see what running two LL's would do:

Compaq DL380/G2, 1GB PC133 ECC, Dual 1.25Ghz P3's

DC = M8558603 iteration times

Proc1 DC = 0.089
Proc2 TF = a 20M exponent

Proc1 DC = 0.131
Proc2 DC = 0.132