Maybe that's the issue with my units then. They are picky enough to want to work faster when they can, but are limited. I'll recompile and check the results.
-Fuse
The higher the pool difficulty, the longer it will take.
By default, it's 3845 steps (~ 1 hour of hashing time). But with diff 512, it's 512*10 = 5120 steps.
I've set up a separate port on the pool specifically for gridseeds. It maxes at 256. Would it be 2560 then?
Is it possible to tune faster, or would that cause more problems? I'm not saying could you do that, but rather can it be done. It would be interesting to see what a faster turning time would do.
-Fuse
Sorry, I forgot to mention that the lower bound is 3845. But those values can be adjusted in the source code (gc3355.h).
Look for:
#define GC3355_OVERCLOCK_ADJUST_MIN 10
#define GC3355_OVERCLOCK_ADJUST_STEPS 3845
Hey! I see lots of progress here since I reverted back to 2.3.2
I do miss the stats at the top though ;(
I think I'll try it out now since most of the issues seem to be handled now.
I know what a hassle updating can be. I just don't have the time or patience to be part of constant debugging. I need stable clean performance w/no issues. Seems it may be there now.
Is the win binary up to date and ready to go now?
Thanks for all your hard work and dedication Sandor111!
Peace
Wolfey2014
Wolfey I would definitely give this latest version a shot seems very stable now and performance is much better than cgminer/bfgminer from all of my testing