Bitcoin Forum
December 18, 2017, 07:46:56 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 ... 72 »
  Print  
Author Topic: [ANN] sph-sgminer: multi-coin multi-algorithm GPU miner | added MaruCoin  (Read 512880 times)
janos666
Hero Member
*****
Offline Offline

Activity: 574


View Profile
March 12, 2014, 01:33:43 AM
 #341

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).
1513626416
Hero Member
*
Offline Offline

Posts: 1513626416

View Profile Personal Message (Offline)

Ignore
1513626416
Reply with quote  #2

1513626416
Report to moderator
1513626416
Hero Member
*
Offline Offline

Posts: 1513626416

View Profile Personal Message (Offline)

Ignore
1513626416
Reply with quote  #2

1513626416
Report to moderator
1513626416
Hero Member
*
Offline Offline

Posts: 1513626416

View Profile Personal Message (Offline)

Ignore
1513626416
Reply with quote  #2

1513626416
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513626416
Hero Member
*
Offline Offline

Posts: 1513626416

View Profile Personal Message (Offline)

Ignore
1513626416
Reply with quote  #2

1513626416
Report to moderator
1513626416
Hero Member
*
Offline Offline

Posts: 1513626416

View Profile Personal Message (Offline)

Ignore
1513626416
Reply with quote  #2

1513626416
Report to moderator
digitalindustry
Hero Member
*****
Offline Offline

Activity: 798


wubba lubba dub dub


View Profile WWW
March 12, 2014, 02:00:23 AM
 #342

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

tiny rick !
- https://voat.co/v/Contact/
- Twitter @Kolin_Quark
badman74
Hero Member
*****
Offline Offline

Activity: 602



View Profile
March 12, 2014, 02:47:26 AM
 #343

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)
Angel991
Newbie
*
Offline Offline

Activity: 4


View Profile
March 12, 2014, 05:55:38 AM
 #344

@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
Legendary
*
Offline Offline

Activity: 1193


View Profile WWW
March 12, 2014, 06:05:57 AM
 #345

@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 Smiley) - 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
Newbie
*
Offline Offline

Activity: 4


View Profile
March 12, 2014, 06:32:00 AM
 #346

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
Legendary
*
Offline Offline

Activity: 1193


View Profile WWW
March 12, 2014, 06:39:11 AM
 #347

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
Newbie
*
Offline Offline

Activity: 4


View Profile
March 12, 2014, 06:48:00 AM
 #348

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 Smiley I has accounts in both, and use them with CPU now, the performance of both pools are similar. However I cannot use GPU.
Amph
Legendary
*
Offline Offline

Activity: 1722


Zabercoin – An Asset Backed Cryptocurrency


View Profile
March 12, 2014, 10:01:51 AM
 #349

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

THE FUTURE OF
REAL ESTATE
..

║║
║║
║║
▬▬ ● ● ▬▬▬▬▬▬▬ ● ● ▬▬▬▬▬▬▬ ● ● ▬▬▬▬▬▬ ● ● ▬▬

║║
║║
║║
reorder
Sr. Member
****
Offline Offline

Activity: 462


View Profile
March 12, 2014, 10:06:27 AM
 #350

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 Smiley) - 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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
March 12, 2014, 10:30:39 AM
 #351

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

BTC: 16TgAGdiTSsTWSsBDphebNJCFr1NT78xFW
SRC: scefi1XMhq91n3oF5FrE3HqddVvvCZP9KB
phm
Full Member
***
Offline Offline

Activity: 182


View Profile
March 12, 2014, 11:55:17 AM
 #352

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

My hobby: mining CPU-only coins with GPU
feeleep
Legendary
*
Offline Offline

Activity: 1193


View Profile WWW
March 12, 2014, 12:02:02 PM
 #353

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 Smiley) - 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
Hero Member
*****
Offline Offline

Activity: 574


View Profile
March 12, 2014, 04:19:11 PM
 #354

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. Roll Eyes

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
Full Member
***
Offline Offline

Activity: 182


View Profile
March 12, 2014, 05:54:12 PM
 #355


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.

My hobby: mining CPU-only coins with GPU
badman74
Hero Member
*****
Offline Offline

Activity: 602



View Profile
March 12, 2014, 09:15:22 PM
 #356

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. Roll Eyes

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
Hero Member
*****
Offline Offline

Activity: 602



View Profile
March 12, 2014, 09:35:52 PM
 #357

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
Member
**
Offline Offline

Activity: 63


View Profile
March 12, 2014, 09:48:14 PM
 #358

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

BLK: BLsJMvE3KxNVEtTNUyKjtt1NRSSwdWgNMZ
Dash: XjUet3evCnXa9pPaPtZg5acjDxtq2447rJ
ocminer
Legendary
*
Online Online

Activity: 1946



View Profile WWW
March 12, 2014, 09:55:35 PM
 #359

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.

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
badman74
Hero Member
*****
Offline Offline

Activity: 602



View Profile
March 12, 2014, 10:21:36 PM
 #360

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
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 ... 72 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!