Even through Afterburner?
This only started in the last two days, and I'd been starting and stopping it for the past couple of weeks just fine.

[QUOTE=Dubslow;271918]Even through Afterburner?[/QUOTE]
Yes, because Afterburner sets the clocks for performance level 3, which the card won't reach once the "lock" (driver downclock problem) occurs.
[QUOTE=Dubslow;271918] This only started in the last two days, and I'd been starting and stopping it for the past couple of weeks just fine.[/QUOTE]
Did you upgrade your GPU drivers or did you start to overclock your card? Overclocking the CUDA cores by a few MHz already triggered the problem here. Running the card at stock clocks (or using old pre CUDA 4.0 driver versions) helped.

Hit an anomaly last night, where, for one class, GPU performance on my GTX440 suddenly doubled for no apparent reason except that I had just returned to my machine and woke it up and turned on the video in the usual way, by moving the mouse. This is under Xubuntu 10.10.

Can you point to the reports on the downclock bug for me?

[QUOTE=Christenson;271954]Hit an anomaly last night, where, for one class, GPU performance on my GTX440 suddenly doubled for no apparent reason except that I had just returned to my machine and woke it up and turned on the video in the usual way, by moving the mouse. This is under Xubuntu 10.10.

Can you point to the reports on the downclock bug for me?[/QUOTE]
I've PMed you a few links...

No, I'd been using Afterburner for about a week already. On the other hand, since my previous post, I did upgrade the drivers (standard ones, not CUDA) and got roughly a 5-10% performance boost. When mfaktc runs free on the CPU, I got 205M/s. With mfaktc on two (hyperthreaded) cores and 3 Prime95 workers running, I stilll get about 175M/s. (And I haven't noticed it do the cut-in-half thing since the driver update, though I hesitate to say that fixed it.

Fixing Mxxx has a factor reporting to primenet
 

I'd like to fix this so:
Does anyone know what format should mfaktc's "Mxxx has a factor" line should have so prime net does not misattribute it to different kind of task?

[QUOTE=apsen;272538]Does anyone know what format should mfaktc's "Mxxx has a factor" line should have so prime net does not misattribute it to different kind of task?[/QUOTE]I believe for manual result submissions, the attribution is (still) based on the size of the factor as to whether it's most likely found via TF/P-1/ECM. The fact that it has "[mfaktc <version>]" at the end of the (next) line should already be plenty to identify this as a TF factor (since mfakt* doesn't do anything else), but the manual results parser isn't quite as robust as it could be.

However, using the PrimeNet API for automated results submission, there is certainly provision for properly reporting factors according to their method of discovery: each result type (TF-F, TF-NF, P1-F, P1-NF, etc) all have their [url=http://v5.mersenne.org/v5design/v5webAPI_0.97.html#8.0]own unique result type id[/url].

I think if any manual results lines contain mfaktc then the result is attributed to TF

[QUOTE=Prime95;272545]I think if any manual results lines contain mfaktc then the result is attributed to TF[/QUOTE]

OK. I'll try to put mfaktc on the factor line and see what happens, but I think I've already tried that...

Do you have an example of a TF result that is being misattributed, that we can try and see why it might be happening?

[QUOTE=James Heinrich;272648]Do you have an example of a TF result that is being misattributed, that we can try and see why it might be happening?[/QUOTE]

I think I have only one factor that I reported via regular manual submission - and it was attributed to P-1, I think.

BTW "has a factor" line of the output does not really have "mfaktc" in it. Only subsequent one does. But I think I tried to put mfaktc manually in it and it did not help.

After that I would just have prime95 rerun bit levels with factors.

Those factors are:

[CODE]Manual testing 54259081 F-PM1 2011-07-30 12:36 5.6 1464964004267408316167 2.4586
Manual testing 55117351 F-PM1 2011-07-20 11:08 2.8 669422135975942696959 2.4586
[/CODE]

I do not really want to try submitting new factors this way as I do not like them being misattributed. Also it would have been nice if the above ones could be fixed too.