Topic: Now trouble setting up my HD7850 GPU w/ SGminer (EDIT: was BFGminer) (Read 3259 times)

That all sounds good, I suspect you've figured it out the 'art' of scrypt mining. If you do get more gpus switch to x11, you wont even break even with scrypt anymore. Plus it runs way cooler. I think i'd be mining at a 20 dollar a day loss with scrypt.

The fan's running at 100%.  I just lifted the intensity back to 15 like when I first got SGminer mining.  The hash went to ~300KH/s with a temp of 81C.  I tried pushing it to 17 which reached ~320KH/s and 83C.  Think my old 15 number is the better choice for me.  The upstairs room is pretty warm thanks to a bevy of SHA-256 miners downstairs.  The window's wide open plus there are windows open downstairs, but it translates into a warm ambient.

This PC wasn't actually intended as a miner, it's one I use for video rendering/burning and media serving and occasional game fooling around -- has an AMD FX8350, very large disc capacity, and restricted GPU fan air flow -- not a good box for mining.  Goal was to see if I could get Scrypt mining running and if it made sense to setup a PC specifically for it.  If it seems to work out, then I can throw together another machine from available parts including a dual fan HD7850 and a main board with three card slots and normal air flow.  Guess I'll ultimately be trying to compare the value of buying a couple more used video cards Vs buying dedicated scrypt miners (Gridseed?)  No, my electricity is definitely not free !

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

Had to drop intensity to 14 due to  low pool reported KH/s rate.  Also saw an unpleasant SGminer "R"eject rate.  However, "HW" remained 0.

What %fan are you running at to maintain 76C? My rigs are 5 cards 2" apart cranking and they only use about ~65% now.

The card is still running very slow. The idea is to keep the card at 80C, as long as the fan isn't cranking 100% all the time it should be fine. If its in a case, you can leave the side panel off, or even point an external fan at it.

Eventually you'd like to earn some money. That card should make you ~25 cents a day on x11 with current prices, depending on whether on not you pay for power. That might be peanuts now, but I experienced a 40x increase in earnings last winter during the bubble. All those 2-3 dollar a days became 100+ days.

Got it running again.  Tested the GPU hashing SHA256 to Slush's Pool and it's definitely working properly.  In fact, it's now hashing at 250KH/s rather than the previous 170KH/s, both with GUIminer.

Last conf file changes I made were to set shaders to the actual total and to delete three parameters that were causing load errors.  Here's the current parameter set:


The higher I set the intensity, the more heat is generated and the fan can't keep up.  12 seems to be reasonable in terms of GPU temp and fan speed.  I don't want to push the GPU hard enough to risk damaging it -- trying to keep it under 80C.  Current SGminer reported hash rate is 250KH/s with temp at 76C.  R and HW are reporting 0 (A -- 4915).  Best of all, I no longer have to mess around with commands after starting SGminer, the conf file is taking care of it just fine as far as I can tell.  I previously had a few disconnects occur and I don't know the cause, it was like the server stopped talking.  Hopefully that doesn't repeat.  Got to just see how it goes now, fingers crossed.

If the pool is reporting the hash rate correctly and the pool is not showing rejects, everythings probably fine. Just seeing block updates means youre not finding anything in time. I used to see this when I solo mined litecoin. The network maybe finding a block every 10-30 seconds, depending on the coin, ad you are perpetually on old work. Ive had this happen before...by lowering

"queue" : "0",
"scan-time" : "1",

to these numbers you can mitigate it. I think cgminer originally had something huge like 60 second scan time, i don't know the default for sgminer,  you could be hashing old work for an entire minute wasting time.

scan time will constantly poll for new work, and queue wont buffer additional work, you dont want to buffer work that will soon be obsolete.

It looks like your using the exact settings from the litecoin hardware comparison. I have never seen any useful mining at such a low intensity. The lowest I have any cards set to is 18, a 5770, 6950, 5850 and a flaky 290. everything else has been cranking at 20 for at least a year and in some instances 2 years. I mined scrypt exclusively from april 2013 to about may this year.

If there was a problem with the gpu, you'd get hardware errors or it would crash the display driver eventually.

Increase intensity to 20 and report back.

also change these in your config. 7 seconds, plus queued work is a lot of wasted time for a slow card
"queue" : "1", -> 0
"scan-time" : "7", -> 1

The thing that's confusing is that for roughly a week at intensity "12", I made plenty of shares of several coins (I can list the results if you like)!  However, I'm now making none at all at the very same intensity, only significant difference (I'm aware of) being the higher concurrency parameter (originally defaulted) and the two command settings.  I'm thinking something's gone wrong, but I've no idea what!  If there's something amiss with the video card, does SGminer flag it?  There has to be an explanation for the change in results, I used to have a pool reported hash rate as high as 312 KH/s w/ GPU 0 only, now there's no reported hash rate at all -- I see that not as a question of optimization, but a question of function!

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.

Thanks guys !

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

Worked back and forth a few times between the "sgminer.conf" file my copy of SGminer emits and the provided example (thanks nsimmons ) 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.

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:

The only messages I'm seeing are block detections and difficulty changes.

I apologize. It was not clear to me from the wording.

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

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

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


then from the cmd prompt run

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.

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 !  Still a total Newbie here I'm afraid !

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"

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.

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

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)!  

===============================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!

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!

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

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?

Thanks for the sgminer suggestion -- something else to learn about !  Introduced me to the NiceHash website.  Now, if I can just find batch file documentation...