It is not necessary for [U]this[/U] project (i.e. GIMPS) to finish the bitlevel, once a factor is found. The goal of gimps is to find primes, and once a mersenne number is proved composite, by finding at least on of its factors, the corespondent exponent present no interest anymore for the project. So, it is safely to stop after the class. However, some people argue that is polite to finish the bitlevel, the reason being that some other projects/people may have other reasons beside finding primes, like finding factors, whatever. Finding factors is cool. :D

If a factor is found, the information about how that factor was found, what program was used, how many classes, etc, is lost (not stored in the database). So, because different programs split the bitlevel differently, an eventual "factors hunter" will not know which candidates were checked and which not, on the bitlevel where the factor was found, so he will have to redo all the bitlevel completely, duplicating the efforts of initial searcher. So, some argue that doing the bitlevel is "polite" at least, but here the opinions vary, most people stop after each class, because anyhow, if another guy will start factoring after years, he will not know which bitlevels were done and which not, he will anyhow start from scratch, and at the speed his computer will have, he will need only fractions of the time we use here, to factor everything from scratch. Who the heck knows where the computer speed will be after few years...

[QUOTE=LaurV;371503]It is not necessary for [U]this[/U] project (i.e. GIMPS) to finish the bitlevel, once a factor is found. The goal of gimps is to find primes, and once a mersenne number is proved composite, by finding at least on of its factors, the corespondent exponent present no interest anymore for the project. So, it is safely to stop after the class. However, some people argue that is polite to finish the bitlevel, the reason being that some other projects/people may have other reasons beside finding primes, like finding factors, whatever. Finding factors is cool. :D

If a factor is found, the information about how that factor was found, what program was used, how many classes, etc, is lost (not stored in the database). So, because different programs split the bitlevel differently, an eventual "factors hunter" will not know which candidates were checked and which not, on the bitlevel where the factor was found, so he will have to redo all the bitlevel completely, duplicating the efforts of initial searcher. So, some argue that doing the bitlevel is "polite" at least, but here the opinions vary, most people stop after each class, because anyhow, if another guy will start factoring after years, he will not know which bitlevels were done and which not, he will anyhow start from scratch, and at the speed his computer will have, he will need only fractions of the time we use here, to factor everything from scratch. Who the heck knows where the computer speed will be after few years...[/QUOTE]

Thank you. For the record, I understand the information is not only lost but primenet does not even grant credit for finishing the bit level even though my result file specifically indicates it. Putting two and two together leaves little incentive to actually terminate the assigned work.

@LaurV, isn't the bit depth for TF remembered on GIMPS? If you look at exponent status and select show full details, it says whether or not it's prime, whether or not a factor has been found, the known factors, LL residues if any, TF factoring bit depth, and P-1/ECM bounds.

EDIT: Nevermind, it does discard that information on mersenne.org once a factor is found. It keeps it until a factor is found, even if it's composite by LL test. However mersenne.ca keeps the information at least.

[QUOTE=Flow;371535]Thank you. For the record, I understand the information is not only lost but primenet does not even grant credit for finishing the bit level even though my result file specifically indicates it. Putting two and two together leaves little incentive to actually terminate the assigned work.[/QUOTE]
I am now stopping at class level, when a factor is found, rather than bit level ...

[QUOTE=Flow;371535]...leaves little incentive to actually terminate the assigned work.[/QUOTE]My interpretation of GIMPS TF assignments are that they are [color=darkgreen]see if there are any factors between 2[sup]x[/sup] and 2[sup]y[/sup][/color], so you can legitimately complete the assignment by [i]either[/i] finding a factor, or verifying there are no factors in that range. Stopping after finding the factor doesn't make the assignment any less complete.

I finally got ahold of my SLI bridge from storage, so I enabled SLI mode on my now two GTX 670s. Since I wasn't quite with it and plugged the SLI bridge in backwards, I couldn't get SLI detected at first, so I tried reinstalling the current NVIDIA driver (335.23), then figured out what I did wrong and SLI went on just fine.

However, I broke mfaktc. While it has been running fine on 335.23 since that came out (early March), mfaktc won't start now:[code]CUDA version info
binary compiled for CUDA 4.20
CUDA runtime version 0.0
CUDA driver version 0.77
ERROR: current CUDA driver version is lower than the CUDA toolkit version used during compile!
Please update your graphics driver.[/code]How did I delete my CUDA runtime version, and how do I get it back? :unsure:

Do you have an integrated card also?

[QUOTE=flashjh;372510]Do you have an integrated card also?[/QUOTE]Nope, i7-3930K has no built-in GPU.

Well, SLI can change the video card numbers. Try using
-d00 and -d01 to start mfaktc.

I may be confused, but I thought that there was no benefit from SLI for mfaktc. Don't x90 dual cards still run just one instance on each GPU?

The driver issue gives me pause, though. I'm running 332.21 without problems. Perhaps "not broken, don't fix" is a good philosophy for now, especially since I don't game, and these are 500 series cards.

Yes, that's right but it would benefit other things when not using mfaktc.

I use the newest drivers and don't have any problems with 580s.