CCminer(SP-MOD) Modded GPU kernels.

[Vita1ico]

There is no difference .63 and .62. Equally the rate of 10.7 Mh \ s Quark 6.1 Mh\s and Lira2. Who stopped .62 color picture is more like (green "yes").

[1714704125]

1714704125

[1714704125]

1714704125

[tbearhere]

 sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx    

[scryptr]

RELEASE dot 63--

I reverted to release dot 62.  There is a typo (likely) that breaks the color display, and dot 63 is actually slightly slower for me.

--scryptr

[mendoza1468]

-i 22.9 is not the best setting for gtx 970. -i 22.9 is good on 2gb cards like 750ti and 960 (and the 1gb 750) uses around 800 MEG of gpu memory.

-i 24 is the default for quark on 970/980

I have retry and im getting :
-i 24 = 33 125 kh/s
-i 22.9 = 33 350 kh/s even 33 442 kh/s atm

so getting better hashrate with this. Idk why but it works

[pallas]

I'm strangely getting a lot of per-thread hashrate reporting on the latest git.
it also doesn't seem to be disabled when I add the -q switch...

[sp_]

Yes, I merged some code from Trent Nelson at it seems to fuckup the colors and output.

[sp_]

 sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx    

I didn't remove it, not sure why it isn't working..

[densuj]

I love vga miner. 

[restless]

on last .63 build my 750Ti has broken colors (have to run with --no-color) and I see no speedup compared to .61
All stock, only the CPu is relatively old&slow (E5200), but this was no issue so far

Wich algos are you mining?

You should get faster rate in quark and lyra2v2

Sorry I omitted algo - I tested with quark only - mining vs nicehash
I'd say ~ 50kh/s less speed as indicated by ccminer

[myagui]

-i 22.9 is not the best setting for gtx 970. -i 22.9 is good on 2gb cards like 750ti and 960 (and the 1gb 750) uses around 800 MEG of gpu memory.

-i 24 is the default for quark on 970/980

I have retry and im getting :
-i 24 = 33 125 kh/s
-i 22.9 = 33 350 kh/s even 33 442 kh/s atm

so getting better hashrate with this. Idk why but it works

Have you checked if you are getting the GPU clocks throttled due to high temperatures?
Higher intensity usually demands more of the GPUs, and if thermally constrained, performance can indeed get worse by raising intensity. Personally, I recommend high & fixed fan settings, to ensure lower temperatures and finding the clock sweet spot before throttling kicks in.

[myagui]

I'm familiar enough with the constraints of pool and mining software to know why many of the presented approaches to developer funding/rewarding do not work. Will not post at length about this now as it would take more time than I'm willing to afford right now, but I'd like to pitch in something.

I do have one suggestion, admittedly of moderate return potential, but importantly, it should not be too costly to implement and would be worth trying out:
- Many people do not know or care to compile, and so will run whatever binaries are made available.
- Many of those that do know how to compile/code, would still uphold fee system, if the set fee is small enough and reasonable.
- Nicehash is by far the most popular service for set-and-forget mining with BTC payout.

So, how about coding a fee system, that only kicks in when mining at Nicehash/Westhash, and mines 1% or 2% of the time to a hardcoded BTC developer fund address?
The destination fund address could be:
- global and individual - if say, sp_ would hardcode his own address in his fork for example, regardless of the algorithm selected, or
- global and shared - if say, the miner would have a hardcoded address that is under the control of multiple developers, or some trusted fund manager, or some multi-sig scheme combination, again, regardless of the algorithm selected, or
- algo-based and individual - if say, for lyra6rev15, the miner would have a fee address for djm34 (responsible for most boosts of that algo), while if quark was selected instead, the fee address would be set for sp_ (responsible for most boosts of that algo).

I'd estimate that the potential returns from such a system are not really massive, but they could certainly add up to make something very much worthwhile for everyone. On the other hand, it should be simple enough to code and maintain, as it is a basic tie to Nicehash and uses plain BTC addresses for the funds routing/assignments.

This approach is still just based on good faith, and keeping the economical incentive mostly unchanged, so that it might be attractive for a good number of users. It also leaves room for private deals and private pools and what not, for any exceptional mining opportunities (new algorithms, solo mining, etc, etc).

I'll also drop a big thank you to tpruvot, which has consistently improved ccminer with new features and better usability. As he focus less on the specifics of squeezing every bit of performance from algo X or Y, he's not mentioned here as much, yet he is one of the most active coders that we have in this space.
I appreciate all developers and everyone's contributions. For a rather long time now, my single rig has been firmly pointed at a mining destination that adequately rewards 2 of the developers here for their work (you know who you are, and thank you both!)

Happy Mining!

[antonio8]

 sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx    

I didn't remove it, not sure why it isn't working..

He's probably talking about wallet mining with GBT - coins are moving to newer BTC codebases, which have getwork removed.

What is weird though is other miners are working to solo mine in the wallet but current releases are not. Maybe from .60 to present.

[joblo]

Yes, I merged some code from Trent Nelson at it seems to fuckup the colors and output.

Only on Windows, Linux is ok.

[pallas]

Yes, I merged some code from Trent Nelson at it seems to fuckup the colors and output.

Only on Windows, Linux is ok.

I'm on linux and it's not ok.
I see a new log.c, thread id is back but the issue is still present.

[scryptr]

Yes, I merged some code from Trent Nelson at it seems to fuckup the colors and output.

Only on Windows, Linux is ok.

I'm on linux and it's not ok.
I see a new log.c, thread id is back but the issue is still present.

dot 62 and dot 63:

Release dot 62 works fine!  I get, mining Lyra2v2, 6Mh/s on my GTX 960 (Win 7), 4.5+ Mh/s on my 750ti cards (Ubuntu), and 9.2Mh/s on my GTX 970 cards (Ubuntu).  The colors are clean, the TID info is gone, and Linux builds show nice clean temp and fan speeds.  I only tried the release build dot 63 on Windows.  It had the color problems and slightly slower speeds, so I put release dot 62 back in the launch folder.

Your hashing code may actually be faster, but if you re-merged the code in dot 63, something went awry.

--scryptr

[wicks]

What would you recommend to mine with Quadro 4000 GPU?

[sp_]

Yes, I merged some code from Trent Nelson at it seems to fuckup the colors and output.

Only on Windows, Linux is ok.

Yes, but I have removed it again from the main branch.

[sp_]

Your hashing code may actually be faster, but if you re-merged the code in dot 63, something went awry.

Just a small change in keccak wich is faster. But it was compiled with another version of the cuda toolkit.
I will give cuda 7.5 another change and try to fix the bugs..

[sp_]

What would you recommend to mine with Quadro 4000 GPU?

This is compute 2.0 device wich is not supported in any miners.

[ldp5500]

Which brothers to help me set up 750TI quarks and lyra2v2 the .bat? Thank you.