[ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 244.

lucid_ity

newbie

Activity: 5

Merit: 0

Quote from: mannyg on June 05, 2014, 10:30:56 AM

Quote from: oktay50000 on June 05, 2014, 08:25:33 AM

cant run it with cgwatcher Angry

gettin hw
any solution

I had the same problem with CGWatcher.. it strips out the pool options out of the config file after you save it. It *might* work if you dont save the config file through CGWatcher's conf file editor and save it normally through notepad instead. I didnt get that far into testing with it, i went back to the .bat file execution of it.

Removing the pool-gpu-threads from the individual pool entries fixed the 60 second timeout.

I am seeing X13 shares being accepted but at 0.00/0.00 .. seems like the diff settings arent right? I have a custom diff defined for X11/X13 at 0.01, low speed miner i used to test thing out with.

Yep you guys have found the cause of the issue quite a few of us are having. Launch this sgminer outside of cgwatcher, and algorithm switching works (so far). I'm still getting 20-30% rejects with keccak, but I believe I will be able to troubleshoot this by changing miner settings.

Anyway, mining without cgwatcher is kind of a deal-breaker for me. I guess it's back to waiting for updates.

mannyg

full member

Activity: 142

Merit: 101

Code:

sgminer 4.2.1 - Started: [2014-06-05 12:11:26]
--------------------------------------------------------------------------------
(5s):967.7K (avg):970.1Kh/s | A:0  R:0  HW:0  WU:0.013/m
ST: 1  SS: 0  NB: 3  LW: 172  GF: 0  RF: 0
Connected to NiceHash_X13 (stratum) diff 0.000 as user 1JPuuW8C65w9EwSj1FFHRjCb9h3GR41VMo
Block: 1063fbea...  Diff:1.39K  Started: [12:13:27]  Best share: -0.000
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0:  62.0C 3268RPM | 966.6K/970.1Kh/s | R:  0.0% HW:0 WU:0.013/m I:17
--------------------------------------------------------------------------------
[12:12:13] Accepted 499b152d Diff 0.000/0.000 GPU 0 at NiceHash_X13
[12:12:33] Accepted 98b9eb7b Diff 0.000/0.000 GPU 0 at NiceHash_X13
[12:12:35] Accepted f3d9efed Diff 0.000/0.000 GPU 0 at NiceHash_X13
[12:12:39] Stratum from NiceHash_X13 requested work restart
[12:13:08] Accepted d0b44297 Diff 0.000/0.000 GPU 0 at NiceHash_X13
[12:13:17] NiceHash_X13 extranonce change requested
[12:13:17] NiceHash_X13 difficulty changed to 0.004
[12:13:17] Stratum from NiceHash_X13 requested work restart
[12:13:20] Accepted f8eeef72 Diff 0.000/0.000 GPU 0 at NiceHash_X13
[12:13:23] Accepted 9fc43337 Diff 0.000/0.000 GPU 0 at NiceHash_X13
[12:13:26] Stratum from NiceHash_X13 requested work restart
[12:13:27] Network diff set to 1.39K
[12:13:27] Stratum from NiceHash_X13 detected new block
[12:13:56] Accepted bc72fa60 Diff 0.000/0.000 GPU 0 at NiceHash_X13

This is all I see when connected to X11 and X13 pools. All other pools display a correct diff for each share. Is this right? GPU is an XFX R7 260x, tc-8000, engine-1100, memclock-1500, worksize-128, intensity 17

*edit*
of course, 2 minutes after I post this, I see for the first time an accepted share of 23/0.000

Elun

member

Activity: 117

Merit: 10

Quote from: platinum4 on June 05, 2014, 11:00:43 AM

Just a note - I think the uptime counter re-initializes each time it flips to a different kernel.

I've left my rigs on all night, and a few are only counting up to ~53 minutes at the current moment - checked against Nicehash graphs and it looks like it was last on X11 about an hour ago...

That's kind of a cool feature, but I wonder if we can get it to stretch through the whole mining instance...

Here's an example of the calc error on the uptime counter -> https://i.imgur.com/GPPXuDj.png

Rig has been up for a good 6 (started at 0400, it's now 1015) hours but the uptime counter is only at 1 hour. Maybe we can make it the current algo uptime counter?

yep, found what is wrong, going to create issue on github.

platinum4

sr. member

Activity: 547

Merit: 250

Just a note - I think the uptime counter re-initializes each time it flips to a different kernel.

I've left my rigs on all night, and a few are only counting up to ~53 minutes at the current moment - checked against Nicehash graphs and it looks like it was last on X11 about an hour ago...

That's kind of a cool feature, but I wonder if we can get it to stretch through the whole mining instance...

Here's an example of the calc error on the uptime counter -> https://i.imgur.com/GPPXuDj.png

Rig has been up for a good 6 (started at 0400, it's now 1015) hours but the uptime counter is only at 1 hour. Maybe we can make it the current algo uptime counter?

mannyg

full member

Activity: 142

Merit: 101

Quote from: oktay50000 on June 05, 2014, 08:25:33 AM

cant run it with cgwatcher Angry

gettin hw
any solution

I had the same problem with CGWatcher.. it strips out the pool options out of the config file after you save it. It *might* work if you dont save the config file through CGWatcher's conf file editor and save it normally through notepad instead. I didnt get that far into testing with it, i went back to the .bat file execution of it.

Removing the pool-gpu-threads from the individual pool entries fixed the 60 second timeout.

I am seeing X13 shares being accepted but at 0.00/0.00 .. seems like the diff settings arent right? I have a custom diff defined for X11/X13 at 0.01, low speed miner i used to test thing out with.

oktay50000

sr. member

Activity: 560

Merit: 250

cant run it with cgwatcher Angry

gettin hw
any solution

cryptonit

legendary

Activity: 3052

Merit: 1053

bit.diamonds | uNiq.diamonds

please add -diamond option
with -groestlcoin u cant mine diamonds via stratum pool because grostlcoin algo dont use gen_hash()

Quote

Source code fixes to sph-sgminer published at https://github.com/danbi/sph-sgminer.

Hope to have it soon merged with the main branch. You can compile your own version. Let's hope someone does it for Windows users.

This is the most important code:

Quote

if (gpus[0].kernel == KL_FUGUECOIN || gpus[0].kernel == KL_GROESTLCOIN || gpus[0].kernel == KL_TWECOIN)
sha256(pool->coinbase, pool->swork.cb_len, merkle_root);
else
gen_hash(pool->coinbase, merkle_root, pool->swork.cb_len);

As you can see, Groestlcoin will go into sha256(), while Diamond will go into gen_hash()

Blago

sr. member

Activity: 416

Merit: 250

Quote from: Dophoeve on June 05, 2014, 07:32:18 AM

Cant seem to get more than 2.5 MH/s for x13 with the gpu-threads on 4. You only have gpu-threads 4 in the config or more settings?

Config for sph-sgminer_x11mod

x13mod:

Code:

"kernel-path" : "/usr/local/bin",
"kernel" : "x13mod,x13mod,x13mod,x13modold",

"vector" : "1",
"intensity" : "18,18,17,15",
"worksize" : "128,128,128,128",
"lookup-gap" : "2,2,2,2",
"gpu-threads" : "4,4,2,1",
"shaders" : "2048,1280,1024,400",
"thread-concurrency" : "10240,6400,5120,1920",
"gpu-engine" : "1070-1190,1100-1200,860-1150,980",
"gpu-memclock" : "1500,1200,1200,950",
"gpu-powertune" : "20,20,20,20",
"gpu-vddc" : "0.000,0.000,0.000,0.000",
"gpu-dyninterval" : "10",
"auto-fan" : true,
"auto-gpu" : true,
"gpu-fan" : "70-100,70-100,70-100,70-100",
"temp-cutoff" : "95,95,95,95",
"temp-overheat" : "90,90,90,90",
"temp-target" : "73,73,73,73",
"temp-hysteresis" : "3",
"api-listen" : true,
"api-mcast-port" : "4028",
"api-network" : true,
"api-port" : "4028",
"failover-switch-delay" : "30",
"log" : "5",
"no-pool-disable" : true,
"no-submit-stale" : true,
"tcp-keepalive" : "30",
"worktime" : true,
"shares" : "0",
"queue" : "3",
"expiry" : "60",
"scan-time" : "60",
"show-coindiff" : true,
"gpu-platform" : "0",
"device" : "0,1,2"

Dophoeve

full member

Activity: 182

Merit: 100

To the MOOOON

Quote from: Blago on June 05, 2014, 07:13:20 AM

Quote from: Dophoeve on June 05, 2014, 07:08:19 AM

Device 0 is 280x?

Yes,
0 = 280x
1 = 7870
2 = 7850

Cant seem to get more than 2.5 MH/s for x13 with the gpu-threads on 4. You only have gpu-threads 4 in the config or more settings?

Blago

sr. member

Activity: 416

Merit: 250

Quote from: Dophoeve on June 05, 2014, 07:08:19 AM

Device 0 is 280x?

Yes,
0 = 280x
1 = 7870
2 = 7850

Dophoeve

full member

Activity: 182

Merit: 100

To the MOOOON

Blago

sr. member

Activity: 416

Merit: 250

I'm compare hashrate sgminer by lasybear (x13mod) https://github.com/lasybear/sph-sgminer_x11mod
and sgminer V5_0 (marucoin-mod) https://github.com/sgminer-dev/sgminer/tree/v5_0
at the same config, (except "algorithm" : "marucoin-mod")
all miners i compile 7 hrs ago.

lasybear's sgminer maximum perfomance @:
device 0 280x - gpu-threads = 4
device 1 7870 - gpu-threads = 4
device 2 7850 - gpu-threads = 2

TABLE:

lasybear

reza_abay

member

Activity: 94

Merit: 10

i have two card 6990 and 290 but i cant two kernel in cofig file
example "pool-algorithm" : "marucoin-modold,marucoin-mod"
frist for 6990 and second for 290 but i get hw error please help for fixing this problem Kiss

i work with sgminer_x11x13mod_03_06_2014 good and no hw error with 2 kernel in cofig file (x13modold,x13mod) but with new sgminer multi algoritm dont work.

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

thread concurrency, vectors and lookup gap only make a difference for scrypt or sha256.
if you see different hashrates when you change them, try recompiling without changing them and you'll see different hashrates as well ;-)

alphateam

hero member

Activity: 1036

Merit: 531

Same hashrate then sph-miner for X11 and X13 with this one?

Dophoeve

full member

Activity: 182

Merit: 100

To the MOOOON

Quote from: platinum4 on June 05, 2014, 03:33:11 AM

Quote from: Dophoeve on June 05, 2014, 03:08:08 AM

Quote from: TheMathGuy on June 05, 2014, 03:06:52 AM

Quote from: platinum4 on June 05, 2014, 03:01:43 AM

ONCE AGAIN this another .conf file with ALL THE THREAD CONCURRENCIES AT THE LOWEST POSSIBLE VALUE OF 8192,

-- and there's no mixture of TC's, mixing worksizes, or mixing intensities... Why mine scrypt if it's on the absolute shittiest possible settings for hashrate?

Uhhmmm.... 8192 is the BEST TC value for the 280x, read his post better please.

Excessively cool story bro and I'm glad you've found your sweet spot, now that the Tahitis are solved, does anybody having a working .conf for all 4 algos on the Hawaii (290/290X) chipsets?

Go and try figure some conf's out yourself and don't shoot shit arguments at people who try to help.

Amph

legendary

Activity: 3248

Merit: 1070

Quote from: TheMathGuy on June 05, 2014, 03:06:52 AM

Quote from: platinum4 on June 05, 2014, 03:01:43 AM

ONCE AGAIN this another .conf file with ALL THE THREAD CONCURRENCIES AT THE LOWEST POSSIBLE VALUE OF 8192,

-- and there's no mixture of TC's, mixing worksizes, or mixing intensities... Why mine scrypt if it's on the absolute shittiest possible settings for hashrate?

Uhhmmm.... 8192 is the BEST TC value for the 280x, read his post better please.

TD is useless for x11/x13, only for scrypt, but we know scrypt is dead for gpu, so...

platinum4

sr. member

Activity: 547

Merit: 250

Quote from: Dophoeve on June 05, 2014, 03:08:08 AM

Quote from: TheMathGuy on June 05, 2014, 03:06:52 AM

Quote from: platinum4 on June 05, 2014, 03:01:43 AM

ONCE AGAIN this another .conf file with ALL THE THREAD CONCURRENCIES AT THE LOWEST POSSIBLE VALUE OF 8192,

-- and there's no mixture of TC's, mixing worksizes, or mixing intensities... Why mine scrypt if it's on the absolute shittiest possible settings for hashrate?

Uhhmmm.... 8192 is the BEST TC value for the 280x, read his post better please.

Excessively cool story bro and I'm glad you've found your sweet spot, now that the Tahitis are solved, does anybody having a working .conf for all 4 algos on the Hawaii (290/290X) chipsets?

Dophoeve

full member

Activity: 182

Merit: 100

To the MOOOON

Quote from: TheMathGuy on June 05, 2014, 03:06:52 AM

Quote from: platinum4 on June 05, 2014, 03:01:43 AM

ONCE AGAIN this another .conf file with ALL THE THREAD CONCURRENCIES AT THE LOWEST POSSIBLE VALUE OF 8192,

-- and there's no mixture of TC's, mixing worksizes, or mixing intensities... Why mine scrypt if it's on the absolute shittiest possible settings for hashrate?

Uhhmmm.... 8192 is the BEST TC value for the 280x, read his post better please.

TheMathGuy

newbie

Activity: 26

Merit: 0

Quote from: platinum4 on June 05, 2014, 03:01:43 AM

ONCE AGAIN this another .conf file with ALL THE THREAD CONCURRENCIES AT THE LOWEST POSSIBLE VALUE OF 8192,

-- and there's no mixture of TC's, mixing worksizes, or mixing intensities... Why mine scrypt if it's on the absolute shittiest possible settings for hashrate?

Uhhmmm.... 8192 is the BEST TC value for the 280x, read his post better please.

Pages:

Bitcoin Forum>Alternate cryptocurrencies>Mining (Altcoins)

Jump to:

Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 244. (Read 877843 times)