CCminer(SP-MOD) Modded GPU kernels.

[sp_]

what is the proper launch configuration. ?

Boost the coreclock to 1600MHZ, reduce the memory clock (500mhz). And run without any parameters.

[Velgelm]

SP_Decred8Vcash6 - without -I and --cpu-priority parameters :


Alexis78 lastest git - without -I and --cpu-priority parameters :


I understand that by default your miner faster. But if you set the settings manually the same for both miners your miner is slightly faster, and then slower than free

[sp_]

Now you should set the clock to 1600MHZ +100 more. (for a 6% boost). It should work fine in my miner, but perhaps crash in his miner.

[Velgelm]

In my version cards MSI gaming I can't lower the memory frequency, it is fixed on 3005Mhz

[th3.r00t]

I understand that by default your miner faster. But if you set the settings manually the same for both miners your miner is slightly faster, and then slower than free

It should be faster - we already know that SP tweaked the default intensity in his miner.

That doesn't mean that the comparison is fair -  to make a fair comparison of the miners and the kernels, the condition should be the same.
Lets say that SP's miner run by default on -i 25, so should be the intensity for Alexis78's miner when comparing.

If I'm not wrong in the same conditions (same intesities and clocks) Alexis78's miner are faster on vcash and decred.

[pallas]

the only fair conditions to compare miners is at the same power usage.
at the end of the story, it's efficiency that counts, not "maximum speed".
so just set a low tdp and see which one is faster.

[scryptr]

the only fair conditions to compare miners is at the same power usage.
at the end of the story, it's efficiency that counts, not "maximum speed".
so just set a low tdp and see which one is faster.

I'LL BACK THAT--

It is based on the economy of mining.  Variations in code may require different command-line tweaksfor best hashrate, but this proposed standard is based on the bottom line.       --scryptr

[sp_]

the only fair conditions to compare miners is at the same power usage.
at the end of the story, it's efficiency that counts, not "maximum speed".
so just set a low tdp and see which one is faster.

But If my version can run stable  @ 100mhz more, then my version is 6% faster.
And if my miner can run stable and fast with -i 31.9 and his version is crashing, then it's not fair to compare both of them with -i 25.

[pallas]

the only fair conditions to compare miners is at the same power usage.
at the end of the story, it's efficiency that counts, not "maximum speed".
so just set a low tdp and see which one is faster.

But If my version can run stable  @ 100mhz more, then my version is 6% faster.

it doesn't matter if it draws (say) 15% more power at that settings ;-)

[sp_]

Not if you downclock the memory to 500mhz. Less power.

[pallas]

Not if you downclock the memory to 500mhz. Same power.

then my assumption is still correct: if you run on low tdp, you can compare fairly.
a power reading at the wall can confirm.

[sp_]

then my assumption is still correct: if you run on low tdp, you can compare fairly.
a power reading at the wall can confirm.

Yes, For algos that doesn't use any memory, you can maintain the speed with a lower TDP.

[crysx]

the only fair conditions to compare miners is at the same power usage.
at the end of the story, it's efficiency that counts, not "maximum speed".
so just set a low tdp and see which one is faster.

I'LL BACK THAT--

It is based on the economy of mining.  Variations in code may require different command-line tweaksfor best hashrate, but this proposed standard is based on the bottom line.       --scryptr

i cannot agree with that ...

in MY mining - i disregard the power argument altogether ... as i dont tweak or manipulate ANY of the power settings ... ever ... i dont oc either ...

speed of the hashrate and its stability and its share acceptibility and correctness with the pools is all im after ...

the way to maximize coin income - is through hashrate optimization and accepted shares ...

if power efficiency was a factor in the speed calculations and results - then we would never be able to have fully optimized algos ...

yes - algos CAN be power efficient and have 'higher' hashrates than 'standard' released algos - but not at maximum optimization ... and IF algos can get the same hasrates at a lower power usage - then why not ... but thats not what teh whole issue is here ... its raw hasrates - regardless of power ...

its like saying that feul efficiency IS the factor in high octane drag races ... its not - its the time it takes to get from one point to another - and the fastest wins ... period ... they dont care how much feul or noise or rubber is used or destroyed in the process ...

same here ...

to hell with efficiency - i want max hashrates ( and we are talking stable and accepted shares ) to maximize the coinage ...

#crysx

[ltc_bilic]

Here is decred sp-mod decred #8 With max overclocking. I use -i 31,9 on the 980ti and -i 29 on the 750ti.



Here is the sourcecode of the sp-mod #4:

https://github.com/sp-hash/ccminer/commit/3a726d90efd528ed386407bbd5b223583d80b378

@sp What clocks do you run on you're Asus STRIX 750ti?

[pallas]

then my assumption is still correct: if you run on low tdp, you can compare fairly.
a power reading at the wall can confirm.

Yes, For algos that doesn't use any memory, you can maintain the speed with a lower TDP.

I tried all the kinds of algo and all have better power efficiency on P2 and low TDP.
Much higher.
The income depends on your margin, but I doubt you'll make more money by overclocking.
Unless you run on free electricity, of course.

[pallas]

its like saying that feul efficiency IS the factor in high octane drag races ... its not - its the time it takes to get from one point to another - and the fastest wins ... period ... they dont care how much feul or noise or rubber is used or destroyed in the process ...

that's because they have a wide margin.
everybody must take expenses into account.
if you made more money by lowering your TDP, wouldn't you do it?
do the math and you'll see.

[sp_]

that's because they have a wide margin.
everybody must take expenses into account.
if you made more money by lowering your TDP, wouldn't you do it?
do the math and you'll see.

But when decred came out, my private kernals where making $10 a day with the proper launchconfig on the 980ti. and the powercost was $0.5 (5%)

Pallas, did you try to overclock the core and lower the tdp at the same time?

[Velgelm]

I try overclock my 960 and 970 - both GPU work in 1600Mhz

at 1540Mhz degree - 75c
at 1600Mhz  degree 78c

[pallas]

that's because they have a wide margin.
everybody must take expenses into account.
if you made more money by lowering your TDP, wouldn't you do it?
do the math and you'll see.

But when decred came out, my private kernals where making $10 a day with the proper launchconfig on the 980ti. and the powercost was $0.5 (5%)

Pallas, did you try to overclock the core and lower the tdp at the same time?

fiddling with the clocks brings you to P0 and the end result was lower hashrate on same TDP.
windows may behave differently than linux, though.
finally it may depend on the driver version and card model.
in the case you are mentioning, the margin is so wide you probably better overclock, but this usually isn't the case.

[Velgelm]

I try overclock my 960 and 970 - both GPU work in 1600Mhz on Alexis78 miner
Work fine, good hashrate and temp like sp version miner
p.s 970 -i 28.9 960 -i 26.9