cwl has no effect
it has indeed...
|
|
|
Not too sure how memory timings reliant can is.
It's relevant in the way that if more people can test the tool the sooner we got better results (made public). But if putting together a linux system is so much PITA only a few can use it.
|
|
|
I played with this tool during the weekend on Vega. But to be honest I did not see any hashrate increase under CN algos. I'm not an expert on timings, but I should see at least 1-2% increase when changing CL 20->19
That was the first time I put a Linux AMD system together and I am struggling with the different kernel and driver versions not working together. The biggest problem is the GPU freq is affected by the voltage. If I set in PPT P7 1600 950 then the GPU runs only at around 1400@950mV. If I increase the voltage the clock goes up, but quickly reaches TDP. Also if I try to trick it and set P7 1700@950 then if load changes freq spikes up and card freezes obviously. Tried with 3 different kernels and one is worse than the other. Maybe I should try other than the 18.50 amdgpupro?
|
|
|
I used to set my RX470s on 1000/800 core and 2050/850 memory
that results in the GPU setting being 1000/850. Dont forget the Vddc >= Vddci rule
|
|
|
Changed timings does not remain after reboot from linux to win?
|
|
|
I got about 350 USD on my account when the card stopped working. Now I can't even login to my account... Is there any chance I can got my money back?
What message do you get after trying to login to your Mistertango account? Have you tried to contact their support. Their cards aren't working for a long time already, it's not likely that new cards will be launched soon. But it's still possible to withdraw money to your bank account using SEPA or SWIFT transfer. On their website the login link did not work yesterday. And in the mobile app it said invalid credentials when I tried to login. Today I could log in on the website, but cannot make any transactions as it says it's under maintenance... Login in the mobile app still does not work with the same password...
|
|
|
I got about 350 USD on my account when the card stopped working. Now I can't even login to my account... Is there any chance I can got my money back?
|
|
|
There are effective Yescrypt GPU miners already.
|
|
|
Ethereum difficulty will be additionally decreased because GTX 1060 3 GB aren't working from today with such a big DAG file of Ethereum. I hope it is going to help increase the profitability of other rigs while Ether mining.
If Metroid is right, those 3GB cards won't make a noticeable drop in diff.
|
|
|
If I'd had a crystal ball I may have bought a Vega or 3 instead of all my 1070s but I reckon 3600 h/s @ 500W is pretty good no?
You can get that speed with 2 vegas @ 400W total power (cpu not hashing)
|
|
|
@playfast I don't wanna be spiteful, but 450h@36W(at the wall) is barely possible. As all polaris GPUs are 100% consistent in relative consumption it would mean an RX 570 can do 900 h/s at 72W but it can't. (or very rarely at least, 1 out of 100 cards maybe) Did you measure it with killawatt or it's some 'calculated' or GPU-Z value?
I have msi 560 that came with hynix mem and later core steppings, 1050 mV at stock core clock 1196. They are great undervolters, doing 895 mV at 1180 on v8, they could do 885 mV with v7. gpuz reads a solid 36W, kill-a-watt doesn't go over 40W, bounces between 36-40W. They were doing 29-30W on v7, so power consumption went up around 20%. OK, so ~40W at wall, that's more realistic. I found my 550/560s need more voltage than 570/580s for the same freq to be stable, usually 1000mV+ for 1250MHz. But OK, maybe MSI 560 is a good series.
|
|
|
@playfast I don't wanna be spiteful, but 450h@36W(at the wall) is barely possible. As all polaris GPUs are 100% consistent in relative consumption it would mean an RX 570 can do 900 h/s at 72W but it can't. (or very rarely at least, 1 out of 100 cards maybe) Did you measure it with killawatt or it's some 'calculated' or GPU-Z value?
|
|
|
I've managed to lower the consumption with a new PPT mod what I made. GPU-s clocks set to 1408MHz running on ~1350-1360 @0.8375V. 2 of my 11 GPU-s are not stable on 0.8375V. Those need 0.85V to run. In a 6 card rig (ref vega56@64) before this mod all of my GPU were at 0.875V (0.8688V sometimes). The consumption was about 1250W with 2*750W EVGA GQ 80+ Gold (6 additional 12cm fan). Same rig with 4 GPUs running on 0.8375V and 2 at 0.85V the consumption is about 1160W. Regfiles --> https://drive.google.com/open?id=1OvKJbv7psAO59I8EavFH5704wf7sr_9zSet HBM P3 voltage to 860mV to 0.8375V GPU. Set HBM P3 voltage to 880mV to 0.85V GPU. You can go even lower. I'm still testing 0.825V (GPU P7 to 830mv, HBM P3 to 850mV) For a short run it seems that 7 out of 11 GPU run even on 0.825mV. Crazy. Hi mate, please enable your private messages because it would be good to talk, but I couldn't send you a pm. (köszi) BTW my Vegas are consuming 200W/card at 0.95V that gives only 160W/card at 0.85V so something is not right.
|
|
|
@ut3wt: make sure crossfire and ULPS are disabled.
yes all GPUs are disabled ULPS and crossfire Maybe DDU and install 18.7.1 drivers? I see you have 000 and 001 there but no GPU are installed on these reg values. You can try to delete them before doing DDU and see if it's working. I had 20x Vega64 on Blockchain drivers, for Monero V8 I did DDU Blockchan drivers, installed 18.7.1 drivers, applied Soft Power tables, Disabled Crossfire and ULPS and all 20 of them are hashing at ~1900 h/s now on MoneroV8. @ut3wt I got the solution. I went through the exact same suckage yesterday till I found the trick. The driver does not give a single f*ck what's in the registry! I reinstalled the 18.6.1 driver multiple times and manually set those values in the registry and after reboot I checked in AMD Settings and CF was still ON! I had to manually turn CF off in AMD Setting and the 2 out of 6 cards that were previously hashing at only ~100h/s got back to normal with ~1850h/s. Now all 6 cards are hashing fine with 18.6.1. I had to remove prev driver with amdcleanutility and install 18.6.1 from scratch. I also switched to Compute mode, but that my not matter for Vegas. FYI: BC drivers are shit at V8 indeed. Only ~700h/s
|
|
|
It's certainly not 1 as the two numbers are different.
It is 2.a71b9f575904a, that is ~2.1 in decimal. But that diff is too low.
There must be some other conversion for the mix digest that I missed. Maybe others could help.
Your target worker diff is FFFFFFFFFFFFFFFFFFFF ÷ 0112e0be826d694b2e62 = ee.6b27fffffff8
that is ~238.6, it couldbe a valid worker diff.
|
|
|
We are in a special situation as used GPUs won't get significantly cheaper but mining profit does not seem to change either (not to the upside) considering all the coming new mining HW (FPGAs expecially).
|
|
|
Diff = 2^N / Hash
Replace N with the binary length of the output of the hash function (usually 256)
|
|
|
Your question is like a unresolvable paradox. If I say yes, then maybe I just want to buy your GPUs cheap. But what if I'm dumb and I tell you it's really a good decision to sell them right now and we break down the prices by dumping a lot of used GPUs onto the market....? I'd rather say nothing at all. The good time for selling was about 6 months ago.
|
|
|
I don't know the getwork protocol, but I looked at the Wiki ( https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_submitwork) It says that 3rd return parameter of eth_getWork is the target calculated by the required difficulty so the hash of your found share must be equal or lower than that, that is for sure. The 3rd param of eth_submitWork is the "mix digest" that is your hash value. But there is something wrong with your example, because 0x6080c976b37988aff954eab92f284afcfc40f84be17ebb5cc3af39b03fad1c58 is bigger than 0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba where it should be lower. So according to the Wiki the formula is target = 2^256 / difficulty. So that means the difficulty of your share = 2^256 / your mix digestthat is 2^256 / 0x6080c976b37988aff954eab92f284afcfc40f84be17ebb5cc3af39b03fad1c58 Here's a very explanatory diagram how ethash works: https://www.vijaypradeep.com/blog/2017-04-28-ethereums-memory-hardness-explained/
|
|
|
Yes, if i understand correctly, Lets say the block needs X zeros to be solved and you be rewarded, for simplicity sake lets call this difficulty to solve a block is 100, so if your share has a difficult of 100 or bigger then you solve the block, your share having bigger than 100 difficulty also solves the block but you get no extra benefit. If you mine a share at 10 difficulty or 50 difficult it also does nothing as it doesnt solve a block, however since a pool is trying to pay for work done so luck (but you dont care about this). So lets say a pool set your difficulty to 10, this means shares with difficulty of 10 are counted as 1 share (worth 10 points), even if you manage to get a 100 or even 1000 difficulty share the pool will not give you more than 10 points. If your difficulty set by pool is 20 then shares mined under that will be deleted and every time you have a share with a difficulty bigger than 20 you get credit for 20 points exactly. Understood?
The pool measures your hashrate by the number of your submitted valid shares that has difficulty greater than your worker diff multiplied by your worker diff. Your Work = (Number of your valid shares) * (Worker diff)It does not matter at all how much is your found share's diff above your worker diff regarding your payment. So if you have worker diff at 10, nobody cares if your share diff is 15 or 50. It only count as one share. Of course if it's above the network diff then you solved a block, but you won't get a bonus for that from the pool, because the reward is split according to only the (number of your shares) * (worker diff). Ksin:The exact answer for your question is that difficulty is measured in hashes.In your example 17.799G diff means that finding a share with that many leading zeros takes 17.799 x 10^12 hashes in average. https://ethereum.stackexchange.com/questions/29784/what-is-the-unit-for-measuring-difficulty
|
|
|
|