Palit DualX (1300/1500 stock) makes 270 using
-l 8x40 switch
still 235, are you using beta drivers? i'm at 337.88
8x60 seems to give the best hash rates on a 750 Ti. If you're on Windows you're also slightly limited by the default bfactor 6, you could try lowering it and the default bsleep of 100 microseconds but your interactivity will take a hit.
My rig has 6x Palit GeForce GTX 750 Ti StormX Dual, each hitting about 280 H/s at the default factory overclock using 8x60. The piece of shit Asus 750 Ti DC2OCwhatever on my win machine does like 244. Marvelous piece of engineering by Asus, take 6 GHz memory chips and fuck something up that they can't run beyond 5.4 GHz.
8x60 is better yes i'm getting 240 now or slightly more, for bfactor and bsleep how much i can lower them?
is nvidia like amd with hynix and elpidia? could explain why some card are better than others
p.s. tried 6 and 66 only 5h more 245h per card
You can probably get away with bfactor 1, maybe even 0. If you're not concerned about interactivity I'm pretty sure you can run bsleep 0. The way it works is described in the help text (and maybe readme, can't remember) but here's the quick recap:
The bfactor option controls how much of the biggest main loop is done in a single kernel launch. That particular kernel gets split into 2^bfactor pieces. At bfactor 0 (default on Linux because you don't need to worry about your OS being a dick and resetting the display driver because your CUDA kernel is taking too long to run) you get 2^0 = 1 meaning doing the whole thing in a single launch. At 1 you get 2^1 = 2 parts and at the Windows default 6 it gets split into 2^6 = 64 parts. 6 seems to be a reasonable balance between interactivity and performance. Of course if you're running more than one card you only need to worry about interactivity on your primary display GPU. So you could run --bfactor 6,1 which would make the primary GPU run the 64 part split and be fairly interactive while the rest of your cards would run a 2 part split and spend a little more time working instead of sleeping.
After typing that I just realized how insignificant the effect of the interactivity hack is after all
It's 0.0064 seconds added to the roughly 1.5 second run time of the second loop, not really a big deal. Well, there's probably some overhead for each kernel launch but it's still not much.
And then we have --bsleep, the amount of time to wait before launching the kernel for the next part of the split. Windows defaults of bfactor 6 and bsleep 100 leaves you with 64 parts with 100 microseconds doing nothing after each part, for a total of 0.0064 seconds spent sleeping instead of working. Well, there's probably some overhead involved with each kernel launch too. Might be just the fact that Windows is doing stuff on the GPU that's slowing it down.
What a useless post.
PS. The temperature in my apartment just hit 35C, fuck my balls and fuck trying to think straight in this shit