Hello, thank you for sharing. Could you show more details on the Gigabyte 6800 XT. I’m curious what the Memory Controller Voltage (mV) is set to?
I assume the 655 value is the Core Voltage (mV), and that 1255 is the Memory Voltage (mV)?
Also, do you have any values in SoC Frequency or VDDmax?
Core voltage: 655
Memory voltage:1255
Soc Freq:805
VDDmax:950
thanks for sharing, but your settings crash my card and rig. Have you changed the bios or done something to achieve those settings?
Here are some OC settings for Gigabyte 6800 XT and ASUS 6700 XT. no Bios changes, SoC values are empty/defaulted
And here are some PowerColor and Gigabyte 6800 OC settings. no Bios changes, SoC values are empty/defaulted
What would be a remedy if 1 or 2 cards from 6-GPU (Biostar 6800xt) is dropping hashrate to the range of 20-55mh/s, while the remaining GPUs keep ~61mh/s. The cards are affected randomly, each time it would be a different card. Checked on TRM and TBM. Same behaviour on 2 separate rigs.
Especially on TRM it can be observed that it is connected with dropping F state of that affected card. Using UPP to bump F clock and memory clock to their desired values sometimes help, but sometimes even though all OC parameters and F clock are in tact, the card would still underperform. Maybe there is some other throttling?
Make sure you are on latest stable kernel as a start, best baseline with most other posters suggestions.
Be prepare to some some GPUs:
I was downloading the latest HiveOS image last week and that problem was right away. Then I switched to some older beta version, which yielded the same results. BIOS update didnt’t help neither. Each reset it affects a different card. Another thing is that vary often the rig is stuck during POST at VGA detection. However, in rare event when everything boots up correclty, and all cards start to hash with full power, one rig remains fairly stable - several hours without any error, while the remaining two rigs throw GPU dead errors each 20-30 minutes. That potentially could be bad risers, because swapping cards between two rigs didn’t help.
I’m really disappointed with these BIOSTAR RX6800GT cards - on another thread I described the problem with entering BIOS with them - you just can’t. Same goes for Boot Menu - when selected it crashes the machine. Do you think I could safely flash them with BIOS of another manufacturer? Maybe that would help somehow.
First rig
Second rig
Sometimes this happens too:
The hashrate is lower, although amd-info shows that all Core/Mem/Fclk are in tact.
Must be using Phoenix Miner? Because that overstates hashrate a lot
Who knows since half the time or more people don’t even indicate what miner they run in their posts. Which makes their shared settings a lot less useful.
Who here is using team black in hive with 6000 series cards? Is it worth the fuss to get it working? It seems like it takes a lot of screwing around with intensity values and such to get it tuned whereas other miners seem to ‘just work’.
That is a lot of downtime on an unsupportable software branch to chase a group of poor performers.
Get back to latest stable Kernel&Drivers
Review the number of code releases per month related to TBM and whether they are new features or break/fix.
Any good OC setting for ASRock 6900 XT? It looks like is outperformed by a lot of 6800 XT, I hoped for something like 65 Mhs @110w being the chipset faster
Just going off what I’m seeing on the btc talk thread for TBM the releases are a mix of bug fixes and improvements.
That said, no SSL support yet kind of kills it for me. I prefer using SSL if I may.
Probably be best off just sticking with what has worked for so long, TRM, even with the 1.0% fee I guess that buys you ease of use and a known quantity.
I have the asrock 6900xt formula OC, the model with the XTXH core. While I can clock the memory higher than 2150 in windows there is no performance benefit. Hash rate just crashes anyway when pushing up past that limit. Disappointing but GDDR6 is what it is. I really have no idea how they squeeze 2250mhz out of the reference 6900xt liquid cool model that is basically a unicorn at this point.
I get 63.4 MH out of it in windows and it beats every other 6000 card I have running in my hive rigs. Most of my 6800 cards are around 61.8-62.2 MH.
Can’t argue with your logic.
fwiw: I’ll follow the folks that test with 100x my hashrate, measure accepted shares poolside, and could care less about MH/s bragging rights in posts.
Last I checked, we don’t receive rewards for reported MH/s.
Thanks for the suggestion. In that case it’s difficult to pick poor performers as each time the poor performer is different, basically meanng all cards are poor performers.
However, what I observed is that when I lower Memory Clock to 1050MHz, all cards start to hash with the same speed. When bumping up to 1055 or 1060, some of them lower the hashrate and become more instable. Therefore now I’m just testing them with 1050MHz memory clock and so far so good for a few hours, what previously was unobtainable. I will keep you posted and let you know the results.
I also flashed a GPU with a reference card’s BIOS - the problem with entering BIOS/boot menu was resolved, as expected. It seems as if Biotar didn’t try hard enough to make their BIOS more compatible with other hardware. (Changing BIOS did not have any effect on hashrate)
Do you think running the SoC 1000MHz@800mV is safe? The lowest voltages I’ve seen on this thread were rather somewhere around 860-870mV.
*At the moment I run 2 out of 3 rigs on the newest kernel and HiveOS version. To this point no difference in hashrate or stability between rigs, however I’ll update if I have new observations.
FWIW. I’ve got a problem with a rig now where it will boot and start mining but it is not able to enter the BIOS. The monitor (displayport) never turns on and detects a signal. The motherboard (asus b550-f) shows a stuck white LED indicating a graphics card problem. I don’t think any of the cards have an issue. I blame the motherboard.
The monitor is plugged into the card that is attached to PCI-E slot 1. That still hasn’t resolved the issue. At this point I don’t care - it works and is operational to mine. Not worth bothering with unless I absolutely have to get into the BIOS at which point I will probably need to disconnect all but one GPU for it to allow me back in.
In my limited experience:
You can’t account for the differences in Kernel, Driver, and F-state variations in the software version you are running on. This includes driver support for your particular motherboard, CPU, LAN, etc.
If your hope is get on an island which finally works for your very narrow group of hardware, continue experimenting across the board, but at some point, I would suggest a Pre-#72(f-state functions began) or >= #83 (current stable) version to focus your efforts.
There is no middle ground as any scripting you attempt will be fighting what is included in the Kernel packaging.
I’d break down to a single GPU in a test rig on the latest stable kernel and repeatably test (1) by (1) if had to establish good vs. bad.
I empathize with the situation, I had to separate some brands out into various rigs to manage their particular issues.
Wishing you good luck and good mining results, soonest.
