|
phzi
|
 |
July 23, 2014, 08:25:07 PM |
|
<snip>
Any help that anyone can provide would be greatly appreciated. I've tried numerous changes to the config file with no improvements. I'm not really sure what is going on in the log file to help me understand the problem.
I think you need to read a few other people's configs... the pool-* options should be removed/replaced with profiles. |
|
|
|
|
|
|
|
|
|
|
|
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
ozzy1926
|
|
July 23, 2014, 09:13:04 PM |
|
This thread is a bit of a mess - very difficult to read and make sense of the numbers posted. It would be helpful if people posted - simply at the top of their post: CARD: MODEL (280x, 290x, 7990) DRIVER VERSION (14.6) ALGO: (X11, X13)Many of the numbers posted - theres no algo. Or no card. Or neither. You have to go back and try to piece together conversations to try to make sense of it. Just my two cents - obviously we are all here to help one another out. I'll post some numbers for people to review next... Strato  That's because this was a developer's thread that unfortunately has now devolved into a "can u post work .bat file" thread, and people don't go back and read. https://bitcointalk.org/index.php?topic=632503.msg7936506#msg7936506Pretty simple and plain for 290X with hashrates. whats your earning daily with 3x 290x? |
|
|
|
|
|
badman74
|
|
July 23, 2014, 09:14:42 PM |
|
Graphic cards (MSI 280, Sapphire 290 Tri X)
Catalyst Driver 14.4
Win7 x64 i7 920 and 6GB ram
Algos: X11, X13 X15, NIST, Keccak
My situation is I am trying to find the optimal conf for each algo by running sgminer 5 with a static algo port at NiceHash. Once I find the optimal settings, I will then build out the full conf file using the multi-algo ports. The problem is I can't get my system to run on any version later than sgminer-5.0-pre-release-2014-06-11-win32. Any of the later versions cause rejects with share above target errors and the log file indicates invalid nonce - HW error.
I'm currently running with X11 on the sgminer-5.0-pre-release-1-win32 version and I'm able to get both cards to run 24+ hours at max TC and intensity 19. When testing with more recent versions of sgminer 5, I set the TC to a minimal value and intensity 8, and I get the reject errors.
Once I find a working setup, I'll split some of the config entries into a profile to make it easier to manage, but for now I need to keep everything together since this is an earlier version of sgminer that doesn't support profiles.
well first, TC is ONLY used in scrypt/nscrypt as of sgminer5 (never saw a difference in non-scrypt algos before this anyway) second remove all pool- references as it just uses the normal references in the pool and profiles as in the main body of the profile so it would look like this {
"pools" : [
{
"name" : "NiceHash_X11",
"url" : "stratum+tcp://stratum.nicehash.com:3336",
"user" : "my bitcoin address here",
"pass" : "d=0.01",
"algorithm" : "darkcoin-mod",
"intensity" : "8,8",
"gpu-fan" : "38,43",
"gpu-memclock" : "1500,1000",
"gpu-engine" : "1030,933"
}
],
"gpu-threads" : "2",
"worksize" : "256,256",
"lookup-gap" : "2",
"gpu-powertune" : "20",
"queue" : "0",
"scan-time" : "1",
"expiry" : "1",
"failover-only" : true,
"failover-switch-delay" : "30"
}
also nfactor only needs specified if it is something other than 10 please read though the new readme.md, news.md, and /doc/configuration.md also look at example.conf if they are not in your download try the link in my sig |
|
|
|
|
|
iwhoss
|
|
July 24, 2014, 02:10:50 AM |
|
Is this fast ?
|
|
|
|
yotadrivers
Member
 Offline
Activity: 114
Merit: 10
|
|
July 24, 2014, 07:35:35 AM |
|
i can't find windows binaries of sgminer5 in main post.. please help me
|
|
|
|
|
|
phzi
|
|
July 24, 2014, 07:54:15 AM |
|
Is this fast ?
This is a horrible question... if you want a non-horrible response, please try again. i can't find windows binaries of sgminer5 in main post.. please help me
CTRL-F> Binaries, maybe? (or just glance at the bolded headings?) And nightlies are available here: https://nicehash.com/software/nightly/ |
|
|
|
|
|
platinum4
|
|
July 24, 2014, 10:40:13 AM |
|
Is this fast ?
Is this slow ? |
|
|
|
|
crnjak021
Newbie
Offline
Activity: 1
Merit: 0
|
|
July 24, 2014, 10:47:12 AM |
|
I need help
over a month I have trouble with starting x13 on my 5970 and 6970 cards... only recive HW error
can anyone succesufully start x13 on this cards? IF yes please post some config for sgminer.
|
|
|
|
|
ebliever
Legendary
Offline
Activity: 1708
Merit: 1035
|
|
July 24, 2014, 06: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.
|
Luke 12:15-21
Ephesians 2:8-9
|
|
|
rldep
Newbie
Offline
Activity: 9
Merit: 0
|
|
July 24, 2014, 07: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?
|
|
|
|
|
|
CryptoBomg
|
|
July 24, 2014, 07: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?
--quiet|-q Disable logging output, display status and errors --log|-l <arg> Interval in seconds between log output (default: 5) |
|
|
|
|
|
lbr
|
|
July 24, 2014, 09: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?
maybe
--debug-log Enable debug logging when stderr is redirected to file
this? Looks like it is enabled by default.nope.. |
|
|
|
|
badman74
|
|
July 24, 2014, 10:38:56 PM
Last edit: July 24, 2014, 11:56:27 PM by badman74 |
|
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... 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 |
|
|
|
|
ebliever
Legendary
Offline
Activity: 1708
Merit: 1035
|
|
July 25, 2014, 04:31:44 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.
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. |
Luke 12:15-21
Ephesians 2:8-9
|
|
|
|
platinum4
|
|
July 25, 2014, 04:54:49 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.
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. |
|
|
|
|
KiloWatts
Member
Offline
Activity: 119
Merit: 10
|
|
July 25, 2014, 05:02:00 AM
Last edit: July 25, 2014, 05:15:27 AM by KiloWatts |
|
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://bitcointalk.org/index.php?topic=632503.msg7883228#msg7883228I 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. -------------------------------------------------------------------------
[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): {
"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"
}
|
|
|
|
|
ebliever
Legendary
Offline
Activity: 1708
Merit: 1035
|
|
July 25, 2014, 05: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.
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. |
Luke 12:15-21
Ephesians 2:8-9
|
|
|
KiloWatts
Member
Offline
Activity: 119
Merit: 10
|
|
July 25, 2014, 05: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.
|
|
|
|
|
|
platinum4
|
|
July 25, 2014, 05: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. |
|
|
|
|
KiloWatts
Member
Offline
Activity: 119
Merit: 10
|
|
July 25, 2014, 05: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? |
|
|
|
|
|
