Topic: [ANN] sph-sgminer: multi-coin multi-algorithm GPU miner | added MaruCoin - page 54. (Read 515713 times)

I understand this but there is one problem - in original CPU miner from Neisklar (https://github.com/Neisklar/quarkcoin-cpuminer) I am pretty sure diff1 is set the same as sha256 and it is used by thousands of users...

However I set up a separate stratum port (once again) for GPU users on Securecoin pool. As I dont have any GPU rig now could anyone test it for a while and post results?

mine1.coinmine.pl:6021

feeleep

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.

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.

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.

@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:


instead of:


please consider this

feeleep

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.

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.

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:


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).

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).

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

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)

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.

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

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

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?

you mean mine-pool or coinmine?

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.

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?