Workaround: run two separate instances, one with -d 0, the other with -d 1.

the communication was so far limited to a kernel submission from nVidia.

It's a high register count (1 hash per thread) Compute 3.5 kernel that gives some marginal improvement over Dave Andersen's work. Unfortunately it's not well suited for implementing a LOOKUP_GAP.

Christian

I have updated the wallet, so it was just bad luck I suppose...
I am indeed on a pool now.

This might sound like a conpiracy, but both the old and the new YAC wallet to me works perfectly, except seemingly randomly after a couple of hours of solomining it shuts off the miner with (Internal Error: 500) and it can't reconnect. Degub.log has nothing. Sometimes it does it after an hour, sometimes it does it a day later, while I'm not even using the PC. I'm not saying it does that when I'm about to find a block, buuuut since I solomined more time than I care to admit with 2-4 kH/s and got nothing, it kind of popped up in my head.


As far as I noticed, scrypt gets no benefit from 64bit, only scrypt-jane does.
In fact, to me the x86 version of the 2013-12-18 release was slighty faster then the x64. Haven't really mined scrypt since then though.

PS:

Hmm, I'm getting like 19 coins a day with 100 kH/s (<0% rejected) on vert.bitcrush.info pool.

Woot, I can finally post here!


I have!


This was me.


Possibly, I was using Patoberli's x86 build of commit 92 for both the T16x1 and K21x1 runs.


This is true but on the x86 build of commit 92, T16x1 netted about 3.68 while K21x1 was 3.93 (few spikes to 3.97) all with a 325+ Core offset... I have not been able to try an x64 build yet or any with the new Lookup Gap implementation (no time to build one myself sadly) so I am not aware of how this may change in later commits.

I can say without a doubt that the K kernel was much more stable then the T kernel was. I could go as high as T19x1 (more and driver would hard crash) but the has rate dropped off significantly after T16x1(T8x2 was virtually the same). The K kernel simply allowed me to reach K21x1 with little to no issue and a significant improvement to hash rate.

Given some time later this week I plan to build a more recent commit as well as an x64 for further testing.

For those interested in Scrypt-Jane OCing, Memory bandwidth is very much not a factor, I was able to do a -502 (maximum possible) memory offset and have literally no change in hash rate. The Memory controller was maybe 17% utilized so there is zero bottle neck here. It is safe to drop this to improve total TDP on your cards. Core Offset can be set vastly higher then a normal overclock, Where i was able to get +155 when running Scrypt I can now easily and safely reach +325 to +350 without much issue. This is with stock Bios and Default Drivers while Air Cooled, do not be afraid to push core clock higher when running Scrypt-Jane

Difficulty went up at lot since my post  :-/ I'm down to 200 coins a day with 1000 kH now. However, the exchange rate went up quite a bit too - 0.0004 BTC on CoinedUp, so profitability is about the same.


That is very cool. Can't wait to see the results.

sorry to ask again and be a pain in the ass but can some give some advise on what to do about trying to get more kh/s out of my gpus on my 2 laptops please.

Hi
First of all, what do you try to mine? Litecoins, any other Scrypt based coin or maybe yacoin?
The hashrate is different for any kind of coin.
Autoscan tries to find the best values for you. Once it has found them (like F56x2) you can start cudaminer with -l F56x2 to skip the autotune every time.
But we need to know which coin you try for more possible tuning.

Two new experimental kernels added to github - currently for Linux only. The Visual C++
project has not yet been updated. You will want to run ./autogen.sh and configure after
doing a git pull.

"Z" code submission by nVidia for Compute 3.5 devices (GTX 780 etc...). Good for scrypt.
"Y" code submission by nVidia, modified to run on Compute 3.0 devices also. Good for scrypt.

I find that scrypt-jane still runs faster with the "X" (Fermi) and "K/T" (Kepler/Titan) kernels
from the current github code.

Test away... Especially the Z kernel is expected to rule. I haven't tested it yet in detail.
Best config for "Z" is No. of SMX x 24, according to the engineer who wrote it.
Best config for "Y" is (guessing) No. of SMX x 32   - or just autotune.

The Z kernel is best run with -C 0 (it supports C 1 and C2, but that is mostly pointless).

When you make kHash/s benchmarks compare with the best scrypt values achieved with the
2013-12-18 release.

I got 86 kHash/s on GTX 750M with the -C2 flag and -l Y4x32 in some quick tests, which
might be slightly faster than what the 2013-12-18 release delivered.

Christian