Is the site supposed to be operational still? I had a failed CPAY token withdrawal, then the cards got suspended and now I can't even find the old "Support Chat" in the bottom-right corner where it used to annoy me (to try nagging the Support about the token withdrawal issue).  |
|
|
|
I missed out on testing v9.7 but v9.8 made all my Polaris based machines unstable. After a few crashes I had to use DDU and reinstall the driver because Windows failed to boot. I guess this is because I have been using up-to-date drivers which effectively disabled the hardware-control/monitor features of older miner versions but v9.8 was updated to the new API. So, I wish to reiterate my long-standing request: an option to run this miner software with completely disabled hardware-access. Let's face it. AMD's API has been and will be utter sh|t. Let's not fight it unnecessarily (let Unwinder and other brave souls push through that bush).  |
|
|
|
Wow, haven't seen this thread in a very long time. Looking forward to seeing what the plans are in more detail...
Well, the market certailnly looks better than ever.  |
|
|
|
|
Slightly off-topic: Can I use NiceHash without allpools now? (I remember trying this a few months ago and getting temporarily banned by their spam filter.)
|
|
|
|
i can't sync with this addnote  Try these (optionally delete or rename your peers.dat to peers.dat.bak and/or remove the old addnode list from your config file): addnode=84.119.48.173
addnode=46.107.182.176
addnode=68.228.232.135
addnode=88.132.141.63
addnode=184.164.129.202
addnode=51.254.196.222
addnode=80.235.7.253 |
|
|
|
Of course, that's always an option. It's just that I installed every second or third iterations since 16.7.x for these RX4xx cards and none of them seemed to make any meaningful difference for mining (neither performance, nor stability), except this one. That's why I thought it's worth reporting. And it's always possible that things like this are not driver issues but a software bug exposed by some otherwise neutral changes in the driver, or they are driver bugs but trivial to work around in software... |
|
|
|
|
There is something strange going on with the 16.12.2 AMD driver (I skipped 16.12.1) and these mining softwares (Claymore ZEC and ETH):
- after a fresh OS boot I rarely (if ever) get all cards (usually 6 per machine) up to full speed, some get stuck at their lowest GPU clock speeds
- restarting the same miner with the same settings usually reproduces the same pattern (the same GPUs remain stuck as before)
- starting a different miner (ETH after stopping ZEC or vice versa) usually draws a different pattern of stuck GPUs (there is overlap but it's not the same)
- starting two processes of the same miner in parallel with 3-3 different cards instead of all 6 usually gets all cards up to full speed
- starting a single process after getting all cards "unstuck" once with parallel processes usually results in all cards running at full speed (even after switching miners)
There is no detectable/reported driver crash (it's no like those card instantly crash and get reset to "safe" speeds, they never get up to full speed).
Sometimes even smaller machines have similar problems, like 1 card getting stuck from 3 (but it's more often for 6 cards and the 3-3 parallel trick is usually enough for 6 cards)
|
|
|
|
I don't have to check links....I have those cards (11260-01-20G) and on my rigs working only hdmi2vga or hdmi2dvi adapters...
Find some dead HDTV motherboards (from the cheap "untested / not working / sold for parts" category sales, not proper replacement parts). Most of them will have 3 HDMI ports (some might have as much as 5, some might only have a single one but that's rare) which is enough for 3 "rigs" (it's sufficient to have 1 display connected to 1 of the cards per motherboards with Windows>7, I prefer Win10). |
|
|
|
|
Does anybody have a stock BIOS collection for Sapphire RX470 4Gb reference models?
I ran into a rather strange problem:
- bought 5 of these cards (exact same P/N and SKU, roughly similar product numbers)
- saved the full 512Kb image of 1 card as backup (I know, I should have saved them all separately and compare the hashes...)
- flashed a modded 256Kb BIOS (I prepared this in advance, based on the image file on techpowerup)
- noticed something is very wrong with one specific card
- restored the backup BIOS image to all cards
- problem persisted, so I pulled that single card out and used the remaining 4 with my modded BIOS re-applied
- I got the card replaced under warranty (the new one has the same P/N and SKU) but I flashed it, and now it's dead (even after restoring my backup BIOS)
Yes, I know I was stupid I didn't make a unique backup of the replacement card's ROM after the first incident. It's very obvious in hindsight now...
Although, I did always check the memory type with GPU-Z and it always reported Hynix (that's why I was confident I really have identical cards).
Any suggestions?
|
|
|
|
This is rather strange. It's all I get on all my machines now (I am testing the settings with my desktop machine for convenience): 19:45:46:001 1978 args: -tt 0 -mport 0
19:45:46:006 1978
19:45:46:010 1978 浜様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様融
19:45:46:015 1978 ş Claymore's ZCash AMD GPU Miner v1.1 Beta ş
19:45:46:019 1978 Č様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様Ľ
19:45:46:024 1978
19:45:46:230 1978 ZEC: 1 pool is specified
19:45:46:236 1978 Main ZCash pool is equihash.eu.nicehash.com:3357
19:45:46:520 1978 OpenCL platform: AMD Accelerated Parallel Processing
19:45:46:524 1978 OpenCL initializing...
19:45:46:526 1978 AMD Cards available: 1
19:45:46:529 1978 GPU #0: Hawaii, 4096 MB available, 44 compute units
19:45:46:532 1978 GPU #0 recognized as Radeon 290X
19:45:46:535 1978 POOL version
19:45:46:537 1978 b107
19:45:46:540 1978 Platform: Windows
19:45:46:548 1978 start building OpenCL program...
19:45:46:555 1978 done
19:45:46:558 1978 Total cards: 1
19:45:56:329 29c8 ZEC: Stratum - connecting to 'equihash.eu.nicehash.com' <5.153.50.217> port 3357
19:45:56:387 29c8 send: {"id": 1, "method": "mining.subscribe", "params": ["equihashminer", null, "equihash.eu.nicehash.com", "3357"]}
19:45:56:390 29c8 send: {"id": 2, "method": "mining.authorize", "params": ["1ExV8BCzSYoxy77v7A4p1ziAKAn9mLnFC.desktop","x"]}
19:45:56:393 29c8 send: {"id": 5, "method": "mining.extranonce.subscribe", "params": []}
19:45:56:397 29c8 ZEC: Stratum - Connected (equihash.eu.nicehash.com:3357)
19:45:56:419 1978 Watchdog enabled
19:45:56:422 1978
19:45:59:484 29c8 checkread timeout
19:46:02:590 29c8 checkread timeout
19:46:05:690 29c8 checkread timeout
19:46:08:781 29c8 checkread timeout
19:46:11:877 29c8 checkread timeout
19:46:14:937 29c8 checkread timeout
19:46:18:020 29c8 checkread timeout
19:46:21:094 29c8 checkread timeout
19:46:24:178 29c8 checkread timeout
19:46:26:428 1978 em hbt: 30110, fm hbt: 47,
19:46:26:433 1978 watchdog - thread 0, hb time 63
19:46:26:438 1978 watchdog - thread 1, hb time 63
19:46:27:273 29c8 checkread timeout
19:46:27:279 29c8 ZEC: Job timeout, disconnect, retry in 20 sec...
19:46:47:285 29c8 ZEC: Stratum - connecting to 'equihash.eu.nicehash.com' <5.153.50.217> port 3357
19:46:47:342 29c8 send: {"id": 1, "method": "mining.subscribe", "params": ["equihashminer", null, "equihash.eu.nicehash.com", "3357"]}
19:46:47:348 29c8 send: {"id": 2, "method": "mining.authorize", "params": ["1ExV8BCzSYoxy77v7A4p1ziAKAn9mLnFC.desktop","x"]}
19:46:47:353 29c8 send: {"id": 5, "method": "mining.extranonce.subscribe", "params": []}
19:46:47:358 29c8 ZEC: Stratum - Connected (equihash.eu.nicehash.com:3357)
19:46:50:425 29c8 checkread timeout
19:46:53:496 29c8 checkread timeout
19:46:56:445 1978 em hbt: 9156, fm hbt: 15,
19:46:56:449 1978 watchdog - thread 0, hb time 31
19:46:56:452 1978 watchdog - thread 1, hb time 46
19:46:56:570 29c8 checkread timeout
19:46:59:651 29c8 checkread timeout
19:47:02:727 29c8 checkread timeout
19:47:05:850 29c8 checkread timeout
19:47:08:923 29c8 checkread timeout
19:47:11:991 29c8 checkread timeout
19:47:15:059 29c8 checkread timeout
19:47:18:130 29c8 checkread timeout
19:47:18:136 29c8 ZEC: Job timeout, disconnect, retry in 20 sec...
19:47:26:457 1978 em hbt: 39172, fm hbt: 78,
19:47:26:463 1978 watchdog - thread 0, hb time 16
19:47:26:468 1978 watchdog - thread 1, hb time 47
19:47:38:143 29c8 ZEC: Stratum - connecting to 'equihash.eu.nicehash.com' <5.153.50.217> port 3357
19:47:38:194 29c8 send: {"id": 1, "method": "mining.subscribe", "params": ["equihashminer", null, "equihash.eu.nicehash.com", "3357"]}
19:47:38:197 29c8 send: {"id": 2, "method": "mining.authorize", "params": ["1ExV8BCzSYoxy77v7A4p1ziAKAn9mLnFC.desktop","x"]}
19:47:38:200 29c8 send: {"id": 5, "method": "mining.extranonce.subscribe", "params": []}
19:47:38:203 29c8 ZEC: Stratum - Connected (equihash.eu.nicehash.com:3357)
19:47:41:285 29c8 checkread timeout
19:47:44:362 29c8 checkread timeout This started when upgraded to v1.1 but going back to v1.0 does not seem to solve it. I can ping the address fine from all the local machines and I see active buy orders on nicehash for equihash. |
|
|
|
|
Nice warning about those kind of SATA cables. I burned a cable like that when I connected two RX480 cards to a single one of those. But the cable quality wasn't really great to begin with. The wires looked thick enough but the connectors were really loose ("pressured razor blades" kind of fitting in a lazy fashion). Although, 1 card works just fine if the cable quality (including the connectors) is decent (and you don't try to win overclocking contests).
I thought about modifying the risers like that but I ran into a false problem. I though: "nahh, the cards might need the 5V lane, not just the 12V". But I was stupid because I could simply leave the 5V wire as is (on a SATA/molex) and only cut/redirect the 12V. Although, as I said, 1 card per decent SATA cable works just fine for me, so I will leave it be. (But I replaced that PSU with one which has better SATA connectors. The old PSU could be hanging on the balance with 1 card.)
|
|
|
|
Is it possible that dual SIA mining NOT change hashrate compared to ETH only?
Or there is something wrong with cards/drivers etc?
Gigabyte 380x.. about 20mhs a card with and without SIA..
Moreover, at some (not large) -dcri values in dual mode you can get a bit more ETH hashrate compared to ETH-only mode (because of shorter queue to memory access), though I see it on 390 cards only. Increase -dcri and ETH hashrate will fall. Interesting. I would think the opposite or assume you can use some tricks to achieve the same without the increased power draw (like explicitly flushing or deliberately "starving" that queue). I don't currently run a secondary coin because high memory clocks with tight timings are only stable at low temperatures (which is also beneficial for power efficiency on it's own) and it's hard to keep the reference 480s cool even at ~100% fan speed if they are busy with two coins. So, single-ETH seems to be better overall (for me, for now. may be winter will change that). |
|
|
|
In order to have less power drain is better decrease the TDP and TDC value ?
Some people often argue they can squeeze out a few Watts decrease by finding the lowest possible PowerLimit (which is an offset applied to the TDP, so you can ignore/disable the PowerLimit offset when you have direct control of the TDP itself), although I think even if such a thing is real (but I think it's just a false perception due to the finite precision and accuracy of their measurements and tuning iterations because TDP ultimately controls [throttles or not] the core clock and very few if anything else, especially under heavy graphic or computing loads when you can't shut down computing blocks) it's not worth worrying about. If you want the optimal settings I suggest you disable / work around the arbitrary limiters (like TDP) and: - find the best memory clock + timing pair (not easy but the potential profit is high) - find the lowest GPU core clock which is sufficient for that memory setting (not too hard but meaningful and thus profitable) - try to under-volt the GPU core (I didn't manage to do that with the 480 yet, it's not the easiest part in practice) (Keep in mind that AMD often uses hardware level dynamic voltage scaling since around Hawaii (R9 290X), so the voltage you think you modify is usually an offset for a target.) Now you probably want to try and create another configuration which allows for lower voltage (loose timings, lower core clock, lower voltage), then compare the perf/Watt of these two configs and decide (or divine a third iteration). |
|
|
|
I personally prefer to eradicate the power limiters (set them high enough to always be a no-op). This is how I run my 480 8Gb cards:  (and you can't see that on this screenshot but I copied the 1626-1750 timings to the 2000+ strap) It would be nice if I could resize the window so that I could always see every items and their full content in every sub-window. |
|
|
|
|
- I planned to use Gentoo (which I love) but amdgpu-pro is not available for it yet (well, not in a working condition) and amdgpu+MESA instantly crashes with ethminer (claymore refuses to use MESA).
- then I tried to fall back to Ubuntu (which I hate) but I had some issues with amdgpu-pro (and since I hate debugging Ubuntu problems, I gave up fast)
- finally, I settled for Win10 (which I like and prefer over Win7)
I quickly checked the hashrate in Win7 but saw no meaningful difference compared to Win10, so I was pleased the Windows line is not restricted with these cards.
|
|
|
|
secure boot is off of course in my system
so you suggest to enable IGPU, sign driver myself, then turn testmode off and that's all?
No. - turn on the iGPU (set it to Auto if possible, so it's always disabled when you don't connect any monitors to it but enabled whenever you do) - move your monitor to the iGPU (you might loose the signal on the discrete cards anyway and you might need to do this temporarily to stop the AMD driver from loading) - have an AMD driver installed (doesn't matter if already "cracked" or stock but I will assume stock here) - flash your cards with custom BIOS (if not already) - reboot to Safe Mode to replace the DLL file with the cracked one (if not already) - enable the Test Mode with bcdedit permanently for every regular boot (and keep it enabled indefinitely) and reboot - sign your DLL file with the tool linked above (preferably while in Test Mode but with the driver NOT loaded, either due to signature problem or no cards connected, etc...) My exact journey was like this: - flashed the cards - enabled Test Mode for regular boots - rebooted to Safe More (note: not Test Mode yet) and applied the cracked DLL - tried but failed to reboot into Test Mode (I ended up with a completely blank display, no life sign) - moved the monitor to the iGPU and rebooted again into Test Mode (by default) - I signed the cracked driver with the linked tool - rebooted (yet again into Test Mode as always from now) and saw the AMD driver loaded - I shut down Windows, move the monitor back to the discrete AMD card (for WattMan to work), booted (into Test Mode) and everything works |
|
|
|
and finally, use this tool (while booted into Test Mode which is now the default for every boot, so simply reboot from Safe Mode "normally" = into Test Mode now): http://www.ngohq.com/?page=dseoto locally self-sign the cracked DLL (since Test Mode requires a valid test signature!) -> copy-paste the line above when asked for the DLL file location (Don't try to use the tool to enable Test Mode! Issue the bcdedit command above manually. This tool is for Windows 7, not >=8 but it can still sign anything anywhere...) have you tried yourself? I didn't manage to make it work without "7" option at reboot Yes. I found and started using this solution several years ago when I had troubles with an old notebook and this is exactly what I just did yesterday on the mining PC (and it worked). SecureBoot could still interfere though, especially if it's a clean install of Windows 10 RS1 (the last update) which made MS signatures (*) mandatory for kernel mode drivers. So, I guess you have to disable Secure Boot (sometimes "Other OS" means "disabled" in practice, so set it to anything but "Enabled" or "UEFI Windows"). * valid MS means WHQL is practice, it's not enough if AMD itself signs it but not MS (so, forget using your own signatures in that system). The other possible trick in my procedure is that I flashed the card first and started to work on Windows later, so the DLL file rejected and this it wasn't loaded when I rebooted into Test Mode to sign it. I am not sure if you can successfully sign in Safe Mode (I guess not but you can try) but you can prevent the driver from loading if you, for example, disconnect all AMD cards and use the Intel iGPU (if available). And that's what I did (I didn't disconnect anything but used the iGPU) because there was no output at all on the AMD card when it tried to boot in EFI mode without a signed driver. |
|
|
|
Well, first of all: Thanks for these BIOS images.  Here is the proper (and I think the only actually working) way of permanently dealing with the driver signature checks: in Safe Mode, overwrite your C:\Windows\System32\drivers\atikmdag.sys file with the cracked one and issue this command in an admin command line: bcdedit /set testsigning on and finally, use this tool (while booted into Test Mode which is now the default for every boot, so simply reboot from Safe Mode "normally" = into Test Mode now): http://www.ngohq.com/?page=dseoto locally self-sign the cracked DLL (since Test Mode requires a valid test signature!) -> copy-paste the line above when asked for the DLL file location (Don't try to use the tool to enable Test Mode! Issue the bcdedit command above manually. This tool is for Windows 7, not >=8 but it can still sign anything anywhere...) |
|
|
|
|
I run some reference design RX480 8Gb cards with default GPU clock/voltage settings (for some reason, these controls are completely locked in WattMan whenever a mining software is running) and the VRAM clocked to 2250MHz (max allowed) with default RAM voltage (I could try under-volting the RAM but I don't think it would worth the hassle since it draws significantly less power than the GPU to begin with and it's overclocked, so it probably needs the voltage anyway...) and I get 27 + 405 Mh/s (ETH+DCR) on each with Claymore's software (v6.1) on Win10 RS1 + Catalyst 16.8.2 beta.
The PSU is rated at ~90% efficiency at ~50% load (and that's roughly the current situations with the 1200W rated PSU drawing 780W from the wall with 3 of these cards + the 30W idle platform [measured alone], so it's ~60% load), so the cards take roughly ~225W (according to measurements and calculations) which is exactly their maximum theoretical limit (150*1.5=225W with the PowerLimit set to +50% over the original 150W TDP limit).
|
|
|
|
Claymore, you should definitely include a command line switch which completely disables ADL (all kinds of hardware monitoring/control, don't even scan for it).
It took me a few days (and a few rounds of jumping between driver/CNext versions) to realize WattMan disables the GPU clock/voltage controls whenever your software is running but enables them when it's not.
I wish to try and undervolt my 480s...
Are you sure that "-tt 0" does not work? Moreover, ADL for 480 works only in v6.0. I am using v6.0 now but I had the same problem with 5.3 (didn't try older ones with these cards). Yes, I tried to add "-tt 0" but it doesn't seem to help (I only tried that with v6.0 though, not with v5.3). The GPU clock/voltage panel of WattMan gets grayed out whenever I start mining and it always comes back yellow (operable) when I stop mining. I am not entirely certain it's related specifically to the hardware monitoring/controlling capabilities of your software or WattMan locks those controls under any kind of heavy computing loads. But it seemed to be a good "educated guess" at first if WattMan tries to "hand over the controls" when something else polls the hardware (think about third-party software like AfterBurner and GPU Tweak II, etc). |
|
|
|
|
Show Posts
