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

[IL MinaTore]

@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

there will be some update of the code to fix the problem ?

[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

there will be some update of the code to fix the problem ?

no idea - lets wait for dev to look at this

[badman74]

@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

there will be some update of the code to fix the problem ?

no idea - lets wait for dev to look at this

I can change that in the code then do a new windows compile to test when I get off work (in 6 hours)

[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

there will be some update of the code to fix the problem ?

no idea - lets wait for dev to look at this

I can change that in the code then do a new windows compile to test when I get off work (in 6 hours)

but i am not sure if this is the only place to be changed - but you can try

[badman74]

Can anyone share hashrates you get on qubit on 7850 GPUs with sph-sgminer? I can't max out 1.4mh for 7850 (on Ubuntu), but reading the thread I've got impression it should be at least 2mh for 7850?

it would depend on the coin you are mining
i get 1.9mh/s with a 6850 at --gpu-engine 950 --gpu-memclock 1150 -I 16 on qubit algo
and 930kh/s with --gpu-engine 900 --gpu-memclock 1000 -I 16 -g 2 -w 256 on dark

I run at 1050-1100 engine clock, and still can't get over 1.4mh on qubit and 800kh on dark, though gpus give perfect hashrates on scrypt/scrypt-jane.
Could you share your os and driver/sdk versions?

I run win 7 with the 13.2 drivers
mem clock is what seems to affect the hashrate the most

[badman74]

@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

there will be some update of the code to fix the problem ?

no idea - lets wait for dev to look at this

I can change that in the code then do a new windows compile to test when I get off work (in 6 hours)

but i am not sure if this is the only place to be changed - but you can try

will do some searching to see if I can find anything else then

[RoboCoder]

Since yesterday I have the problem in MPOS pools

100% : "share is above target"

but it was working well and I have not changed anything

Help, please

a lot of the mpos cpu pools have been fixing there pool so that gpu miners cant mine there

Hi - I am the owner of coinmine.pl pools and most probably sgminer has wrong settings coded for diff1 - this software is just spamming pools with incorrect shares and thats why most of them are rejected. Please fix it because stratum servers are set up correctly.

EDIT: or it just interpret share difficulty set by stratum differently than cpuminers... for example for quark based coins I have to set up stratum share diff as 1/256

feeleep

hey feleep, love coinmine.pl, can you let the user choose to set a difficulty manually? or choose between cpu/gpu diff settings to alleviate errors? im not sure there is anyway to do it from the client side here...

hi - atm I have vardiff implemented on all sites so it should automatically adjust difficulty - please check

havent checked myself but i found the gpu miners need at least .05 diff1 shares to work properly

I have tried it on src.coinmine.pl.  The only shares that don't seem to give the share above target error is ones that sgminer reports as difficulty 1 or higher - does that help any?  The pool seems to accept those also but sgminer doesnt increment the accepted counters.

I also would really like to use feeleep's pool but cannot because of this incompatibility.

I set up a test stratum server with higher difficulty - can you guys test if it works for you? If yes I can set up a separate stratum port for GPUs...

Pool: Securecoin
stratum server: mine1.coinmine.pl:6021

let me know if it's ok

feeleep

I could not connect to it.  I got the probing for an alive pool message.

[feeleep]

Since yesterday I have the problem in MPOS pools

100% : "share is above target"

but it was working well and I have not changed anything

Help, please

a lot of the mpos cpu pools have been fixing there pool so that gpu miners cant mine there

Hi - I am the owner of coinmine.pl pools and most probably sgminer has wrong settings coded for diff1 - this software is just spamming pools with incorrect shares and thats why most of them are rejected. Please fix it because stratum servers are set up correctly.

EDIT: or it just interpret share difficulty set by stratum differently than cpuminers... for example for quark based coins I have to set up stratum share diff as 1/256

feeleep

hey feleep, love coinmine.pl, can you let the user choose to set a difficulty manually? or choose between cpu/gpu diff settings to alleviate errors? im not sure there is anyway to do it from the client side here...

hi - atm I have vardiff implemented on all sites so it should automatically adjust difficulty - please check

havent checked myself but i found the gpu miners need at least .05 diff1 shares to work properly

I have tried it on src.coinmine.pl.  The only shares that don't seem to give the share above target error is ones that sgminer reports as difficulty 1 or higher - does that help any?  The pool seems to accept those also but sgminer doesnt increment the accepted counters.

I also would really like to use feeleep's pool but cannot because of this incompatibility.

I set up a test stratum server with higher difficulty - can you guys test if it works for you? If yes I can set up a separate stratum port for GPUs...

Pool: Securecoin
stratum server: mine1.coinmine.pl:6021

let me know if it's ok

feeleep

I could not connect to it.  I got the probing for an alive pool message.

I turned it off as this is not a problem with stratum - you can use normal port 6020

[darius08]

i made that change in the linux src from sph, didnt make a difference on the shares.

the higher diff stratum didnt make a difference? thats odd...i would think that since adding +1 to the user in p2p fixes the rejected share issue, adding diff would be the answer...weird.

[xtcminer]

Can anyone share hashrates you get on qubit on 7850 GPUs with sph-sgminer? I can't max out 1.4mh for 7850 (on Ubuntu), but reading the thread I've got impression it should be at least 2mh for 7850?

it would depend on the coin you are mining
i get 1.9mh/s with a 6850 at --gpu-engine 950 --gpu-memclock 1150 -I 16 on qubit algo
and 930kh/s with --gpu-engine 900 --gpu-memclock 1000 -I 16 -g 2 -w 256 on dark

I run at 1050-1100 engine clock, and still can't get over 1.4mh on qubit and 800kh on dark, though gpus give perfect hashrates on scrypt/scrypt-jane.
Could you share your os and driver/sdk versions?

I run win 7 with the 13.2 drivers
mem clock is what seems to affect the hashrate the most

Yeah, I tweaked mem clock, but everything above 1250 does no good. But this is not the engine or clock issue, since 30% difference is huge.
I run 13.4 on Ubuntu 13.10, and that seems to be the key. Will try another driver versions.

[bbr]

I know nothing about programming but came across the below on github in regard to issues with cgminer and slush's pool, if it makes any sense? :

I believe I can explain what the problem is: all this is due to a bug in recent versions of Cgminer where CGminer performs miscalculations due to the fact that extranonce size is reduced to 2 bytes by slush's stratum proxy. In fact those versions of CGminer can only handle 4 bytes of extranonce. If the proxy somehow manages to workaround this issue by reformatting extra nonce, adjusting offset, adding null bytes or passing extranonce in separate argument, then all versions of CGminer will be able to connect. Anyone who wants to provide a bugfix for slush stratum proxy, please check cgminer's source code in relation to extranonce size.

[azhago]

@phm
Hi !

Is it possible that you can add support for HEFTY1 to your miner? It is used in HeavyCoin. Here is the link: https://bitcointalk.org/index.php?topic=470391.0

+1

reach mintpal today

[phm]

Hi, just curious: Are there any plans to integrate these features into the main sgminer branch?

Personally I see little point in cluttering sgminer sources with OpenCL kernels from a dozen of altcoins, but there's nothing preventing sgminer devs from integrating my changes. Ask them, not me.

Miner program works like a charm :-)
Could you explain differences for all those scrypt mining *.cl kernels please?

No idea, they were already present in the original sgminer.

Is it possible that you can add support for HEFTY1 to your miner? It is used in HeavyCoin. Here is the link: https://bitcointalk.org/index.php?topic=470391.0

It's possible, but involves too much work to do it just for fun. The sad truth is that people are mining loads of coins with this software, but I can count donations to the project on my fingers. Organize a solid bounty and I may reconsider.

[phm]

@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 only place where this variable is used is in quarkcoin_test() function, which is not used at all in sgminer code, so I'm afraid this is not the cause. Thanks for suggestion anyway, I will investigate the issue when I have some free time.

[IL MinaTore]

@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 only place where this variable is used is in quarkcoin_test() function, which is not used at all in sgminer code, so I'm afraid this is not the cause. Thanks for suggestion anyway, I will investigate the issue when I have some free time.

if you can fix the miner on the algorithm quark'll be happy to donate for your work

[laxduke]

Hi, just curious: Are there any plans to integrate these features into the main sgminer branch?

Personally I see little point in cluttering sgminer sources with OpenCL kernels from a dozen of altcoins, but there's nothing preventing sgminer devs from integrating my changes. Ask them, not me.

Miner program works like a charm :-)
Could you explain differences for all those scrypt mining *.cl kernels please?

No idea, they were already present in the original sgminer.

Is it possible that you can add support for HEFTY1 to your miner? It is used in HeavyCoin. Here is the link: https://bitcointalk.org/index.php?topic=470391.0

It's possible, but involves too much work to do it just for fun. The sad truth is that people are mining loads of coins with this software, but I can count donations to the project on my fingers. Organize a solid bounty and I may reconsider.

Let's brake that HVC cyber cartel.
Give us btc wallet donations address so that we can gather some money there.

[Burninj]

It's possible, but involves too much work to do it just for fun. The sad truth is that people are mining loads of coins with this software, but I can count donations to the project on my fingers. Organize a solid bounty and I may reconsider.

how much the bounty?

Cbuchner is already working on implementing heavycoin in his cudaminer, that would be a shame if ATI owner coud not rip off the ass to of this ipo scamcoin

[km4700ruda]

It's possible, but involves too much work to do it just for fun. The sad truth is that people are mining loads of coins with this software, but I can count donations to the project on my fingers. Organize a solid bounty and I may reconsider.

how much the bounty?

Cbuchner is already working on implementing heavycoin in his cudaminer, that would be a shame if ATI owner coud not rip off the ass to of this ipo scamcoin

Agree with you,send your BTC address and I will donation.
Let me fuck this scamshitcoin.

[janos666]

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

[digitalindustry]

@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

there will be some update of the code to fix the problem ?

no idea - lets wait for dev to look at this

feeleep i was just about to ask about this, if only there were more people like you around !

the source code would have to be fixed in this case yes? also its great to see a good working open source version of this .

the reason i ask is because it seemed to work on some compiles and then not on others to varying degrees but then that could have been the pool because it was mining on different pools also?

i.e one pool noticed and another did not, but i believe this error could be present in the DRK mining aspect also as its shown similar behavior.

regards.