Bitcoin Forum
December 16, 2017, 01:56:07 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Now trouble setting up my HD7850 GPU w/ SGminer (EDIT: was BFGminer)  (Read 3102 times)
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 05, 2014, 05:10:27 AM
 #1

Just downloaded the latest BFGminer -- 4.8.0 -- and am trying to run it with Hamster's Scrypt pool.  Yes, I know GPU isn't a great solution anymore, but it's what I have and I want to get my feet wet.  My problem is I can't get any hashing done, though frequencies are reported and seems thread 0 (of two) is being shut down since the GPU also provides normal screen output.  The video card is an AMD HD7850 1GB that works fine mining BTC (SHA256) with GUIminer (definitely can't compete these days, ~170MH/s).

I'm starting BFGminer from a batch file and the contents is as follows:

Code:
@echo off
echo loading GPU scrypt miner
bfgminer.exe -S auto -o stratum+tcp://eu.hamsterpool.com:7771 -u <worker> -p <password>

On the surface it seems to come up OK, detecting the GPU and reporting frequencies (though much lower than the actual configuration), but the only messages appearing in the command window are announcements that another block has been found and network difficulty has changed.  No acceptances, no rejects, no nothing that suggests work is being done.  Also, the GPU fan doesn't spin up -- sure did with GUIminer and BTC.

So, I know some people are still using GPU Scrypt processing, how do I get this thing running?

Thanks in advance Smiley!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513432567
Hero Member
*
Offline Offline

Posts: 1513432567

View Profile Personal Message (Offline)

Ignore
1513432567
Reply with quote  #2

1513432567
Report to moderator
1513432567
Hero Member
*
Offline Offline

Posts: 1513432567

View Profile Personal Message (Offline)

Ignore
1513432567
Reply with quote  #2

1513432567
Report to moderator
nwoolls
Hero Member
*****
Offline Offline

Activity: 798


View Profile WWW
October 05, 2014, 06:52:18 AM
 #2

You need to pass in the --scrypt argument when connecting to Scrypt pools.

MultiMiner: Any Miner, Any Where, on Any Device |  MobileMiner: Monitor and manage your rigs from your browser or phone  |  Xgminer: Mine with popular miners on Mac OS X
btc: 1BmXY4ZZQh1iHSVre658gM1gPAEtDnq8rv  |  ltc: LP1SsHZTDexndkvRKsqAkXNsienPHwaMb5  |  hardware: nwoolls at gmail dot com
MaxDZ8
Hero Member
*****
Offline Offline

Activity: 673



View Profile
October 05, 2014, 07:15:03 AM
 #3

Maybe it's going on the integrated VGA?
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 05, 2014, 08:04:55 AM
 #4

You need to pass in the --scrypt argument when connecting to Scrypt pools.
Thanks, just retried that:

Code:
@echo off
echo loading GPU scrypt miner
bfgminer.exe --scrypt -S auto -o stratum+tcp://eu.hamsterpool.com:7771 -u <worker> -p <password>

... unfortunately, the result is that BFGminer self-aborts with an error message window saying it stopped running (same problem version 4.4.0) I'm guessing something else must be amiss!

Maybe it's going on the integrated VGA?
I'm guessing you're referring to the AMD APU series -- I've one of those on another PC running BFGminer 4.4.0 with a collection of USB miners Smiley!
No, this PC is running an AMD FX3250 CPU, no integrated video.  The only video capability is the HD7850 1GB card.

Other thoughts anybody?

PS. Should mention I have the AMD-APP-SDK-V2.9 installed on the Win7 Ultimate 64bit OS.
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 05, 2014, 10:15:39 AM
 #5

Hey people! What am I missing!  I need to get this thing working!  Using GPU for crypto-currency processing goes back years (2008?).  Why should my situation be an exception?  All I'm trying to do is hash Script with my AMD HD7850 video card -- is that really space science?  What is it I'm missing?
MaxDZ8
Hero Member
*****
Offline Offline

Activity: 673



View Profile
October 05, 2014, 12:42:58 PM
 #6

Have you tried sgminer? I see bfgminer includes .cl kernels but I also see it focuses on FPGA/ASIC. Maybe it does not support GPU anymore? I recall using it... about 10 months ago.
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 05, 2014, 09:46:29 PM
 #7

Have you tried sgminer? I see bfgminer includes .cl kernels but I also see it focuses on FPGA/ASIC. Maybe it does not support GPU anymore? I recall using it... about 10 months ago.
Thanks for the sgminer suggestion -- something else to learn about Smiley!  Introduced me to the NiceHash website.  Now, if I can just find batch file documentation...
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 06, 2014, 01:37:39 AM
 #8

OK, got sph-sgminer-4.1.0 running and I've set the GPU clock to 1GHz (DRAM default is 1.2GHz) and I'm seeing a GPU temp of ~74C, but the production is only ~16 KH/s for my HD7850 1GB (had ~170MH/s on SHA250 GUIminer).  Recognizing I'm a complete newbie to Scrypt, does that Hash rate look right to you guys?
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 06, 2014, 03:00:42 AM
 #9

OK, got sph-sgminer-4.1.0 running and I've set the GPU clock to 1GHz (DRAM default is 1.2GHz) and I'm seeing a GPU temp of ~74C, but the production is only ~16 KH/s for my HD7850 1GB (had ~170MH/s on SHA250 GUIminer).  Recognizing I'm a complete newbie to Scrypt, does that Hash rate look right to you guys?
Judging by this chart:

https://litecoin.info/Mining_hardware_comparison

An HD7850 should be in the neighborhood of 350KH/s, any ideas as to what's going on with my setup?  At 16KH/s it seems apparent I'm being robbed blind! Sad

=================================A LITTLE LATER==============================

Appears the Intensity parameter was set too low (I'd defaulted it).  Raised it to 11 and the GPU took off.  Bumped it to 15 and further adjusted (+/-) from there.  Seems not only have to watch Temp, but also HW and Rejects.  Am now looking for a happy point where HW is infrequent, R is minimal, and Hash rate is as high as available.  Still, it's now finally Hashing -- too bad I can only use one of the two GPU threads (cuts H/s in half), but there are also video responsibilities.

Looking as though the SGminer suggestion is my solution -- thanks!

PS. Would really like to find documentation on how to enter the parameterrs into the batch file -- entering them manually is fine for experiment, but not for long term.
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 06, 2014, 05:26:05 AM
 #10

Well, Hamsterpool still only reports a 64KH/s rate, so it's not clear I'm out of the woods yet.  SGminer reports 291/164 KH/s, a lot higher (the second SGminer number is very gradually rising)!  Sad

===============================SOME TIME LATER===============================

SGminer reports 290/200 KH/s, yet Hamsterpool reports just 56KH/s.  Would really appreciate it if someone could explain how this makes sense.  I see plenty of messages and they include sequential Difficulty increases finally resulting in a work reset.  Is the problem that communications are screwed up?  The Hash capacity is there, but it's just not being effectively utilized by the pool and SGminer?  Why do I see all the difficulty hikes?  More hikes than acceptances when they cut in.  Something seems screwed up!
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 06, 2014, 08:12:46 PM
 #11

Well, Hamsterpool still only reports a 64KH/s rate, so it's not clear I'm out of the woods yet.  SGminer reports 291/164 KH/s, a lot higher (the second SGminer number is very gradually rising)!  Sad

===============================SOME TIME LATER===============================

SGminer reports 290/200 KH/s, yet Hamsterpool reports just 56KH/s.  Would really appreciate it if someone could explain how this makes sense.  I see plenty of messages and they include sequential Difficulty increases finally resulting in a work reset.  Is the problem that communications are screwed up?  The Hash capacity is there, but it's just not being effectively utilized by the pool and SGminer?  Why do I see all the difficulty hikes?  More hikes than acceptances when they cut in.  Something seems screwed up!

==================================NEXT DAY===============================

SGminer reports 291/273 KH/s, but Hamsterpool only reports 71-78 KH/s.  Anybody have any idea what's going on with this?

===================================LATER=================================

It's warmer today and noticed the GPU Temp had climbed to 78C. Lowered the Intensity two notches and it's now back to 75C and the clock numbers went to 262/272 KH/s.  Checked Hamsterpool and it now reports 193KH/s, so appears I had the Intensity setting too high.  Tried one more setting down and the card fell on its face so it appears Intensity has to be set just high enough, but no higher.
FeelTheBeat
Hero Member
*****
Offline Offline

Activity: 560


Blocklancer - Freelance on the Blockchain


View Profile
October 06, 2014, 09:58:17 PM
 #12

Did you have any hardware error with intensity set too high? This could be cause of low hash reported by Hamsterpool.
Anyway you must always first run with default clocks and only adjusting thread concurrency and intensity. When this is stable (no HW errors) then you start finetuning memory and core clocks.

nsimmons
Sr. Member
****
Offline Offline

Activity: 308


View Profile
October 07, 2014, 04:20:15 AM
 #13

my moneys on hardware errors, your thread concurrency is too low for the intensity. I dont know the shaders for a 7850, set threads to something like 12000 maybe???

Run the highest thread concurrency possible without sgminer complaining, if the number is too high, it will bitch about gpu ram and exit. keep lowering the number until it runs, then set the intensity to 20. fiddle from there.

make sure this has been run once on the system from the command prompt, just run it one time.
"setx gpu_max_alloc_percent 100"

TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 08, 2014, 06:23:31 AM
 #14

Did you have any hardware error with intensity set too high? This could be cause of low hash reported by Hamsterpool.
Anyway you must always first run with default clocks and only adjusting thread concurrency and intensity. When this is stable (no HW errors) then you start finetuning memory and core clocks.
my moneys on hardware errors, your thread concurrency is too low for the intensity. I don't know the shaders for a 7850, some thing like 12000 maybe???

Run the highest thread concurrency possible without sgminer complaining, if the number is too high, it will bitch about gpu ram and exit. keep lowering the number until it runs, then set the intensity to 20. fiddle from there.

make sure this has been run once on the system from the command prompt, just run it one time.
"setx gpu_max_alloc_percent 100"
Wish I understood the batch file language, haven't found documentation yet.  Shader count is 1024, am looking at possibility of HD 7970 and 2048 for next Scrypt PC effort.  Am most definitely seeing hardware errors, but if I calculate HW/(HW+Difficulty) (correct calculation?), it seems reasonable.  Rejection rate is very low.  Typical current Hamster report is now ~250-300KH/s.
I can try fooling with it some more tomorrow, but seems pretty stable at the moment -- results seeming workable.  Have to keep in mind the card has to take care of video duties as well, not entirely free to Hash.

No, I didn't run with default 860KHz GPU clock since I previously concluded 1GHz worked fine for gaming benchmarks -- perhaps a mistaken approach?  I did try rolling back to default 860MHz, but it didn't appear to have much (if any) impact on HW.  Not yet familiar with term "Thread Concurrency", or for how to set batch file parameters for that matter Sad!  Still a total Newbie here I'm afraid Sad!
nsimmons
Sr. Member
****
Offline Offline

Activity: 308


View Profile
October 08, 2014, 09:01:05 PM
 #15

You should get no hardware errors when setup properly.

make a file called scrypt.conf in the same folder and put this in it, make sure you set your pool info.

Quote
{
"pools" : [
        {
                  "url" : "stratum+tcp://stratum.pool.url:port",
                  "user" : "user.worker1",
                  "pass" : "x"
        }
]
,
"intensity" : "20",
"worksize" : "256",
"kernel" : "scrypt",
"lookup-gap" : "2",
"thread-concurrency" : "16384",
"gpu-threads" : "1",
"gpu-fan" : "0-100",
"temp-cutoff" : "95",
"temp-overheat" : "90",
"temp-target" : "80",
"api-mcast-port" : "4028",
"api-port" : "4028",
"auto-fan" : true,
"expiry" : "28",
"failover-only" : true,
"failover-switch-delay" : "60",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "7",
"tcp-keepalive" : "30",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

then from the cmd prompt run
Quote
sgminer -c scrypt.conf

it should mine fine then, if there's no typos, if it complains about ram trying decreasing the thread concurrency by 1000 at a time.

I originally mined btc with gpus, it was easy to setup cgminer, when i switched to scrypt it took me 2 weeks screwing with things until i figure it out, now its simple. x11 is more forgiving.

MaxDZ8
Hero Member
*****
Offline Offline

Activity: 673



View Profile
October 09, 2014, 11:26:08 AM
 #16

Actually decreasing thread concurrency is more likely to cause HW rather than solve them.
The thread concurrency setting does not do what you think it does. A better name would be "size of the concurrent thread scrypt scratchpad buffer".

I strongly suggest to keep the thread concurrency parameter as high as possible: 2x the total shader count worked for me. Lower numbers increase the chance threads smash each other. At thread concurrency == shader count the risk of hardware errors is close to 100%.

7970 has 32 clusters. This means it will keep in flight 32*256=8192 threads at the same "tick".
nsimmons
Sr. Member
****
Offline Offline

Activity: 308


View Profile
October 09, 2014, 07:36:52 PM
 #17

Actually decreasing thread concurrency is more likely to cause HW rather than solve them.
The thread concurrency setting does not do what you think it does. A better name would be "size of the concurrent thread scrypt scratchpad buffer".

I strongly suggest to keep the thread concurrency parameter as high as possible: 2x the total shader count worked for me. Lower numbers increase the chance threads smash each other. At thread concurrency == shader count the risk of hardware errors is close to 100%.

7970 has 32 clusters. This means it will keep in flight 32*256=8192 threads at the same "tick".

You didn't read my post, i said "if it complains about ram trying decreasing the thread concurrency by 1000 at a time."

If it complains, the thread concurrency is too large for the gpu ram. I can't tell him the exact concurrency to use because I have no experience with a 7850. I can tell him I run 6400 for my 6950, 24000 for my 280xs and 32765 for my 290s, but this doesn't help him.

I suggested 16384 for him because i found this number online, it is many times larger than the shader count.

You are just confusing him.

2x the shader count for a 290 is only 5120, ridiculously low, even with 2 threads.

To the op, if you double the gpu threads you halve the concurrency. example,
gpu thread = 1
thread-concurrency=16000

gpu thread = 2
thread-concurrency=8192


MaxDZ8
Hero Member
*****
Offline Offline

Activity: 673



View Profile
October 10, 2014, 11:05:10 AM
 #18

You didn't read my post, i said "if it complains about ram trying decreasing the thread concurrency by 1000 at a time."
I apologize. It was not clear to me from the wording.

Quote
2x the shader count for a 290 is only 5120, ridiculously low, even with 2 threads.
No, the old outdated documentation is confusing people. There's no such thing as "shaders" in AMD GCN, the numer you are referring to is probably the "total number of concurrent work items in flight", which is a multiple of the hardware concurrency. I admit the wording could have been better.

If memory serves 290 has 44 CU so that would be 11264 to me. Besides, as I said the number of threads in flight at the same tick for 7970 has 32 CU and it already keeps in flight (at the same tick) more work items than your computations suggest.
No idea what "shader count" is supposed to mean I admit, the concept is largely obsolete and last time I checked sgminer didn't use it. Is it the SIMD lane count? Concurrenty per clock? Per timeslice? Scheduler limit? Please explain how you obtained that number.
Please explain me the connection to "threads" as well.

Reference: AMD APP, Appendix D "processing elements".
TrevorS
Sr. Member
****
Offline Offline

Activity: 307


View Profile
October 12, 2014, 10:17:20 PM
 #19

Thanks guys Smiley!

Well, in some ways things have improved and everything looks great, except that all three of A/R/HW are holding at zero.  Here's a rundown:

I've manually entered the following two lines via the command window (tried the .bat file, but they didn't take).
Code:
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1

Worked back and forth a few times between the "sgminer.conf" file my copy of SGminer emits and the provided example (thanks nsimmons Smiley) and ended up with the following that everything seems happy with.  I shaved the suggested concurrency value by 1024 per shot to reach the shown SGminer accepted value.
Code:
<sgminer.conf>
{
"pools" : [
{
"url" : "stratum+tcp://eu.hamsterpool.com:7771",
"user" : "name.name",
"pass" : "pw"
}
],
"intensity" : "12",
"xintensity" : "0",
"rawintensity" : "0",
"worksize" : "256",
"kernel" : "ckolivas",
"lookup-gap" : "0",
"thread-concurrency" : "8192",
"shaders" : "0",
"gpu-threads" : "1",
"gpu-engine" : "860-930",
"gpu-fan" : "0-100",
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "90",
"temp-overheat" : "85",
"temp-target" : "75",
"api-mcast-port" : "4028",
"api-port" : "4028",
"expiry" : "28",
"failover-switch-delay" : "60",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "7",
"tcp-keepalive" : "30",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/i586-mingw32msvc/bin"
}

The GPU and fan come quickly up to speed and the reported hash rates are just fine, there's just the problem of no work being done (get network and pool messages, but no acceptances/rejections)! Hope something hasn't gone south with the card, but if it has, wouldn't SGminer indicate something? With SGminer sidelined I tried running the "Heaven" gaming benchmark and all appeared normal (image quality and fps), so it's not clear what's going on.

PS. On the shader question, I notice this version of SGminer does accept a "shaders" parameter, I defaulted it.  The card specs specify 1024.

PPS. The values shown in the SGminer window after some 20 minutes are:
Code:
-----------------------------------------------------------------------------
<5s>:257.1K <avg>:254.8Kh/s | A:0  R:0  HW:0  WU:251.233 (ever changing value)
ST: 2  SS: 0  NB: 32  LW: 781  GF:  0  RF: 0
Connected to Pool 0 <stratum> diff 16.3K as user <user.user>
Block 4e2d97ae...  Diff:1.84M  Started: [18:58:36]  Best share: 2.88K
------------------------------------------------------------------------------
[P]ool management (etc across this line)
GPU 0:  81.0C 3217RPM | 254.3K/254.3Kh/s  | R: 0.0% HW:0 WU:292.641/m I:12
------------------------------------------------------------------------------

The only messages I'm seeing are block detections and difficulty changes.
nsimmons
Sr. Member
****
Offline Offline

Activity: 308


View Profile
October 13, 2014, 05:12:19 AM
 #20

You're not finding any shares, you need hundreds of megahash to effectively mine scrypt. Your intensity is too low, 12 is basically off idle. turn it up to at least 18.  The hash rate is pitiful, my ancient 5770 is hashing faster than that right now. Increase your intensity until you get hw errors, if you cant reach 20, increase thread concurrency a bit, but 8192 probably fine, i would guess it'll run at intensity 20

I doubt you'll find any shares because the pool will move to a new block before you ever find one. You need a long block time scrypt coin and maybe you'll find a share in time. I've never used hamster pool.

Honestly change the kernel to x11 and point it at wafflepool just to make sure its all working..here's a config from one of my rigs.

5x290's, i've removed some pool details. This rig gets about 4.4mhs scrypt, 24mhs x11. I've got one funky card that runs hot and it need lower intensity, 18, probably needs new thermal compound.

Quote
{
"pools" : [
   
{
      "url" : "",
      "user" : "",
      "pass" : "x"
   },
{
      "url" : "stratum+tcp://uswest.wafflepool.com:3331",
      "user" : "",
      "pass" : ""
   },
   {
      "url" : "stratum+tcp://asia1.darkcoin.miningpoolhub.com:20465",
      "user" : "",
      "pass" : ""
   },
   {
      "url" : "stratum+tcp://europe1.darkcoin.miningpoolhub.com:20465",
      "user" : "",
      "pass" : ""
   }

],
"kernel" : "x11mod",
"thread-concurrency" : "32765,32765,32765,32765,32765",
"worksize" : "256,256,256,256,256",
"lookup-gap" : "2",
"intensity" : "20,20,20,18,20",
"gpu-fan" : "0-100,0-100,0-100,0-100,0-100",
"gpu-powertune" : "0,0,0,0,0",
"temp-cutoff" : "95,95,95,95,95",
"temp-overheat" : "90,90,90,90,90",
"temp-target" : "80,80,80,80,80",
"auto-fan" : true,
"no-submit-stale" : true,
"expiry" : "1",
"failover-only" : true,
"gpu-threads" : "1",
"log" : "5",
"queue" : "0",
"scan-time" : "1",
"temp-hysteresis" : "3",

"kernel-path" : "/usr/local/bin"
}


Pages: [1] 2 »  All
  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!