Here are the results of my various settings… Hopefully the table renders properly. These GPU’s are running at stock clocks. As far as power consumption, only had a 100w increase for almost double the hash rate in a 4x GPU rig.
edit: table didn’t render… Best settings were -i 13 -w 64, and -i 12 -w 64 which were both pegged at 300Kh/s
So far I’m getting the best results with the 14.6 drivers and the R9 290. When I used 14.4 for some reason the hash rates were far better than 14.9, but nowhere near as good as 14.6. I’m compiling a list of all of the settings I’ve tried with corresponding hash rates that I’ll post when I’m done. Currently the best I’ve seen is 300Kh/s using -I 13 and -w 64 (as mentioned earlier).
LoL. Works great now with 14.x. Edited the other post and updated the zip file.
Here’s the one that I threw together complete with the 13.x AMD drivers (you need them as the kernel included with this dev release does not appear to work with 14.x yet). For those of you who normally use cgminer, you use “-k neoscrypt” instead of --neoscrypt to tell the miner which algo to use.
https://www.dropbox.com/s/0327xxwnuriv6z2/sgminerNeoScrypt-Dev.zip?dl=0
You can definitely tell that everyone just started using 3.7.8 - the network hash rate is up almost 40% and the diff with it.
Haven’t tried playing with the clock speeds yet on my 290’s - however… I was able to get them up to 160kh/s using -I 15 and -w 48… (hynix cards, haven’t tried the elpida ones yet)
Not too shabby for stock clocks :)
Absolutely… :) I’m getting pretty decent performance bumps from my 7950’s by tweaking the settings, but my 290’s aren’t doing much better than they already were.
So, some new observations… My initial results with 3.7.8 were based on using the exact same settings I had used with the 3.7.7 series. Try starting over with your configs (ie: bump up -w, change intensity etc). My 7950 rig got even more performance with -w 64 and a higher intensity, which it couldn’t do with the 13.x bin files… I’ll keep playing.
So how do we get a copy of this in-dev kernel? LoL
Wow, 255Kh/s with no HW errors? I’m assuming that’s 1 gpu… None of my stuff is OC’d except for my 7950’s (which went from 85kh/s to 113kh/s) …
https://www.dropbox.com/s/fc6ufamv44140zl/NeoScrypt-3.7.8.zip?dl=0
Seeing a HUGE performance bump for the R9 290 - 100kh/s - 135-140Kh/s. Using native 14.9 drivers, no messing with 13.x bin files.
Thanks Wolf0 & Vehre… This is awesome.
op has not the latest…
it has 3.7.7b current is 3.7.7c
windows miner compiled by me, 3.7.7c:
Did you notice any extra performance with 3.7.7c? I just compiled it tonight and didn’t notice any difference. One thing I will mention for anyone who decides to try 3.7.7c, is that it was actually overwriting my 13.x bin files with new 14.x ones. You need to follow the directions from seand52 about copying AMD driver files on this other post unless you want 100% hardware errors (or grab 3.7.7c from my dropbox):
https://forum.feathercoin.com/index.php?/topic/7978-hw-errors/
https://www.dropbox.com/s/waedf2ghtc33zun/NeoScrypt-3.7.7c.zip?dl=0
First of all, I’m really glad we’ve made the switch to NeoScrypt. I’m happy that we have something we can GPU mine again without taking a huge loss. I’m just curious if anyone is in the same boat as me already. Last I checked the amount of FTC I’ve been mining barely covers the cost of electricity @ $0.11/kWh. I’ve got my mining equipment optimized as much as possible based on what I have to work with and what I know of NeoScrypt optimizations (850w @ 400kh/s with cgminer 3.7.7b). Anytime the diff goes over 6 I’m barely breaking even, yet I keep seeing the hash rate climb higher and higher as if everyone has free power to work with. I know that multipool activity can drive diff levels high, but this hasn’t really affected FTC nearly as bad since the previous fork when the diff re-target was adjusted. I can only come to a few conclusions of my own: a.) far more people have cheaper power than I do. b.) CPU miner botnet activity? or c.) far better optimized GPU mining software that I don’t have or am not aware of. Thoughts?
What type of riser cables are you using? 16x to 16x and maybe a single 16x to 1x? Almost every single problem that I’ve ever had with mining has been related to crappy riser cables. Pins that aren’t completely soldered, tiny breaks in the ribbons themselves etc. I’ve tossed about 5 different cable in the last year alone. In retrospect I should have just taken a dremel to them and reduced them to 16x to 1x…
Here are a few observations that I’ve made over the last year in regard to these risers…
First off, if I could start all over I would have done all 16x to 1x ribbons. Mining doesn’t use anything other than 1x anyway, they are cheaper, and you have less pins to be messed up or broken (less troubleshooting basically). Not only that, but when you have a 16x ribbon in a 16x slot (especially the first 2 slots), the motherboard reports this, the OS expects this, and the AMD Catalyst software tries to utilize it. What appears to happen is that the AMD software will try to enable crossfire automatically as soon as it detects 2 16X or 8X devices in those first 2 slots. If any single pin is messed up in the 1x, 4x, or 8x sections of either of these risers, the driver will lock the system up and cause it to crash. I’ve been able to take bad cables and move them to the last slot simply because that last slot only tries to utilize 4x which doesn’t use the majority of the riser pins and it magically works just fine.
Like I said, almost every single problem I’ve ever had was PCIE riser related. As soon as I take the riser out of the equation, everything magically works just fine. Go figure. The magic about using all 1x risers is that the Catalyst driver theoretically should never try to enable crossfire or use anything beyond that 1x bandwidth. If you’ve got mostly 16x risers, I would move them around and see if you can’t get 2 good ones into the PCIE 1 and 2 slots. If you can get those first 2 slots working well and mining, you should be able to start adding more cards to the system. If you add card 3 with another 16x riser and the system locks up, most likely you’ve got a riser with an issue in the 1-4x range.
Cheers.
Sapphire R9-290 Tri-X/OC — 125 to 145 Kh/s — 77c to 82c temps
-I 13
-g 3
-w 48
AMD 14.03 / 14.9Catalyst - updated from 13.11 - stock settings, not overclocked or undervolted
Take a look at the HW stats in cgminer, looks like those settings are only getting you hardware errors…
-Edit- To quote a famous gay guy, “oh my”… 136 mh/s and climbing…
Which settings/drivers did you use to get that high of a hash rate? Highest I’ve seen so far is 111Kh/s with an R9 290 (hynix ram) with the settings I mentioned earlier.
I’ve changed driver versions so many times now that it’s practically a science. The key to driver uninstall is the DDU app. Without it you leave behind too many files and things start crashing and not running right. Someone else on this thread was talking about not going beyond 13.12 for performance reasons. Back when I first started messing with this stuff it was with 7950’s and by going beyond the 13.12 series it definitely impacted performance. I theorize that you’ll see the bump I was talking about just by reverting to the older stuff. I really don’t know why it makes a difference, but I’ve gotten great performance out of my 290’s by doing exactly what I said. 13.12 bin files seem to be gold for me when paired with 14.X. What I found is that the -g 2 setting doesn’t do anything for the 290 unless you have a 14.X series driver installed. Once you install 14.X and use the 13.12 bin with -g 2, it causes that performance bump up into the 100-110 range.
I’m also looking for optimum settings for the 290/290x gpu’s. (maybe a google doc spreadsheet with settings can be developed sort of like the litecoin one?)
Anyway, I’m currently running -I 14 -g 4 -w 32, and have one 290 GPU running 60 kh/s and an identical GPU running 51 kh/s. win7x64, ATI 13.25, 3.7.7b.
Tried another setting shown in this thread
but the 3.7.7b doesnt like the concurrency, and without it, only managed about 45 kh/s.
I’ve configured several rigs now that are running R9 290’s. Elpida based GPU’s run around 100Kh/s, while Hynix ones tend to be around 110Kh/s on 3.7.7b
Here’s what I’ve done on each of them:
Step 1 - Uninstall any 14.X based driver you may already have (or anything higher than 13.12 for that matter). Then grab DDU from guru3d.com and use it to completely remove any remnant of that driver.
Step 2 - Install 13.12
Step 3 - Create a batch file that you can use to provide cgminer with these startup options, ie: c:\neoscrypt377b\cgminer.exe --neoscrypt -g 2 -I 14 -w 32 -o http://bla.bla:12345 -u XXX - p XXX
Step 4 - ensure that you’ve deleted *all* .bin files created by any previous run attempts with that other driver. Wherever you run the batch file from, that’s where the bin files are created. If you’re using CGWatcher to launch this, the bin files will be created in the actual cgminer home directory, go delete them. I recommend creating a new directory called “neoScrypt377b” and placing your batch file there - this makes sure that you’re using all new bin files.
Step 5 - Now run the newly created batch file. Cgminer should launch and your GPU’s should hash in the upper 70’s to low 80’s. This will also create a brand new bin file using these settings. Now close it.
Step 6 - Run the 14.X installer and upgrade the driver (I’m using 14.9). Now when you run the batch file, it will be using bin files created with 13.12 - but utilizing whatever extra capability is enabled with 14.X.
I’ve done this on several different rigs now and it’s worked exactly the same with every R9 290 card I’ve touched across 4 different manufacturers (stock card settings). The key is creating those bin files with 13.12 installed and then using them after you upgrade to 14.X. Sometimes people don’t realize where the bin files are being created to be able to delete them. If cgminer sees a bin file with the same name in the directory it’s looking at, it won’t even bother trying to make a new one for you regardless of what driver you’re using. Hopefully this helps someone out.
note: If you’re using CGWatcher… You need to add the --temp-cutoff and --temp-overheat settings or it might throttle the GPU down and decrease the hash rate. When mining scrypt, these GPU’s got hot and pulled a lot of power. As of 3.7.7b they don’t use nearly as much power or produce as much heat…
How did you undervolt the 290 ?
I’m using MSI Afterburner. Most of mine seem to run pretty stable at -62 with stock clocks.
Having the best luck as mentioned earlier by using bin files created with 13.11 and then installing the 14.X drivers. Seems that the R9 290 doesn’t understand the -g 2 option without the newer drivers installed (makes a big difference in hash rate for the R9 290). I’ve got my 7950’s hashing at 85Kh/s and my R9 290 (hynix) at 111Kh/s. using -g 2, -I 13 (7950’s), 14 (r9 290) and -w 32 for both. My 7950’s are OC’d, the 290 is running stock clocks and undervolted. Running 3.7.7b.