CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 703.

crysx

sr. member

Activity: 364

Merit: 260

--- ChainWorks Industries ---

Quote from: scryptr on April 12, 2016, 07:02:09 AM

Quote from: pallas on April 12, 2016, 06:47:50 AM

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

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: pallas on April 12, 2016, 07:06:38 AM

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.

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

Quote from: sp_ on April 12, 2016, 07:04:54 AM

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_

legendary

Activity: 2954

Merit: 1087

Team Black developer

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

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

Quote from: sp_ on April 12, 2016, 07:02:15 AM

Quote from: pallas on April 12, 2016, 06:47:50 AM

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_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: pallas on April 12, 2016, 06:47:50 AM

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.

scryptr

legendary

Activity: 1797

Merit: 1028

Quote from: pallas on April 12, 2016, 06:47:50 AM

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

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

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.

th3.r00t

sr. member

Activity: 312

Merit: 250

Quote from: Velgelm on April 12, 2016, 06:19:00 AM

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.

Velgelm

sr. member

Activity: 299

Merit: 250

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

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

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

sr. member

Activity: 299

Merit: 250

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_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: Velgelm on April 12, 2016, 06:12:12 AM

what is the proper launch configuration. ?

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

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: tbearhere on April 12, 2016, 06:11:18 AM

Same speed as quark... I just noticed that

With sp private #5.

For sp-private #5 quark use -i 25 on the 980ti. The default is -i 24

Velgelm

sr. member

Activity: 299

Merit: 250

what is the proper launch configuration. ?

tbearhere

legendary

Activity: 3164

Merit: 1003

Same speed as quark... I just noticed that

With sp private #5.

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

decred #8 is using 29 registers

here is the speed with a proper launch configuration.

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: Velgelm on April 12, 2016, 04:48:03 AM

960 ccminer -d 1 -i 26.9 -a decred --cpu-priority 1
970 ccminer -d 0 -i 28.9 -a decred --cpu-priority 2
this intensy gives better results

If you remove the intensity parameter and run both the exe files without the -i my miner is much faster. Basicly you reduce the speed of my kernal by putting on an intensity brake. you should also remove the --cpu-priority parameter. My VCASH mod is only using 25 registers(little GPU Resources), and need a high intensity and overclock. The right 970 card can run stable at a 1600MHZ core for weeks.

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: pallas on April 12, 2016, 05:03:15 AM

"faster" at the command line, slower at the pool ;-)

But in version #8 I have fixed the bug, and the hashrate is the same on the pool.

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

Quote from: sp_ on April 12, 2016, 05:00:51 AM

why don't you compile this:

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

copy the decred_ok.cu to decred.cu in the algo256 folder and rebuild.

And use -i 29.6 as intensity. It is "faster"

"faster" at the command line, slower at the pool ;-)

Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 703. (Read 2347641 times)