Raise that shit too high and you'll be holding down the power button and hard-resetting your hung rigs every 6 minutes.
You are prikolist! :-))(Prikolist is a man who like jokes)
Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 188. (Read 877859 times)
July 25, 2014, 06:56:47 AM
(Prikolist is a man who like jokes)
July 25, 2014, 06:06:54 AM
Your x11 hashrate will be dependent mostly on memclock speed, if you can hold at 1350, great, I can't though.
I didn't know that x[n] algorythms are sensitive to memory speed.
Does it mean we must rise memory clock speed to achieve maximum hash rate at x11, x13, x15 ?
Raise that shit too high and you'll be holding down the power button and hard-resetting your hung rigs every 6 minutes.
Not with my Asus dcII 290x..still stable with 1500mem
love my card 
x15 testing and running 4080kh/s
4100kh/s
Code:
sgminer 4.2.2 - Started: [2014-07-25 12:33:01] - [0 days 01:07:01]
--------------------------------------------------------------------------------
(5s):4.104M (avg):4.080Mh/s | A:3 R:0 HW:0 WU:0.059/m
ST: 0 SS: 1 NB: 107 LW: 4080 GF: 0 RF: 0
Connected to am02 x15 (stratum) diff 0.007 as user bullus.3
Block: 40a76a3e... Diff:88 Started: [13:39:54] Best share: 26
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 74.0C 85% | 4.100M/4.084Mh/s | R: 0.6% HW:0 WU:0.060/m xI: 51
--------------------------------------------------------------------------------
GPU 0: 4.1 / 4.1 Mh/s | A:345 R:2 HW:0 U:8.51/m I:0 xI:51 rI:0
73.0 C F: 85% E: 1060 MHz M: 1500 Mhz V: 0.000V A: 100% P: 10%
Last initialised: [2014-07-25 12:57:15]
Thread 0: 2.0 Mh/s Enabled ALIVE
Thread 1: 2.0 Mh/s Enabled ALIVE
[E]nable [D]isable [R]estart GPU [C]hange settings
[I]ntensity E[x]perimental intensity R[a]w Intensity
Or press any other key to continue
edit
Final speeds Asus DCII 290X
@1060/1500 stock Voltage (ratio 1:1.415)
X11=6350
X13=4650
X15=4100
@1060/1425
X11=6305
X13=4585---> not much difference but with mem@1500 it does make difference
X15=4005---> not much difference
@1060/1350
X11=6200
X13=4585
X15=4000
@1050/1350
X11=6150
X13=4575
X15=3970
@1000/1415 (ratio 1:1.415) -> but can lower my voltage..let's see if hash/watt is better.
X11=6170
X13=4560
X15=3990
Code:
{
"profiles" : [
{
"name" : "x11",
"algorithm" : "darkcoin-mod",
"xintensity" : "64",
"gpu-threads" : "2",
"worksize": "64"
},
{
"name" : "x13",
"algorithm" : "marucoin-mod",
"xintensity" : "51",
"gpu-threads" : "2",
"worksize": "64"
},
{
"name" : "x15",
"algorithm" : "bitblock",
"xintensity" : "51",
"gpu-threads" : "2",
"worksize": "64"
},
{
"name" : "nist5",
"algorithm" : "talkcoin-mod",
"intensity" : "16",
"gpu-threads" : "2",
"worksize": "64"
}
],
"default-profile": "x15",
"hamsi-expand-big" : "7",
"shaders" : "2816",
"gpu-fan" : "85-100",
"gpu-powertune" : "10",
"gpu-vddc" : "0",
"auto-fan" : true,
"failover-only" : true,
"expiry" : "1",
"gpu-dyninterval" : "7",
"hotplug" : "5",
"log" : "5",
"queue" : "0",
"scan-time" : "1",
"temp-hysteresis" : "2",
"shares" : "0",
"no-submit-stale" : true,
"no-restart" : true,
"failover-switch-delay" : "30",
"show-coindiff" : true,
"remove-disabled" : true,
"extranonce-subscription" : true
}
July 25, 2014, 05:54:56 AM
Your x11 hashrate will be dependent mostly on memclock speed, if you can hold at 1350, great, I can't though.
I didn't know that x[n] algorythms are sensitive to memory speed.
Does it mean we must rise memory clock speed to achieve maximum hash rate at x11, x13, x15 ?
Raise that shit too high and you'll be holding down the power button and hard-resetting your hung rigs every 6 minutes.
July 25, 2014, 05:54:01 AM
edit
I notice a hashrate drop to below 6mh/s and rise back again with xI=65.
Drop to xI=64 (6274kh/s) and is not dropping anymore.(10kh/s or so)
I notice a hashrate drop to below 6mh/s and rise back again with xI=65.
Drop to xI=64 (6274kh/s) and is not dropping anymore.(10kh/s or so)
Interesting. I've noticed that xI:64 is a slight increase in performance on x11; but absolutely no increase in performance on x13/x14/x15.
Sticking with xI: 50 still provides 4M solid on 290X on x15. I wanna see if we can get 4.1 somehow. I'm still stuck at WU: .056/m maximum on x15. Would be nice to increase it by .001-.003
July 25, 2014, 05:47:06 AM
Your x11 hashrate will be dependent mostly on memclock speed, if you can hold at 1350, great, I can't though.
I didn't know that x[n] algorythms are sensitive to memory speed.
Does it mean we must rise memory clock speed to achieve maximum hash rate at x11, x13, x15 ?
July 25, 2014, 04:37:35 AM
Thanks to all who answered :-)
no, -q is very silent ))
It works!!! :-)
--quiet|-q Disable logging output, display status and errors
--log|-l Interval in seconds between log output (default: 5)
--log|-l
no, -q is very silent ))
--log-file log.txt
It works!!! :-)
July 25, 2014, 03:07:26 AM
Is this fast
No, it can be faster
edit
I notice a hashrate drop to below 6mh/s and rise back again with xI=65.
Drop to xI=64 (6274kh/s) and is not dropping anymore.(10kh/s or so)
Edit2
As u can see the Accepted shares are calculate fine in sgminer, but the above value isn't.
Is it hard to change the above value to the value sgminer is showing with "G".?
edit3
Still stable after 3 hours.
Restarted and see if the other algos also be stable...6.346kh/s
Code:
sgminer 4.2.2 - Started: [2014-07-25 09:47:50] - [0 days 00:18:36]
--------------------------------------------------------------------------------
(5s):6.211M (avg):6.078Mh/s | A:2 R:0 HW:0 WU:0.083/m
ST: 0 SS: 0 NB: 30 LW: 1796 GF: 1 RF: 0
Connected to am02 x11 (stratum) diff 0.013 as user xxxx
Block: 204bc369... Diff:119 Started: [10:06:00] Best share: 1.946
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 72.0C 85% | 6.211M/6.092Mh/s | R: 0.0% HW:0 WU:0.084/m xI: 56
--------------------------------------------------------------------------------
GPU 0: 6.2 / 6.1 Mh/s | A:140 R:0 HW:0 U:8.81/m I:0 xI:56 rI:0
72.0 C F: 85% E: 1060 MHz M: 1500 Mhz V: 0.000V A: 100% P: 15%
Last initialised: [2014-07-25 09:47:48]
Thread 0: 3.1 Mh/s Enabled ALIVE
Thread 1: 3.1 Mh/s Enabled ALIVE
[E]nable [D]isable [R]estart GPU [C]hange settings
[I]ntensity E[x]perimental intensity R[a]w Intensity
Or press any other key to continue
No, it can be faster
Code:
sgminer 4.2.2 - Started: [2014-07-25 09:47:50] - [0 days 00:40:34]
--------------------------------------------------------------------------------
(5s):6.283M (avg):6.139Mh/s | A:3 R:0 HW:0 WU:0.087/m
ST: 0 SS: 0 NB: 90 LW: 3952 GF: 1 RF: 0
Connected to am02 x11 (stratum) diff 0.012 as user xxxx
Block: 683f926f... Diff:694 Started: [10:28:02] Best share: 1.946
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 73.0C 85% | 6.283M/6.145Mh/s | R: 0.0% HW:0 WU:0.087/m xI: 65
--------------------------------------------------------------------------------
GPU 0: 6.3 / 6.1 Mh/s | A:341 R:0 HW:0 U:8.81/m I:0 xI:65 rI:0
72.0 C F: 85% E: 1060 MHz M: 1500 Mhz V: 0.000V A: 100% P: 15%
Last initialised: [2014-07-25 09:47:48]
Thread 0: 3.1 Mh/s Enabled ALIVE
Thread 1: 3.1 Mh/s Enabled ALIVE
[E]nable [D]isable [R]estart GPU [C]hange settings
[I]ntensity E[x]perimental intensity R[a]w Intensity
Or press any other key to continue
edit
I notice a hashrate drop to below 6mh/s and rise back again with xI=65.
Drop to xI=64 (6274kh/s) and is not dropping anymore.(10kh/s or so)
Edit2
As u can see the Accepted shares are calculate fine in sgminer, but the above value isn't.
Is it hard to change the above value to the value sgminer is showing with "G".?
edit3
Still stable after 3 hours.
Restarted and see if the other algos also be stable...6.346kh/s
Code:
sgminer 4.2.2 - Started: [2014-07-25 12:33:01] - [0 days 00:19:21]
--------------------------------------------------------------------------------
(5s):6.346M (avg):6.312Mh/s | A:2 R:0 HW:0 WU:0.083/m
ST: 0 SS: 0 NB: 22 LW: 1825 GF: 1 RF: 0
Connected to am02 x11 multi (stratum) diff 0.014 as user xxxx
Block: 2ef3e81b... Diff:1.11K Started: [12:51:30] Best share: 1.397
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 74.0C 85% | 6.352M/6.326Mh/s | R: 0.6% HW:0 WU:0.083/m xI: 64
--------------------------------------------------------------------------------
GPU 0: 6.4 / 6.3 Mh/s | A:174 R:1 HW:0 U:10.30/m I:0 xI:64 rI:0
73.0 C F: 85% E: 1060 MHz M: 1500 Mhz V: 0.000V A: 100% P: 10%
Last initialised: [2014-07-25 12:33:00]
Thread 0: 3.2 Mh/s Enabled ALIVE
Thread 1: 3.2 Mh/s Enabled ALIVE
[E]nable [D]isable [R]estart GPU [C]hange settings
[I]ntensity E[x]perimental intensity R[a]w Intensity
Or press any other key to continue
July 25, 2014, 01:58:44 AM
I'm amazed we're still doing all this tweaking blindly with so much guesswork and trial and error. There's got to be a way to accurately and precisely measure what's possible/stable, based on the numbers alone.
Everybody's clocks have different tolerances. It'd be easier just to say stock clocks and unedited .cl files, but fuckit; gotta try and get that extra 200Kh/s. If you don't somebody else might.But why would they have different tolerances if they're built exactly the same? Are we talking differences in heat/humidity or something?
July 25, 2014, 12:49:23 AM
I'm amazed we're still doing all this tweaking blindly with so much guesswork and trial and error. There's got to be a way to accurately and precisely measure what's possible/stable, based on the numbers alone.
Everybody's clocks have different tolerances. It'd be easier just to say stock clocks and unedited .cl files, but fuckit; gotta try and get that extra 200Kh/s. If you don't somebody else might.But why would they have different tolerances if they're built exactly the same? Are we talking differences in heat/humidity or something?
July 25, 2014, 12:45:37 AM
I'm amazed we're still doing all this tweaking blindly with so much guesswork and trial and error. There's got to be a way to accurately and precisely measure what's possible/stable, based on the numbers alone.
Everybody's clocks have different tolerances. It'd be easier just to say stock clocks and unedited .cl files, but fuckit; gotta try and get that extra 200Kh/s. If you don't somebody else might. July 25, 2014, 12:30:00 AM
I'm amazed we're still doing all this tweaking blindly with so much guesswork and trial and error. There's got to be a way to accurately and precisely measure what's possible/stable, based on the numbers alone.
July 25, 2014, 12:17:38 AM
I've noticed some odd behavior and wanted to see if anyone else has spotted it or knows a solution. I'm mining X11.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
Wanted to share an update on this night's efforts. With engine/memory speeds at 1020/1350, raising xintensity to 66 or 68 (they are about even), takes my 290X's up to ~6.04 Mhash/s, but the "sine decay curve" as I've named it, keeps tanking them down around 10% as before. The upshot is I'm getting around 23.8 Mhash on average over time (5.95 per GPU). If I drop the xintensity to 50 the problem goes away but average hashrate is slightly lower. Messing with hamsci, going back to the default kernel and binary, and worksize changes all failed to help. I suppose maybe this is just how it is and I should be happy with it? After all I can just drop to x-50 and be content if it still bugs me.
Yep. Unless you know how to edit the hardcoded address space inside of darkcoin-mod.cl
hamsi isn't a part of the x11 algorithm, it's only in x13/x14/x15, so your hamsi changes aren't relevant.
Your x11 hashrate will be dependent mostly on memclock speed, if you can hold at 1350, great, I can't though. I think badman74 can hold his up at 1500, not sure on the wattage draw for that though.
I've found that bullus' bin works the best on my standard 290X but it shits all over my 290X Tri-OC's, I don't think it was built for that BIOS version.
worksize 64 rI 140800 (= xI: 50) is okay; I don't think ratcheting up xI to 66 is going to average out as any better over 24hours.
Thanks for the pointers. Yes, I got the best results with bullus' bin file but the regular kernel file. I am running now at xI-68, still seeing each GPU tapering off 10% and then recovering, but one of them is getting over 6.1 Mhash between the tapering and others also top out over 6.0. Nudging up the engine speed from 1020 to 1025 causes almost immediate crashes, but 1020 is stable so I'm sticking right there. I'm going to let it run overnight like this and see how it averages out.
July 25, 2014, 12:02:00 AM
https://bitcointalksearch.org/topic/ann-sgminer-v5-optimized-x11x13neoscryptlyra2reetc-kernel-switch-miner-632503
Pretty simple and plain for 290X with hashrates.
Pretty simple and plain for 290X with hashrates.
Honestly man, I haven't been able to get close to this. I've applied all your settings. I max out at 5.4MH with X11, but I have to throttle back because the same clocks on X15 give me dead cards. My stable settings are 1030/1300 for all three X algos, and I hit 5.2MH for X11 and 3.2MH for X15. This is for two Sapphire R9 290x BF4 editions, one with Hynix and one with Elpida. I'm using the 7/20 daily build, and driver 14.4 + the 14.6 CLs. (multidriver trick) I guess maybe the problem is I'm not using 14.7, but I was under the impression they yield the same performance.
Try my darkcoin bin , I get ~6mh/s so does others
https://bitcointalksearch.org/topic/m.7883228
I went ahead and updated to 14.7, and now I'm getting 5.9MH with my own bins. So let the record show that using the 14.4+14.6 multidriver trick does not work as well as 14.7. Using sgminer daily build 7/20.
Code:
-------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 77.0C 56% | 5.903M/5.860Mh/s | R: 0.0% HW:0 WU:0.107/m rI:21
GPU 1: 78.0C 65% | 5.894M/5.874Mh/s | R: 0.0% HW:0 WU:0.033/m rI:21
-------------------------------------------------------------------------
5.9 is fine with me. I'm leaving town for 4 weeks, so I need this to be safe and stable anyway.
My settings, a little different than yours (higher diff, lower clocks):
Code:
{
"pools" : [
{
"name" : "NiceHash_X11_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4336",
"user" : "x",
"pass" :
"d=0.08;f0=0;f2=0;f3=5.5;f4=4;f5=0;f6=3.5;f7=0",
"profile" : "x11"
},
{
"name" : "NiceHash_X13_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4337",
"user" : "x",
"pass" :
"d=0.08;f0=0;f2=0;f3=5.5;f4=4;f5=0;f6=3.5;f7=0",
"profile" : "x13"
},
{
"name" : "NiceHash_X15_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4339",
"user" : "x",
"pass" :
"d=0.08;f0=0;f2=0;f3=5.5;f4=4;f5=0;f6=3.5;f7=0",
"profile" : "x15"
},
{
"name" : "NiceHash_X11_BACKUP",
"url" : "stratum+tcp://stratum.nicehash.com:3336",
"user" : "x",
"pass" : "d=0.08",
"profile" : "x11"
}
],
"profiles" : [
{
"name" : "x11",
"algorithm" : "darkcoin-mod",
"worksize" : "64",
"gpu-engine" : "1030-1030",
"gpu-memclock" : "1300-1300"
},
{
"name" : "x13",
"algorithm" : "marucoin-mod",
"worksize" : "64",
"gpu-engine" : "1030-1030",
"gpu-memclock" : "1300-1300"
},
{
"name" : "x15",
"algorithm" : "bitblock",
"worksize" : "64",
"gpu-engine" : "1030-1030",
"gpu-memclock" : "1300-1300"
}
],
"vectors" : "1",
"rawintensity" : "211200",
"shaders" : "2816",
"gpu-threads" : "2",
"gpu-fan" : "0-95",
"gpu-powertune" : "20",
"temp-cutoff" : "99",
"temp-overheat" : "85",
"temp-target" : "80",
"auto-fan" : true,
"auto-gpu" : true,
"log" : "5",
"log-dateformat" : "1",
"failover-only" : true,
"failover-switch-delay" : "300",
"no-pool-disable" : true,
"no-submit-stale" : true,
"scrypt" : true,
"queue" : "1",
"scan-time" : "7",
"expiry" : "28",
"api-listen" : true,
"api-mcast-port" : "4028",
"api-port" : "4001",
"api-allow" : "W:127.0.0.1"
}
July 24, 2014, 11:54:49 PM
I've noticed some odd behavior and wanted to see if anyone else has spotted it or knows a solution. I'm mining X11.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
Wanted to share an update on this night's efforts. With engine/memory speeds at 1020/1350, raising xintensity to 66 or 68 (they are about even), takes my 290X's up to ~6.04 Mhash/s, but the "sine decay curve" as I've named it, keeps tanking them down around 10% as before. The upshot is I'm getting around 23.8 Mhash on average over time (5.95 per GPU). If I drop the xintensity to 50 the problem goes away but average hashrate is slightly lower. Messing with hamsci, going back to the default kernel and binary, and worksize changes all failed to help. I suppose maybe this is just how it is and I should be happy with it? After all I can just drop to x-50 and be content if it still bugs me.
Yep. Unless you know how to edit the hardcoded address space inside of darkcoin-mod.cl
hamsi isn't a part of the x11 algorithm, it's only in x13/x14/x15, so your hamsi changes aren't relevant.
Your x11 hashrate will be dependent mostly on memclock speed, if you can hold at 1350, great, I can't though. I think badman74 can hold his up at 1500, not sure on the wattage draw for that though.
I've found that bullus' bin works the best on my standard 290X but it shits all over my 290X Tri-OC's, I don't think it was built for that BIOS version.
worksize 64 rI 140800 (= xI: 50) is okay; I don't think ratcheting up xI to 66 is going to average out as any better over 24hours.
July 24, 2014, 11:31:44 PM
I've noticed some odd behavior and wanted to see if anyone else has spotted it or knows a solution. I'm mining X11.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
Wanted to share an update on this night's efforts. With engine/memory speeds at 1020/1350, raising xintensity to 66 or 68 (they are about even), takes my 290X's up to ~6.04 Mhash/s, but the "sine decay curve" as I've named it, keeps tanking them down around 10% as before. The upshot is I'm getting around 23.8 Mhash on average over time (5.95 per GPU). If I drop the xintensity to 50 the problem goes away but average hashrate is slightly lower. Messing with hamsci, going back to the default kernel and binary, and worksize changes all failed to help. I suppose maybe this is just how it is and I should be happy with it? After all I can just drop to x-50 and be content if it still bugs me.
July 24, 2014, 05:38:56 PM
Help me, please, to avoid HUGE amount of info in log file.
my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
how long are you talking about...my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
5 days on mine gave a 35mb file with "log-file" : "logfile.txt", "log" : "5", and "log-show-date" : true,
maybe try --log-show-date --log-file log.txt --log 5
or -L -l 5 --log-file log.txt
July 24, 2014, 04:47:49 PM
Help me, please, to avoid HUGE amount of info in log file.
my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
--debug-log Enable debug logging when stderr is redirected to file
this? Looks like it is enabled by default.
nope..
July 24, 2014, 02:44:11 PM
Help me, please, to avoid HUGE amount of info in log file.
my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
--quiet|-q Disable logging output, display status and errors
--log|-l
July 24, 2014, 02:35:37 PM
Help me, please, to avoid HUGE amount of info in log file.
my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
my sgminer starts in this way:
sgminer.exe -c qvs_as.conf --api-listen 2>>log.txt
Last versions of sgminer produce about 240MB of log file.
Early versions of sgminer did produce much smaller logs.
I'm not need so many info.
I want only know when sgminer starts, why sgminer suddenly closes, when GPU become SICK or DEAD, and also events of pools switching, share accepting/regecting.
How can I do it?
July 24, 2014, 01:38:42 PM
I've noticed some odd behavior and wanted to see if anyone else has spotted it or knows a solution. I'm mining X11.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
I finally got around to upgrading to AMD CCC 14.7/CGWatcher 1.4.1/SGMiner 5 last night, from 14.6, CGWatch 1.3.8 and SGMiner 4.1. I'm running 4 AMD R9 290X's (3 Sapphire, not the tri-x, and one reference 290X), on Win7-64bit.
On my prior setup I was maxing out just over 5.6 Mhash/GPU (22.4 Mhash total). So I tried following Platinum's advice on this thread in hopes of breaching 6 Mhash/GPU. However I got sick GPU's pretty quickly at 1040, then 1030 and 1025 on Engine speed. It stabilized at 1020, with the GPU's generally hitting over 5.9 Mhash and sometimes touching 6.0. (My tweaking also cut Memory speed to 1250, but bumped Xintensity to 64 rather than 50.)
This setup is giving me 23.72 Mhash, or 5.93 Mhash/GPU which is pretty good. But what's curious is that as I was watching the speeds of each GPU, I would notice one after another GPU's speed tanking about 10% (down to around 5.4 Mhash) over maybe 30 seconds. It lingers there a bit, then slowly climbs back up and runs just shy of 6.0 again (Right around 5.98 Mhash/s). Sometimes 2 GPU's would be at differing points in this cycle, which just seems to appear randomly but persistently while running in an otherwise stable manner.
Anyone have any ideas what's up? I was going to try changing HAMSCI from 7 to 1 based on a dim recollection of something I ran across, but other ideas would be appreciated. If I solve it I'll post here.
EDIT: I should also mention I replaced the default darkcoin kernel with another mentioned here (I think by bulllus), and the corresponding binary. I will switch back to the defaults with those to see what effect they have.
Jump to: