Another bug? The ETA is meaningless (to me). I have 29 million iterations left at 2.47 ms/iter. It says the ETA is in 42 hours. Is this because I did the first 8% of the test on a GTX 460?

It also appears that my iteration times go from 2.44ms to 2.85ms when the display shuts off. Does anyone have advice on how to keep the GPU going full throttle (Windows 7)?

[QUOTE=Prime95;379011]Another bug? The ETA is meaningless (to me). I have 29 million iterations left at 2.47 ms/iter. It says the ETA is in 42 hours. Is this because I did the first 8% of the test on a GTX 460?

It also appears that my iteration times go from 2.44ms to 2.85ms when the display shuts off. Does anyone have advice on how to keep the GPU going full throttle (Windows 7)?[/QUOTE]

You could have a look at the Power settings.
Control Panel\All Control Panel Items\Power Options

It defaults to "Balanced" but this may include things which happen when the display goes to sleep. Go into 'Change Plan Settings' and pick your way through all the layers. I am not sure of system specifics on Intel, but that's where to look.

[QUOTE=Prime95;379010]Possible bug. I got a used GTX 580. Installed it and it was running a 1792K FFT double-check using 256 / 128 threads. Then I saw your cool new feature and ran:

./CUDALucas -threadbench 1536 2048 5 10

This created a file suggesting 1792K run with 64 / 64 threads. This combination turns out to be 10% slower than the 256 / 128 combination I was using. Needless to say, I deleted the threadbench output and resumed work.[/QUOTE]

Try

./CUDALucas -threadbench 1792 1792 50 2

This will test only fft 1792k and show the timings for each thread combination. If the card is running a display, the 50 iterations will help smooth things out from the display's interuptions. The results of the threadbench do vary from run to run but I haven't seen them come up that far off before.

In interactive mode, entering the character "n" will reset the timer so that the eta is meaningful for the new card.

Thanks. The card is running a display and things have settled down now. Windows must have been doing some strange bookkeeping due to the new card and new driver. CUDALucas ran overnight at full speed and this morning threadbench produced more meaningful results.

I don't see why it is required to download a [B][U][I]1.1GB[/I][/U][/B] installation file (CUDA v6 toolkit) just to create the CUDALucas v2.05 non-beta? This seems very discouraging to non-developpers. As if the extra download & file size wasn't discourraging enough I also need to compile this software using a program I've never heard of. I would understand needing to do this as a performance tweak maximizer, but I think the programmers and developpers should provide a compiled stable compatible (even if it's not the most efficient assembly possible), that gets all users up and running ASAP. Not so savy users and users that can't spare the time to download extra files and compile everything, only care about the quickest/simplest way to participate.

I've finally fully migrated to v2.05Beta but each time I try to complete one more step at getting a v2.05 non-beta ready & running, it seems each step will take me a few days to find time to complete it.

ok having read this page ([url]http://gnuwin32.sourceforge.net/packages/make.htm[/url]) from the v2.05 readme file, I am completely lost, I don't know what I'm supposed to be doing to create the non-beta program. Can someone provide some direction. I just see lots of references to things I may need, or steps that might need to be taken but nothing that clearly states exactly what I should do and which files or packages I specifically need. I'm not a developper and never programmed anything this complex before.

I've discovered another bug in v2.05Beta r68. When the display driver stops responding and resets/recovers, CL restarts testing from the last report iteration not from the last checkpoint iteration. This was causing me to lose far too many hours of processing because I had set my screen report iteration to 10x the checkpoint iteration number. The checkpoints absolutely work when you close CL and relaunch but the CL code is not using the checkpoint when the driver stops responding and recovers. I've already lost 24hrs worth of processing across a few exponent tests with this bug.

Thanks for pointing this out. I had assumed that checkpoints would be less frequent than screen reports, so this was intended to save time in case the cufft hang bug manifested. I'll set that to go with whichever is more frequent.

I have seen an unexpected format of CUDALucas results submitted to the new manual_results form:[quote][color=red]M66612345[/color], 0xf14280335dcba098, offset = 32109876, n = 3584K, CUDALucas v2.05 Beta, AID: B858C7F634B865CB75587ADCFFFFFFFF[/quote]Generally looks "normal", except the first part of the line shows "[b]M66612345[/b]" instead of the expected "[b]M( 66612345 )C[/b]"
Is this an accepted variant output of any version of CUDALucas, or was this just something the user edited before submitting?

No, it is not, all versions of cudaLucas I know will show parenthesis. Someone played with the results (?!)
If you didn't mask the exponent, it ends in 5 :razz:

That's what I figured. And yes, I masked the exponent, residue, offset and AID :smile: