I ran some initial tests on GTX 660Ti this morning. It looks like my newly optimized CUDA kernels up the khash from 112 to about 135 khash tops.

Don't know why JSON API calls would be failing, other than the pool being under DDOS attack or heavy load.

Maybe I should still allow the single memory allocation as a fallback, in case chunked allocation gets too slow?

Christian

I'm getting this same issue on my GTX670 machine.  Looking forward to testing this once I can get it to work - looking good so far though

I might add linux build support back in at some point. BUT. So far no one has donated anything to my donation address, and hence it feels utterly bizarre when you wave a 100 LTC bill around like that. In all of the last 2 weeks I have only mined 13 LTC.

I just added a little Microsoft' ism into the code (scrypt.cpp): I use a parallel for construct around the HMAC SHA256 hashes. This takes the load off a single CPU core and allows the mining to go above ~120 kHash/s without choking the CPU.  For Linux compilation I would have to use either OpenMP or turn this feature off via #ifdef.  But Microsoft Visual Studio is not supporting OpenMP in the Express versions...

  Update!  

I've just added some special code for Geforce Titan. It is compiled against device capability 3.5 and makes use of the new funnel shifter, it keeps the register count tidy (64) and it consumes very little shared memory. And as extra effort, it is automatically enabled when you have a Titan. I am really curious what khash this will produce.

Now I need to get my command line overrides for device selection and launch configuration done. An update within the next 6 hours is likely!

Christian

Autotune on a 660ti autodetected S1x4 which reported 136-138kH/s, but all shares were rejected.

No autotune using 290x2 on the same card comes in a little slower, 115-132kH/s, but very low reject rate and faster than the previous version.

1 LTC sent to LKS1WDKGED647msBQfLBHV3Ls8sveGncnm

Looking forward to testing Linux support.

Same here for the first part (S1x4=100% reject)
Tried using 290x2, my device driver(314.14) crashed and i had 40-50% rejects..

So, i'm back with 2013-04-04..

can you try the 04-08 version with --no-autotune ? I might have broken autotune a bit, as indicated by people having issues with the "S" kernel being used in a 1x4 configuration, even though that kernel can't work at 4 warps

So because the kernel isn't run, it throws off the timing measurements resulting in inflated kHash values, and then autotune picks that broken configuration.  Meh.

Where are the Titan owners? Hello, we have support for Titan and I really need someone to test this. If you could post the result of a Titan autotune session with debug flags to the forum - that would be immensely helpful.

cudaminer.exe -D >log.txt

This would generate two large tables in the log file. One table for the normal kernel, the other one for the spinlock kernel. (hopefully cudaminer prints to stdout, and not stderr - and you would have to wait through the time it takes to complete autotune. Can take quite long if your card has a lot of RAM: 6GB for Titan - of which at most 4GB are addressable from a 32 bit binary).

Christian

The 04-08 build works on the 690 if I tell it only one thread, so we're getting close!

If it'd be easier than getting it working properly in an SLI rig, could there be a command line to set GPU affinity? That way I could just kick off two copies of cudaminer for their respective GPU.

Otherwise, so far so good! --no-autotune gives me ~110khash/sec on GPU0 in a 690.

Looks like you need to switch to a pool that uses the getwork protocol, not Stratum. For stratum you need to set up a local proxy server. Can't help you with that, as I haven't tried this myself.