Topic: Sapphire R9 290X Tri-X OC Hashrate? (Read 36578 times)

I get about 930khs from my 043 cards in bamt, how much more you expecting?  tc 20481, 1030/1400 i-20

with what x intensity?

I realise "You cant polish a turd", but does anyone know of a n alternative/improved BIOS that works with the later 290 Tri-X 043 cards?

eg:  that supports the later Hynix ram.

Best,
-Evil

Hi all,

Two of My R9 290 Tri-x's just died.  They won't boot up alone directly plugged into an X16 slot.

How do you go about RMA'ing these?  I see everyone talk about RMA, but don't see any info on it.

Also what exactly does RMA stand for ?  Return, Manufacturer ....

Cheers,

My favorite lately is 20479.  Best performance I have found.

the magic TC is "25599" 

getting 856 at 72 degrees in an open case.

I have been mining for 8 days straight now so well happy.

need an intensity that don't make my pc unusable

Hello miners,

I will appreciate if you support me on an issue I am currently experiencing with my RIG.
I will start from scratch trying to simply explain my pain. Thank you in advance for your time! :-)

RIG Specs:

MB  Asrock H81 ProBtc
GPU 4x Saphire 290 Tri-X OC
PSU 1x Corsair i1200ax Platinum
CPU Pentium
RAM 2x2GB 1333mhz

3 GPU's are on risers PCIx1 --> PCIx16
The system is assembled and starting with SMOS BAMT from USB stick. It is working with SMOS config suggested from their site for about 11-36 hours when it suddenly freeze with black screen, no SSH and no web dashboard. The only solution is physically powering off the RIG. I also observe that it wont start mine successfully after reboot with the overclocked cgminer.conf and I have to load a default one from backup to reboot and afterwards to update the overclocked config for another 11-36 hours of successful mining.



So far I have done some investigation and I have the following results:

1) Assuming power consumption issue - I have started the RIG with 3 GPU's where I have the same result. The system works perfectly fine for ~11h and then freeze.
2) Assuming overclocking issue - I have left the RIG with 3/4 GPU's with default cgminer config - the very same result.
3) I have tested also the MEM and can confirm it is fine.
4) GPU temps are 62-69 C with fan's rpm between 55-85%

5)From the logs I can observe the following error:
root@smos-1:~# tail /var/log/messages
Mar  5 20:02:20 smos-1 kernel: [   58.821275] atitweak[3090]: segfault at 2e6e6570 ip b7511cad sp bf85f700 error 6 in libc-2.11.3.so[b74a2000+140000]
Mar  5 20:02:20 smos-1 start_mining[2992]: generating per gpu munin plugins for template gputemp...
Mar  5 20:02:20 smos-1 start_mining[2992]: done generating munin config, starting munin-node
Mar  5 20:02:20 smos-1 kernel: [   59.000845] atitweak[3191]: segfault at 1d ip b75e3cad sp bfd397b0 error 6 in libc-2.11.3.so[b7574000+140000]
Mar  5 20:02:24 smos-1 start_mining[3536]: starting cgminer with cmd: cd /opt/miners/cgminer;/usr/bin/screen -d -m -S cgminer /opt/miners/cgminer/cgminer -c /etc/bamt/cgminer.conf
Mar  5 20:02:24 smos-1 start_mining[3547]: post mining tasks...
Mar  5 20:02:24 smos-1 start_mining[3547]: gathering post-mine stats for offline mode
Mar  5 20:03:01 smos-1 kernel: [   99.895369] atitweak[3905]: segfault at 50a0556 ip b753fcad sp bfd83260 error 6 in libc-2.11.3.so[b74d0000+140000]
Mar  5 20:03:01 smos-1 kernel: [   99.958959] atitweak[3910]: segfault at 64356441 ip b7459cad sp bf862480 error 6 in libc-2.11.3.so[b73ea000+140000]
Mar  5 20:05:01 smos-1 kernel: [  220.020975] atitweak[4060]: segfault at 776f64c2 ip b7590cad sp bff36820 error 6 in libc-2.11.3.so[b7521000+140000]


I have potted that one of the hangs was with GPU 0 DEAD/SICK - How could I confirm on which slot is GPU 0 installed ?
Could you please advice on what should I focus my self to investigate any further the RIG issue ?

Really appreciate your help!

Try WafflePool and see if your rejects are better.  Your high reject rate is very likely due to the way ScryptGuild decides if a share is stale or not.

Yeah, I did wonder if it was the pool too. ScryptGuild here.

rhaikh: I don't see where I suggested xi 1100 in that post...

Relm9: rejects are hugely dependant on the pool too. Where are you mining?  BIOS is unlikely to affect your reject rate.

I get ~1% rejects at xi 1100, btw.

I'm a bit out of the loop when it comes to newer cgminer versions... I did try an xintensity value of 300 just now and this seems to be working better, rejects are at 4% which is an improvement over the 7% I was getting with intensity 20, and the hash rate is around the same as intensity 20.

My hash rate gain from -I 18 to the new settings only around 4-5% though, so with the rejects factored in it's almost a wash.

I'll have to play around with the settings more... I came across someone's post with 300 xintensity and his rejects were around 1% though, so not sure what's going on. He was running a custom BIOS and I'm still on stock, maybe that has something to do with it.

Intensity - raw(?) - xintensity
13   8192           2.90909090909091
14   16384   5.81818181818182
15   32768   11.6363636363636
16   65536   23.2727272727273
17   131072   46.5454545454545
18   262144   93.0909090909091
19   524288   186.181818181818
20   1048576   372.363636363636
21   2097152   744.727272727273
22   4194304   1489.45454545455

So you are suggesting an xintensity which corresponds to between 21 and 22 whereas he's saying a value closer to 18 (93) reduces rejects.

In my own setup I tested xintensity keeping other values constant.  Values higher than ~372 (such as 1100 and 702) were causing some throttling issues i'm assuming due to gaps in utilization (temp pretty cool throughout).  Values lower than ~372 (such as 176 and 93) reduced the hash rate with no improved thermal performance.  I don't have any reject % numbers though and I will test that again later.

Stop using intensity... switch to shader multiple threads - xintensity.  Intensity is completely antiquated now.

Intensity 20 on these cards gives me way too many rejects, I found 18 is the best setting (< 1% reject).

Why this #?  People here say try 1000 + x*10 and I guess that makes sense. What speeds under 1000 should be tried?

Thanks for the reply.

The TC is from 2816 * 8 + 1 and just a guess.  Where the heck is 24000 24550 32765 from?

2816 * 5  + 1 = 14081
2816 * 6  + 1 = 16897
2816 * 7  + 1 = 19713
2816 * 8  + 1 = 22529
2816 * 9  + 1 = 25345
2816 * 10  + 1 =  28161
2816 * 11  + 1 = 30977
2816 * 12  + 1 = 33793

It doesn't seem happy using more than 30k thread concurrency so I'm using *8 at the moment.  I can remove the shaders line but I am pretty sure the card has 2816 shaders so I doubt it makes a difference.  I'm willing to entertain other numbers but I'd like to hear a reason.

I want to keep the fan low (hence 60-85) and the temps low to increase overall longevity of the card and avoid a bad time when summer hits.  I'm willing to give up some kh/s to do it but I also want to run an optimal setting.  Giving up 10% so far seems like an OK deal but 5% would be nice.  I'll try a single gpu thread and see where that gets me.  And more trial and error.  I think it was generally better than 2 in my attempts earlier.

I finally got some good settings for my 290x Tri X OC.  I am running 918KH/s with these settings in BAMT. Mine runs at 73 degrees with these settings. I also have a Cooler Master Haf X. So there are a lot of fans in my case! Thanks for the response rhaikh!

"intensity" : "20",
"vectors" : "1",
"auto-fan" : true,
"temp-target" : "75",
"temp-overheat" : "80",
"temp-cutoff" : "90",
"worksize" : "256",
"kernel" : "scrypt",
"lookup-gap" : "2",
"thread-concurrency" : "32765",
"shaders" : "0",
"api-listen" : true,
"api-port" : "4028",
"api-allow" : "W:127.0.0.1",
"expiry" : "60",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "1",
"gpu-engine" : "947",
"gpu-memclock" : "1425",
"gpu-powertune" : "20",
"log" : "5",
"no-pool-disable" : true,
"queue" : "0",
"scan-time" : "2",
"scrypt" : true,
"shares" : "0",
"kernel-path" : "/usr/local/bin"

Only relevant parts quoted - nuff said... fix your cooling situation - VRM and GPU needs to stay cool.

---

That said...

stop using gpu-threads 2... 1 is optimal for 290(X)

Where the heck is that thread-concurrency from?  Try some normal numbers as posted everywhere.

If you are tuning intensity/xintensity, get rid of the shaders line.

Crank your FAN!  Why are you using variable?  Stick it to 90 or 100% if you need to to keep it cooler. temp-* is too low.  cutoff should be 95, overheat something like 97, and target 92.

If you are mining on a pool that has a good reject policy, crank the xintensity up - 1100 is a good value.  Only pool like CM, or solo-mining low-diff coins, will reward a low intensity.