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

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?

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

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)

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.

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

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

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

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

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

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.

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.

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

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.

+1

reach mintpal today

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.

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.

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.

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

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

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

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

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