What SIEVE_PRIMES are you using?

[LaurV]

Originally Posted by James Heinrich

2000 requested quiet often

Hm... I "quiet" "quite" need this... When can we have it? Can it include George's barrett77 code? Will the "low expos" version be merged with it or still be a separate trust-based distribution?
Thanks!

[NormanRKN]

2000 ? oh, very low.
by the way, is it possible to use more then 1 cpu for 1 instance ? p.e. core 0+1 or core 2+3 or all cores ?

[Dubslow]

Originally Posted by NormanRKN

by the way, is it possible to use more then 1 cpu for 1 instance ? p.e. core 0+1 or core 2+3 or all cores ?

No. The sieving code is not multithreaded. (You can set the affinity for the process to multiple cores, but it won't actually go any faster.)

[LaurV]

Originally Posted by Dubslow

The sieving code is not multithreaded

Correct. Why should it be? Our problem (the guys wanting a lower SievePrimes) is that the CPU is heavily suffocated. If you have a system where the balance is in favor of the CPU (i.e. more CPU power, less GPU power), then you have plenty of possibilities to make it running as you want. You either can use more instances, set affinities of more instances on the same core, whatever, in such a way to max the GPU's and if some CPU resources are free, you still can play P-1, aliquots, whatever, to max both. But in a system where more GPU power is available, few instances of mfaktc will immediately deplete the CPU power. In my system where I have two gtx580 (factory overclocked), there is no way to max both of them without overclocking my i7-2600k CPU to over 4.4Gigs, and in that case the computer can't be used for anything else. To avoid that, and still have both GPU/CPU maxed, I have to use some CudaLucas too...

It would be more convenient for me to "mfaktc with the GPU only" i.e. have the possibility to set the SievePrimes lower, to let the GPU do more exponentiation, and free the CPU by sieving less, close to nothing, if possible. In this case I can use the CPU for other things.

[kladner]

Yesterday, I realized that I had not updated my system BIOS in some time. I went to the Asus site and got the latest and flashed it.

When I got all the BIOS settings back to their usual values and booted Windows and mfaktc, I noticed that SP was behaving a little differently. I've now switched the BIOS back and forth a couple of times and came up with the attached. The older BIOS is above the red line, the newer below. The summary is that the older runs at SP 28125 while the newer stayed at 25000.

Can someone help me interpret this in terms of which BIOS is more advantageous if this difference is significant in the first place?

EDIT: Sorry for the poor legibility of the attachment. I had to downsize it and use heavy JPEG to meet the upload limit.

EDIT2: These are the same three exponents in both sets. Also, I hope it is not too OT to post this here.

[bcp19]

Originally Posted by kladner

Yesterday, I realized that I had not updated my system BIOS in some time. I went to the Asus site and got the latest and flashed it.

When I got all the BIOS settings back to their usual values and booted Windows and mfaktc, I noticed that SP was behaving a little differently. I've now switched the BIOS back and forth a couple of times and came up with the attached. The older BIOS is above the red line, the newer below. The summary is that the older runs at SP 28125 while the newer stayed at 25000.

Can someone help me interpret this in terms of which BIOS is more advantageous if this difference is significant in the first place?

EDIT: Sorry for the poor legibility of the attachment. I had to downsize it and use heavy JPEG to meet the upload limit.

EDIT2: These are the same three exponents in both sets. Also, I hope it is not too OT to post this here.

In technical terms, the older bios should be more productive since the CPU is Sieving deeper. About all you could do is time some full runs to see if there is much difference (which may fall within the normal variance between runs)

[kladner]

Thanks Pete,

There's more going on than I realized. I'm still gathering information to describe it. I'll start a new thread when I have it together.

EDIT: Suffice it to say that the BIOS may not have had a causal relationship with the speed change.

[LaurV]

Originally Posted by kladner

say that the BIOS may not have had a causal relationship with the speed change.

That was what I wanted to say, but wasn't sure how to put it, I have asus maximus mobos with multiple bios, you use a switch on the case and select which bios you want to launch (very good for guys who overclock or make a lot of hardware experiments as I do). What I want to say, in spite of the fact their setting are totally different, there is no difference in mfaktc running under different bios'es, beside of the difference given by overclocking - faster CPU sieves faster.

On the other hand, SievePrimes stabilizing higher (or lower) have nothing to do with the general speed, I mean, one ca not say which one is better/faster just looking at those screens. Say I raise the CPU clock in bios, overclock few %, then the sieveprime can get higher (or not) and the speed of TF will increase. Now assume I go to the bios and do strange settings for PCIe slots, insert some wait states, reduce apertures, whatever, make the GPU or the communication slower, the effect would be the same: the CPU will have time to sieve more, but the "global" effect will be diminishing mfaktc output.

The only way to say which one is better, as bcp suggested already, is to take the stopwatch and count... There are more thinks involved, sometime you can get few percents more output, but the system will generate a lot more heat and waste a lot more energy, raising the electricity bill. You can overclock and have an apparently FASTER output rate, like 20%, 30%, whoaaaa, but if the system become unstable and you have to repeat one test in 5 (cudalucas) or miss factors (mfaktc) then you will get the same output at the end, only will have to pay more money for electricity, and you don't help the project. You should play around a while, then select the run mode which is most STABLE. If the speed come with it, well, that is bonus. What I want to say, after thousands of experiments and burned fingers, I reached the conclusion that the fastest way is not always the best.

[kladner]

Originally Posted by LaurV

That was what I wanted to say, but wasn't sure how to put it,.....

I lost track of how many tweaks I had in place at various times. When I did the initial BIOS change I also cut back all OC's, etc. I'm not sure if there was still some blip, but now I am reproducing the results I had earlier.....with NumStreams=5 and mfaktc priority=Normal or higher.

In the meantime, I ran through various BIOS and nVidia driver versions. Currently, I have a rather old BIOS (though not the oldest [on the MB CD]), and GF drivers 285.62. The other variable I overlooked was setting NumStreams=5 instead of 3, combined with Normal or High Priority. This gives great results on a Windows machine as long as you don't need to use it for much else.