[ANN] sph-sgminer: multi-coin multi-algorithm GPU miner | added MaruCoin

[badman74]

It seems to be scarily easy to freeze my whole Linux by experimenting with DarkCoin mining. (I have to go out to the garage and flip the power switch!)
These are my well established settings for the basic sgminer (git master) and the regular litecoin scrypt algo with the good old ckolivas kernel:

Code:

"shaders" : "2560,2560,2560,2816",
"thread-concurrency" : "20480,20480,20480,22528",
"xintensity" : "300",
"lookup-gap" : "0",
"gpu-threads" : "1",
"worksize" : "512",
"gpu-powertune" : "50",
"gpu-engine" : "1000,1060,1000,1000",
"gpu-memclock" : "1450,1450,1475,1475",
"gpu-fan" : "50-100",
"temp-cutoff" : "99",
"temp-overheat" : "95",
"temp-target" : "85",
"temp-hysteresis" : "2",
"auto-fan" : true,
"failover-only" : true,
"kernel" : "ckolivas",
"log" : "1",
"queue" : "0"

First note: Yes, I know that worksize will actually end up at 256 and LG at 2 but I keep these settings to see if a new sgminer version will actually use these and they don't make a difference now.

If I just simply replace the kernel with "darkcoin" then I get an instant crash.
I figured it out by trial and error that I must use lower intensities. But still, I can't reach a nice performance before I hit a linux-freezer wall with intensity or xintensity (higher values seem to grant me considerably more speed before the system goes dark).

Should I find the highest possible xintensity by trial and error method, or do I need to change something else?
I tried to set below-reference GPU and VRAM clocks, that's not the issue.
I tried ~1.5-2x higher TC values.
(And yes, I tried to set worksize to 256 and LG to 2, even if they end up at that in practice anyway.)


And how can this miner freeze my whole Linux OS anyway?
The basic sgminer or the original cgminer could never do that. I was always able to reboot through SSH, even if X crashed (for example, due to too high over-clocking attempts).

start with your clock speeds, i can go a bit higher on dark as it generates less heat and that gives me more hash rate
then start upping intensity
i get around 18 to 20 intensity before things start acting funny
also i think your drivers may affect your speed as well
13.1 and 13.2 seem to be ok (i run windows so any linux irregularities are a mystery)

[1715448969]

1715448969

[1715448969]

1715448969

[Angel991]

@phm

I was investigating rejected share ration for quark based coins and noticed that you may have a mistake in the code:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/quarkcoin.c#L144

for quarks it should be:

Code:

static const uint32_t diff1targ = 0x00000000ffff;

instead of:

Code:

static const uint32_t diff1targ = 0x0000ffff;

please consider this

feeleep

The current and previous sgminer releases are work with supernova pool without any problems now. And both worked with mine-pool until March 7, after that both are rejected. And now both don't work with coinmine.pl
I'm afraid the problem is in the pool settings

[feeleep]

@phm

I was investigating rejected share ration for quark based coins and noticed that you may have a mistake in the code:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/quarkcoin.c#L144

for quarks it should be:

Code:

static const uint32_t diff1targ = 0x00000000ffff;

instead of:

Code:

static const uint32_t diff1targ = 0x0000ffff;

please consider this

feeleep

The current and previous sgminer releases are work with supernova pool without any problems now. And both worked with mine-pool until March 7, after that both are rejected. And now both don't work with coinmine.pl
I'm afraid the problem is in the pool settings

because maybe pool owners corrected their settings?

Problem with current sgminer is that is spams stratum server with lots of shares - If I change settings to accept those shares you will see that from one AMD280 card you have like 100MHash which is of course wrong. Few months ago there was the same problem with quark cpu miner - someone "corrected" miner source code which also spammed stratum with incorrect shares and if pool was not set up correctly that guy had huge hashrates there however almost never finding blocks.

Actually there are two guys who may help here as well (I finished my C++ programming 20 years ago ) - murraypaul who actually discovered the problem with "corrected" Quark miner and also reorder who fixed similar problem with his cgminer implementation for Skeincoin. I will send them PMs to look at this thread...

feeleep

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

[Angel991]

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

I think it's wrong, I don't like supernova for this reason.
Could you reject sgminer with high percent of errors only? I used it with mine-pool until March 7, and it had about 1% errors only.

[feeleep]

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

I think it's wrong, I don't like supernova for this reason.
Could you reject sgminer with high percent of errors only? I used it with mine-pool until March 7, and it had about 1% errors only.

you mean mine-pool or coinmine?

[Angel991]

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

I think it's wrong, I don't like supernova for this reason.
Could you reject sgminer with high percent of errors only? I used it with mine-pool until March 7, and it had about 1% errors only.

you mean mine-pool or coinmine?

Anyone I has accounts in both, and use them with CPU now, the performance of both pools are similar. However I cannot use GPU.

[Amph]

i found that intensity is the key here, set it to 18 and -g to 1

[reorder]

because maybe pool owners corrected their settings?

Problem with current sgminer is that is spams stratum server with lots of shares - If I change settings to accept those shares you will see that from one AMD280 card you have like 100MHash which is of course wrong. Few months ago there was the same problem with quark cpu miner - someone "corrected" miner source code which also spammed stratum with incorrect shares and if pool was not set up correctly that guy had huge hashrates there however almost never finding blocks.

Actually there are two guys who may help here as well (I finished my C++ programming 20 years ago ) - murraypaul who actually discovered the problem with "corrected" Quark miner and also reorder who fixed similar problem with his cgminer implementation for Skeincoin. I will send them PMs to look at this thread...

feeleep

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

Pool and miner should agree on diff1 target, or it will not work because the target is sent in compact format in stratum. Ideally, but not necessarily, it should also match the wallet diff1 to prevent confusion.

However, sgminer may not be consistent in how it calculates this (or so it seems): it does not ajust truediffone for modified diffone here:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/sgminer.c#L2967

Please compare it with cgminer which has an adjustment (diff1 is 0x0000FFFF for scrypt):

https://github.com/Kalroth/cgminer-3.7.2-kalroth/blob/master/cgminer.c#L3306

[murraypaul]

because maybe pool owners corrected their settings?

Problem with current sgminer is that is spams stratum server with lots of shares - If I change settings to accept those shares you will see that from one AMD280 card you have like 100MHash which is of course wrong. Few months ago there was the same problem with quark cpu miner - someone "corrected" miner source code which also spammed stratum with incorrect shares and if pool was not set up correctly that guy had huge hashrates there however almost never finding blocks.

Actually there are two guys who may help here as well (I finished my C++ programming 20 years ago ) - murraypaul who actually discovered the problem with "corrected" Quark miner and also reorder who fixed similar problem with his cgminer implementation for Skeincoin. I will send them PMs to look at this thread...

feeleep

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

Pool and miner should agree on diff1 target, or it will not work because the target is sent in compact format in stratum. Ideally, but not necessarily, it should also match the wallet diff1 to prevent confusion.

However, sgminer may not be consistent in how it calculates this (or so it seems): it does not ajust truediffone for modified diffone here:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/sgminer.c#L2967

Please compare it with cgminer which has an adjustment (diff1 is 0x0000FFFF for scrypt):

https://github.com/Kalroth/cgminer-3.7.2-kalroth/blob/master/cgminer.c#L3306

Yes, I agree, this matches the earlier problem with the Quark miner that feeleep mentions above.
Scrypt difficulty needs to be scaled by 65535, if this is not done then you will be submitting shares below the actual difficulty target.
If the pool code has a similar bug, it will accept the shares and credit you with the work, but the shares have no chance of solving a block, so you will be taking an unfair portion of any pool reward for blocks found, compared to miners that only submit correctly scaled shares.
In short, the new miner may report very impressive hash rates, but these are spurious, and do not reflect actual useful work.

[phm]

because maybe pool owners corrected their settings?

Problem with current sgminer is that is spams stratum server with lots of shares - If I change settings to accept those shares you will see that from one AMD280 card you have like 100MHash which is of course wrong. Few months ago there was the same problem with quark cpu miner - someone "corrected" miner source code which also spammed stratum with incorrect shares and if pool was not set up correctly that guy had huge hashrates there however almost never finding blocks.

Actually there are two guys who may help here as well (I finished my C++ programming 20 years ago ) - murraypaul who actually discovered the problem with "corrected" Quark miner and also reorder who fixed similar problem with his cgminer implementation for Skeincoin. I will send them PMs to look at this thread...

feeleep

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

Pool and miner should agree on diff1 target, or it will not work because the target is sent in compact format in stratum. Ideally, but not necessarily, it should also match the wallet diff1 to prevent confusion.

However, sgminer may not be consistent in how it calculates this (or so it seems): it does not ajust truediffone for modified diffone here:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/sgminer.c#L2967

Please compare it with cgminer which has an adjustment (diff1 is 0x0000FFFF for scrypt):

https://github.com/Kalroth/cgminer-3.7.2-kalroth/blob/master/cgminer.c#L3306

There is target adjustment in sph-sgminer depending on the coin, this is what DM_SELECT(1, 256, 65536) does. Currently for darkcoin and myriadcoin-groestl truediffone is multiplied by 1, for quarkcoin and qubitcoin it's multiplied by 256 and for scrypt it's multiplied by 65536.

[feeleep]

because maybe pool owners corrected their settings?

Problem with current sgminer is that is spams stratum server with lots of shares - If I change settings to accept those shares you will see that from one AMD280 card you have like 100MHash which is of course wrong. Few months ago there was the same problem with quark cpu miner - someone "corrected" miner source code which also spammed stratum with incorrect shares and if pool was not set up correctly that guy had huge hashrates there however almost never finding blocks.

Actually there are two guys who may help here as well (I finished my C++ programming 20 years ago ) - murraypaul who actually discovered the problem with "corrected" Quark miner and also reorder who fixed similar problem with his cgminer implementation for Skeincoin. I will send them PMs to look at this thread...

feeleep

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

Pool and miner should agree on diff1 target, or it will not work because the target is sent in compact format in stratum. Ideally, but not necessarily, it should also match the wallet diff1 to prevent confusion.

However, sgminer may not be consistent in how it calculates this (or so it seems): it does not ajust truediffone for modified diffone here:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/sgminer.c#L2967

Please compare it with cgminer which has an adjustment (diff1 is 0x0000FFFF for scrypt):

https://github.com/Kalroth/cgminer-3.7.2-kalroth/blob/master/cgminer.c#L3306

There is target adjustment in sph-sgminer depending on the coin, this is what DM_SELECT(1, 256, 65536) does. Currently for darkcoin and myriadcoin-groestl truediffone is multiplied by 1, for quarkcoin and qubitcoin it's multiplied by 256 and for scrypt it's multiplied by 65536.

so here may be the problem - quarks should have diff1 similar as sha256 coins (so multiplier = 1)

[janos666]

start with your clock speeds, i can go a bit higher on dark as it generates less heat and that gives me more hash rate
then start upping intensity
i get around 18 to 20 intensity before things start acting funny
also i think your drivers may affect your speed as well
13.1 and 13.2 seem to be ok (i run windows so any linux irregularities are a mystery)

May be I wasn't clear about the problem. It's more like a stability than performance problem. Well, it could be either:
A: a stability problem which prevents me from reaching a good performance
B: a performance problem which makes me push the system past it's stable limits in a hope to harness a good enough performance

I started with the clock speeds after my first system wide crash: I lowered them. It didn't help. I don't think higher clock rates would help me stabilize an already unstable system.

Interesting. My system black out around intensity 14 or xintensity 100. Starting up sph-sgminer for darkcoin with intensity 18 causes an instant system crash.
So, I guess it's case A. I can't reach a good performance due to a stability issue.

I have 290(X) cards and Linux which practically limits me to 13.12 (stable). Older and newer Linux beta drivers for these cards are either unstable/buggy or run sgminer slower.

By the way, I already flashed the cards with Stilt's VBIOSes before I tried mining DarkCoin for the first time. It proved to be nice for both litecoin or vertcoin scrypt and it didn't cause any problems with Keccak either (but of course, it didn't help with SHA-3 which is far less VRAM bandwidth heavy).

[phm]

There is target adjustment in sph-sgminer depending on the coin, this is what DM_SELECT(1, 256, 65536) does. Currently for darkcoin and myriadcoin-groestl truediffone is multiplied by 1, for quarkcoin and qubitcoin it's multiplied by 256 and for scrypt it's multiplied by 65536.

so here may be the problem - quarks should have diff1 similar as sha256 coins (so multiplier = 1)

Are you sure about this? Because for example hash of BTC block 10 (difficulty = 1) is:

000000002c05cc2e78923c34df87fd108b22221ac6076c18f3ade378a4d915e9

and hash of QRK block 600 (difficulty = 1.01576304) is:

00000096b99f154706b957c0e36cc4bf3789849e8a0684278dffac607b404641

so QRK definitely has higher target than BTC for this difficulty, otherwise this block would not be accepted. I'm not an expert in this, though.

Also take a look at:

https://github.com/bitcoin/bitcoin/blob/master/src/rpcblockchain.cpp#L36

and

https://github.com/MaxGuevara/quark/blob/master/src/rpcblockchain.cpp#L31

In BTC dDiff is multiplied/divided by 256 until nShift is 29 while in QRK it's multiplied/divided by 256 until nShift is 30 - so IMHO for two difficulties with the same value target value will be shifted by 8 bits.

Note that sph-sgminer displays network difficulty correctly for Quark and QubitCoin. It wouldn't be correct with wrong multiplier.

[badman74]

start with your clock speeds, i can go a bit higher on dark as it generates less heat and that gives me more hash rate
then start upping intensity
i get around 18 to 20 intensity before things start acting funny
also i think your drivers may affect your speed as well
13.1 and 13.2 seem to be ok (i run windows so any linux irregularities are a mystery)

May be I wasn't clear about the problem. It's more like a stability than performance problem. Well, it could be either:
A: a stability problem which prevents me from reaching a good performance
B: a performance problem which makes me push the system past it's stable limits in a hope to harness a good enough performance

I started with the clock speeds after my first system wide crash: I lowered them. It didn't help. I don't think higher clock rates would help me stabilize an already unstable system.

Interesting. My system black out around intensity 14 or xintensity 100. Starting up sph-sgminer for darkcoin with intensity 18 causes an instant system crash.
So, I guess it's case A. I can't reach a good performance due to a stability issue.

I have 290(X) cards and Linux which practically limits me to 13.12 (stable). Older and newer Linux beta drivers for these cards are either unstable/buggy or run sgminer slower.

By the way, I already flashed the cards with Stilt's VBIOSes before I tried mining DarkCoin for the first time. It proved to be nice for both litecoin or vertcoin scrypt and it didn't cause any problems with Keccak either (but of course, it didn't help with SHA-3 which is far less VRAM bandwidth heavy).

hmm that is strange...
i get 2.85mh/s on my 290x with stock bios and 1050 core, 1500 mem clock at I 20 stable
so it must be something with linux i guess

edit: i have to use -g 2 to get the best performance on dark

[badman74]

Since my last build was missing zlib1.dll and was causing problems for newbies, here is a new link for the build
sgminer [DRK_Q2C_QRK_MYR].rar

[xsedivy]

It seems to be scarily easy to freeze my whole Linux by experimenting with DarkCoin mining. (I have to go out to the garage and flip the power switch!)
These are my well established settings for the basic sgminer (git master) and the regular litecoin scrypt algo with the good old ckolivas kernel:

Code:

"xintensity" : "300",
"gpu-threads" : "1",

First note: Yes, I know that worksize will actually end up at 256 and LG at 2 but I keep these settings to see if a new sgminer version will actually use these and they don't make a difference now.

If I just simply replace the kernel with "darkcoin" then I get an instant crash.
I figured it out by trial and error that I must use lower intensities. But still, I can't reach a nice performance before I hit a linux-freezer wall with intensity or xintensity (higher values seem to grant me considerably more speed before the system goes dark).

Should I find the highest possible xintensity by trial and error method, or do I need to change something else?
I tried to set below-reference GPU and VRAM clocks, that's not the issue.
I tried ~1.5-2x higher TC values.
(And yes, I tried to set worksize to 256 and LG to 2, even if they end up at that in practice anyway.)


And how can this miner freeze my whole Linux OS anyway?
The basic sgminer or the original cgminer could never do that. I was always able to reboot through SSH, even if X crashed (for example, due to too high over-clocking attempts).

Try to change xintensity to 4 (not a typo) and gpu-threads to 2

[ocminer]

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

I think it's wrong, I don't like supernova for this reason.
Could you reject sgminer with high percent of errors only? I used it with mine-pool until March 7, and it had about 1% errors only.

Hey guys,

you can simply PM me if you have any strange observations or questions, I'm always around and I think we should work together instead of "disliking" someone or something without even notifying him about this..

I've banned those fake shares now too, the strange thing is, even those miners are sending like 100 MH/s from just one miner, sometimes there are also VALID shares between those 95% invalid..

The problem is, it is too hard to filter out the good ones, as the miners spams stratum with bad shares all the time.

[badman74]

EDIT: Just looked at supernova pool and someone pointed 350 (now) 550 MHash there (1/3 of the network more or less) but still did not find a block - you guys still think it is valid?

I think it's wrong, I don't like supernova for this reason.
Could you reject sgminer with high percent of errors only? I used it with mine-pool until March 7, and it had about 1% errors only.

Hey guys,

you can simply PM me if you have any strange observations or questions, I'm always around and I think we should work together instead of "disliking" someone or something without even notifying him about this..

I've banned those fake shares now too, the strange thing is, even those miners are sending like 100 MH/s from just one miner, sometimes there are also VALID shares between those 95% invalid..

The problem is, it is too hard to filter out the good ones, as the miners spams stratum with bad shares all the time.

it seems like sgminer only sends those bad shares when the diff is too low (.008 and below) at the same time it causes massive amounts of HW errors that dont stop occuring till you either restart sgminer or it crashes your display drivers

[qbitx]

@phm

I was investigating rejected share ration for quark based coins and noticed that you may have a mistake in the code:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/quarkcoin.c#L144

for quarks it should be:

Code:

static const uint32_t diff1targ = 0x00000000ffff;

instead of:

Code:

static const uint32_t diff1targ = 0x0000ffff;

please consider this

feeleep

This comment makes no sense!
Both of those lines do literally the exact same thing.  The first one might actually make some compilers mad for setting a uint32_t (32 bits!) to a value that appears to be padded out to 48 bits in length (why?!)
In C, setting "a = 0xFFFF", "a = 0x00FFFF", "a = 65535", "a = 0x0000FFFF", all have the same EXACT RESULT.  The only difference is readability.

Please explain why you would ever use the first statement.

[feeleep]

@phm

I was investigating rejected share ration for quark based coins and noticed that you may have a mistake in the code:

https://github.com/prettyhatemachine/sph-sgminer/blob/master/quarkcoin.c#L144

for quarks it should be:

Code:

static const uint32_t diff1targ = 0x00000000ffff;

instead of:

Code:

static const uint32_t diff1targ = 0x0000ffff;

please consider this

feeleep

This comment makes no sense!
Both of those lines do literally the exact same thing.  The first one might actually make some compilers mad for setting a uint32_t (32 bits!) to a value that appears to be padded out to 48 bits in length (why?!)
In C, setting "a = 0xFFFF", "a = 0x00FFFF", "a = 65535", "a = 0x0000FFFF", all have the same EXACT RESULT.  The only difference is readability.

Please explain why you would ever use the first statement.

indeed it doesn't make sense but I said I haven't touched c++ for 20 years