 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
Left pane, second box down, "PowerPlay" there will be a value for "Max Memory Freq. (MHz)" and whatever value you have in there is the absolute maximum the card will accept.
Question for you iSuX (just cos I think you might have the answer). I've modded bioses with Polaris 1.6.7 and the One Click Timing Patch, etc. but I have noticed on the 570s that the max freq is 2250, with straps going up to 2000. However, when I try to OC above 2000 it just crashes. Anything 2000 and under runs fine. So, my question, do I need to be adding extra timings above 2000 to allow it to OC above 2000? I also see in the memory portion, there are freq and voltages up to 1750 mhz, but nothing above. Should I be adding in more freq/voltage pairs as well? Or is all of this unnecessary? Hi jeremyismer You ask an interesting question, and are probably already thinking on the right track to solve your problem. I've been thinking about blogging here on this topic, so thanks for the inspiration. Apologies if this is a bit off topic/Claymore. (it IS, but the question is here too). I can't claim to have the definitive answers, or even if this is "the" way to do it, but I can share what I discovered along the way, trial and error methods etc. What I noticed was, some cards have memory timings stopping at 2000 while others go to 2250. This seems more dependant on the memory type, than the actual card vendor or model. For example, Micron memory based cards, straps top out at 2000 on (most of) my cards, and these were the worst performers out-of-the box, but one click timing actually made them worse in some cases. What I think is happening in the firmware, is when an application/os is calling for a specific clock, (that is not specified in the table), the firmware is calculating that, (changing it), based on the scale/gradient as defined by the stepping and values in that table. For example, (simplified), suppose the top strap was 1000 and has a timing value of 100, and the application calls for clock of 1010MHz, the actual value would be scaled up to 101. So, when people start editing those straps, you have to think about how the firmware is going to be able to scale those strapping values, when you request some clock value that is NOT specially listed in the table. What I see is a lot of data out there, where people are editing, sometimes only the top strap, sometimes the top 2, 3, or even 5. Where that seems likely to screw up later on, will be with people trying to get every last single MHz out of it, and essentially requesting values that might not get scaled to something the card can actually deliver, or potentially values that don't parse. On tuning straps/mem type. Samsung: I've more or less given up on. It's a great performer out of of the box. All my efforts to increase MH/s were marginal in that respect, and questionable in stability. Ergo, I decided the potential gains were not worth the downtime. Time I can be using for those cards to mine. (Plus I only have 2 of them, so collective gain is not an incentive for me). Micron: This is my top performer, but was a lot of work and learning. But all those cards hash at a super stable 32.64 MH/s I shuffled 8 into a single rig, and sometimes think ethman is not refreshing, because those values change so little. lol. Hynix2. I have to confess, I'm not so happy with my results, and am working on that. (32.07 is my super stable average) It's tough man, you know, you struggle through issues get things working, take a breather, (if you're lucky ;-) let some time pass so you can assess stability, while all the time wondering, should I try to improve hash rate? What will that cost in down time, stability? It's a question of expectation, so I decided early on to numerically quantify expectation, in hash rate terms. I settled on my absolute minimum acceptable on the RX580 would be 32.0, and I mean SOLID, never seeing a 31.999 for example. (Claymore also helped me here, as his miner got faster, so I wouldn't claim all the credit there) So currently I'm in two minds with the hynix cards, evening pulling one into the dev rig, I need some ROI :-) Ok, so back to practicalities here. I'm usually pretty hesitant to get involved in posting about BIOS settings, there is potential there to damage or even destroy hardware, and that would not be nice for anyone. Also, I'm frequently astounded at how poorly some people follow instructions, even when those are crystal clear, and include advice to read it and ask first, if you don't understand. Of course, that's not directed at yourself, simply a general observation. So, blah blah "I take no responsibility, blah blah", you get the point. OK, so have a think about this from a different perspective. The firmware architecture is such, that we see a stepped scale. If one requests a MHz value that is specifically defined in that table, THAT strap value is used. Every other value, will be scaled/translated to something in between, (interpolated), or if set above the top step, extrapolated. Now, interpolation is going to be more likely to work, as it's always constrained, but not so extrapolation, that can only follow the gradient as crafted by the steps between the lowest and highest step values. Ergo, any value you set above the top step, is less likely to work, and the probability of failure increases with higher values. So once I theorised this, I decided to test that theory. I took the 300MHz strap value, and set all values in the table to that value. Expecting the following: No matter what value I requested between 300 and 2000, there would be no change in hashrate, because there was no scale/gradient in that range. (flat line etc) This proved so. I then changed this, so-called flatline BIOS ver, so only the 2000 value was default, and when I requested 2000, I got stock hashrate, while 1900 was more or less the same as 300, (a tiny big higher). Try to visualise that on a graph, and it makes it's pretty obvious what is going on. So, essentially one could, in theory, have claymore pick ANY number for the clock, 9000 for example, and provided 9000 limit is set, and 9000 has a specific table entry, that would at least be accepted, assuming the actual strap value was something rational like the original 2000 value. It's kind of a lookup table, or transform table if you like. Where I think most people screw up, is by flashing BIOS they downloaded from the net onto their cards, who knows what that does, every situation would be more or less unique, while perversely those same people probably have some "standard" expectation, (as do we all), but how does one expect standards, when working without a standard logical methods? (That said, I looked at LOT of those online BIOS while trying to work out what was happening in the firmware), so in that situation, having a bunch of random BIOS edits was useful to analyse. The next screw up, is if you are going to edit a bunch of strap steps, you should at least start by using one of those specific clock values, and take it from there if expectation is not met. OK, so, something else to think about. That table is stepped, each line has some Id, (not visible in the editor), so you can't simply add additional steps in there, well, you can't with any editor I have seen so far. This means you need to edit an existing entry, and those are sorted by the ID only, so you can't for example think, "oh, I don't think I need the 400MHz step, as I have 300 and 800, so I will change the 400 entry to 2250. Rough example, that table would then be 200 2250 800 1000 1600 But think about what that does to the curve on the graph. Fine if you use any of those specific values, but everything else would be a roller coaster value around the 2250 mark. Also, you need to think about how the card inits, so I decided it would probably be a bad idea to touch the lowest value, (200, 300 etc), that is the stepping the card will init at, as it uses minimal power, and equally, if it gets a reset from the driver, it needs to start there before clocking up. What I did was to edit the scale so I could make the last entry, (the fastest one), some value that was overclocked. I decided to pick 2250 on the RX580, simply because I knew it could be called, and meant I didn't need to test how to, (or even if), the MAX limit was editable, (and understood by the fw). Logic being, minimal change = maximum stability. Of course this means eliminating one of the lower, existing steps, and shuffling the rest of them up the list, which is kind of tedious in the editor tbh, and VERY easy to make mistakes, copy/pasting etc The method I came up with is this. Open 4 instances of the editor. 1: The stock BIOS for that specific card, (readonly etc, for reference and cross checking, typos or my screw ups) 2: The stock BIOS for that specific card, (same as above), but this will be the one I edit. 3: The previous revision (if I have one) 4: The BIOS with the straps I'm copy from, (if I have one) Eliminate distractions, interruptions, and lots of coffee if it's dark outside :-) Well, that's more or less where I'm at with trying to understand this topic so far, but work continues for sure. The aspects mentioned here, where I devised tests for proof, I've said so, but I'm open to debate on, (or anything I might write for that matter), but I decided I was confident enough in that proof, to move forward. Indeed some of this is purely theory, albeit observational based, but also based on more than a few years experience in related fields, and I'd very much welcome anyone correcting me if I've erred anywhere. Equally, testing was done on Sapphire, Gigabyte, Asus based, RX580 8GB cards, which is hardly runs the gamut, so I would make no claims this info applies to all and every vendor, model. That said, there is enough above, people can experiment on their own, and take full responsibility for doing so. @jeremyismer If you want to PM me, link/dropbox/etc your stock BIOS and best edit version, I can take a look, (include card make, model of course), I might be able to help you in a positive direction. Oh yeah, and here's a funny discovery, (that helped me understand more about the types of chips/archecture used, (you can Winflash the BIOS on a card, WHILE MINING with it in claymore) hahaha. Happy mining everyone. |
|
|
|
|
Surprise!
Greetings everyone.
2018/05/25 Windows Defender Virus Definition version 1.269.69.0 has identified a Trojan:Win32/Bluteal.B!rfn in EthDcrMiner64.exe
According to Microsoft, "This threat can perform a number of actions of a malicious hacker's choice on your PC."
What a bunch of wankers.
Likewise trendmicro.
Lets just list something, and give no specific detail, keep it totally moronic, and scare people, and big ourselves up, and sell more software.
What is weird here is, Defender had removed my exclusion on EthDcrMiner64.exe
This on a rig with NO windows updates permitted, only defender can update itself, but wholly typical of MS who gave us all win10, and therefore consider our computers belong to them, to do with as they see fit, when and where.
Relevance: This defender was last updated on the 23rd, Claymore 11.7 has been running for weeks before then, so clearly MS have only added this signature to the db in the last day or so.
Suggest you folks check your exclusions, (suggest exclude file ONLY, (not folder for example), exclude EthDcrMiner64.exe and check your existing exclusions have not been removed.
Happy mining.
|
|
|
|
18.3.4 fixed issues I can now use 10.6 with 46mhs again.. Still can't launch 11.7 just pops up then disappears. How can I get 11.7 to work?
Hey there There are 2 basic approaches to this. 1: Use the console, (CMD) and cd to the directory containing Claymore's executable, (EthDcrMiner64.exe), (and probably also containing your batch file, because if you're asking this question, is likely you're not so familiar with the console, setting paths etc. Not a criticism at all. MS have worked hard since win95 days to eliminate the user need for the console, and for the most part, have probably succeeded.) But with the console open, you can then run your batchfile and see the print out of the results, (and the console remains open regardless, unlike executing the batchfile directly from explorer or desktop shortcut for example.) 2: Look at your log file, (it will have all the same info as you see in the console), and a lot more. General advice on init fails. Read the Readme!!!.txt file (especially the last sections, troubleshooting advice etc) Read the History.txt file (as you mention you're using 10.6. Mr Claymore added a lot since then.) KISS: (Keep It Simple Stupid),(USN acronym, look that up if you're interested) But if you have a complex system, (rig), (more than 1 GPU), break it down, work with a single GPU until you solve your issue, then build it back up to multi etc. If you are still stuck, post your batchfile, info on hardware, make/model/qty of GPU, logfile, and issue etc. ""It" doesn't work" for example, is unlikely to encourage people to give up time and braincells to help you. Be specific, that you don't understand the problem is fine, but without providing detail, it's unlikely anyone else can help you. As your rig is apparently running on 10.6 but not 11.7, and assuming you change nothing else, this should be a pretty quick and easy problem solve. Some more detail would help here. Best of luck. Foot note, on cd From the console, (Command prompt, aka cmd etc), type cd (change directory), 1 space, followed by the path to the location of EthDcrMiner64.exe on your system. BE CAREFUL here, because you mention you have 2 versions of claymore on your rig, so make sure you know which version is where, (and you are really in the 11.7 directory). e.g. C:\Windows\System32>cd C:\Program Files\Claymore |
|
|
|
A noob question;
Is memory overclocking work with RX560? mine will not change by -mclock 2000 and got stuck on bios.
Hey there I'm sure what you mean by "stuck on bios" though?? (FYI, this statement actually makes no sense at all probably, because if the BIOS failed to init, (actually the VERY first thing when you power on a PC, before the CPU, or motherboard), then you would not even know that RX560 existed in your rig. FYI, the reason the very first thing in a PC that completes init is the GPU, is so the monitor is able to show the user what happens next, (the mb init and boot up etc). This is of course not always entirely true, if you have multiple GPUs for example, because the BIOS on the motherboard only waits for the first GPU to complete init, then it un-pauses and runs it's own init sequence. But when you say "overclock", that implies you know what the default clock is to start with, and equally the limits etc. One way to find that out would be to use GPU-z, which will display the defaults, and the current values. Like anything, there are limits, those can vary by vendor, model, etc, so one way you could find out about your card, (for sure, rather than believe what people might tell you), is to use ATIWinFlash to save your factory BIOS, then open it in PolarisBiosEditor. Left pane, second box down, "PowerPlay" there will be a value for "Max Memory Freq. (MHz)" and whatever value you have in there is the absolute maximum the card will accept. I could be wrong, but the RX560 is not such a common card in mining rigs, and I mention this because all the example batchfiles you see posted, are actually specific settings for specific cards, so don't assume you can use for example, RX580 clock limits (2250) on the RX560. Maybe you can, maybe you can't, check for yourself on your cards, as above, then you know for sure. Just out of interest, what hash rates are you seeing on the RX560, with what settings, (post your batchfile). Post a bit more detail, if you need help, problems you're seeing, expectation not being met, detailed info on hardware, enviro, drivers. Good luck. Thanks for the answer. Bios memory clock is set to 1750, and the memory is Hynix. My problem is; I cant use -mclock 2000 to set the memory clock by claymore, but I can set it with Overdriventool and wattman to 2000MHZ with no problem. Also I've tested and I can set it a bit more further to 2100MHZ with those programs without any problem, and its still solid rock stable. But again, I cant change it with claymore. I'm measuring all sensors and clocks with GPUZ, And for sure, with hashrate too. I've reached 15.758 MH with overclocking and undervolting with ease and no problem. For the info, This rig is my side rig, and I've set all others with RX580, not rx560. But as they're exist in my inventory, I should use them too. OK< but what is the "Max Memory Freq. (MHz)" for that RX560? Make, model of GPU? Actually, like I said, and rather than piecemeal this discussion, please post a PolarisBiosEdit screenshot of that card stock BIOS. Need to see the full picture here, otherwise it's impossible to provide meaningful advice. |
|
|
|
A noob question;
Is memory overclocking work with RX560? mine will not change by -mclock 2000 and got stuck on bios.
Hey there I'm sure what you mean by "stuck on bios" though?? (FYI, this statement actually makes no sense at all probably, because if the BIOS failed to init, (actually the VERY first thing when you power on a PC, before the CPU, or motherboard), then you would not even know that RX560 existed in your rig. FYI, the reason the very first thing in a PC that completes init is the GPU, is so the monitor is able to show the user what happens next, (the mb init and boot up etc). This is of course not always entirely true, if you have multiple GPUs for example, because the BIOS on the motherboard only waits for the first GPU to complete init, then it un-pauses and runs it's own init sequence. But when you say "overclock", that implies you know what the default clock is to start with, and equally the limits etc. One way to find that out would be to use GPU-z, which will display the defaults, and the current values. Like anything, there are limits, those can vary by vendor, model, etc, so one way you could find out about your card, (for sure, rather than believe what people might tell you), is to use ATIWinFlash to save your factory BIOS, then open it in PolarisBiosEditor. Left pane, second box down, "PowerPlay" there will be a value for "Max Memory Freq. (MHz)" and whatever value you have in there is the absolute maximum the card will accept. I could be wrong, but the RX560 is not such a common card in mining rigs, and I mention this because all the example batchfiles you see posted, are actually specific settings for specific cards, so don't assume you can use for example, RX580 clock limits (2250) on the RX560. Maybe you can, maybe you can't, check for yourself on your cards, as above, then you know for sure. Just out of interest, what hash rates are you seeing on the RX560, with what settings, (post your batchfile). Post a bit more detail, if you need help, problems you're seeing, expectation not being met, detailed info on hardware, enviro, drivers. Good luck. |
|
|
|
Hello guys!
Thanks a lot to the whole community! I appreciate any question and especially answer.
I have 2 workers, rx 570/580 ,
first worker 6 cards, second worker 4 cards.
Recently, came back to august blockchain drivers. As usually, difficulties arise after random windows 10 updates...
1st problem. For 1st worker, hashrates goes down... recently my cards gave 29 stable, now it's more like 26-27... - any advises?
2nd problem. for 2nd worker, I'm not able to use msi afterburner. could someone please assist me in pm or here how I can change (set up) core clock and memory clock manually?
after many attempts, i fear to do something wrong.
I'd appreciate any advices. Me myself is a very young noobie with no tech backgrounds. But it's all about learning, right?
Thanks any help in advance. just aim to put maximum from the setup I have, but every time I have around - 5% efficiency and I wish to do something about it.
I tried new drivers (October, november, april) but with them I have 21, 19, or even 16 mh/s while i remember seeing 27 and even 30...
Thank you, kowtow
Hey there, it's not really possible to give you any specific advice, as there is no detail about your rigs, hardware, os version etc. But what stands out are a number of common follies with prepping an mining environment. Most of the suggestions I could offer I've already posted, so suggest you take a look at those posts, last 2 weeks etc, and find the best best-practice methods that work for you and your rigs. A key point copied here below, (updates) but make sure there is a specific gain FOR YOU, (a problem YOU have, that is documented solved in the update), otherwise you probably don't need it or the hassle. Dedicate your rig for mining, no wallets, no web browsing, no exceptions, keep defender (or whatever) ON, and set exclusions only if need be. Mining and stability go hand in hand, and keeping the OS as lean as possible, OS updates disabled, (set all NICs to metered connection), and manually control/manage how/when you plan on updating, (if at all).Side note: Why did you go back to the blockchain drivers? Those were and are Beta, they are also very old now, the releases since, have rolled up those refinements, and so choosing an old beta version needs some explanation. (Don't forget to use the -y 1 parameter, or lame AMD setting to set all cards to compute) Side note: I never allow ANY windows updates on my rigs, all have stock OS deploy, and all update services removed or disabled. I consider the OS a throw-away item, if it gets trashed, I redeploy the stock image, and so far, have never needed to do that. Use CCleaner to remove all the MS garbage, all the tiles and crapps, all the xbox rubbish, EVERYTHING you can remove, remove it. Keep your os firewall on, make sure you know how to use it, and what exceptions and rules are in place, stay behind a hardware firewall, dedicate the rig for mining, no email apps, no browsing as I said, don't install anything else, keep defender up to date, and scanning and secure the hardware, and you're pretty much safe for the most part. Remember, most security breaches these days are by tricking you to do, (install) something you don't want, or expect to do what it advertises to do. Ergo, YOU are the biggest risk, not Microsoft, or whatever vendor. If you need any convincing of the unsuitability of changing the OS with constant updates, look no further than this very page in this forum. Or almost any page for that matter. Bottom line is, we all want our rigs to RUN 24/7 and stable, so why people see the need to destabilise them with updates is a question worth asking. Stability = unchanging! End of debate on that subject if you please. Finally, if none of this helps, summarise (itemise) your hardware, versions, expectations, batchfile, and results. Essentially, be specific and detailed, otherwise advice will be best guess, and probably well off the mark. Good luck. |
|
|
|
2 Big problem I have and I'm sure its happened to many others:
1- Claymore dont recognize gpu temp and fan speed but GPU0 if you connect with RDP and run claymore there.
2- Windows update 1803 ruined everything, and no more claymore running or ATIFlash after updating to 1803. Damn microsoft for that.
Did you look at the Readme!!!.txt Funny Claymore as added more !!! to that file name, but with posts like this, it's no surprise. I wonder if Readme!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.txt would help ;-) Why did you update the OS? What problems did that solve for you? |
|
|
|
OVERLOAD!
Background:
In the early days of my mining project, I had managed to get 2 rigs stable.
They were built in succession, so the RIG1 had been running non-stop for some 7~8 weeks, ahead of RIG2.
These rigs used a few different PSUs, all Corsair 1000W, RM1000x, HX1000, HX1000i.
At about the 3 month point, RIG1, hit a bump, "random" reboot, (it's was running a USB watchdog, so I was unsure if this was the trigger, and disabled it for testing purposes), equally, event logs only mentioned kernel power, which is pretty vague.
Fortunately, things went downhill fast, and I stripped the rig down for inspection.
Cutting to the chase here, the problem was traced to the SATA/Peripheral 6pin plug on the PSU itself.
In this case, the connector was melted on the 12V pin, the pin welded into the cables socket, and all the insulation crumbled on the plug/socket, and melted some 2cm up the wire itself.
Now, I had failed to appreciate a number of things, and these are worth sharing.
The plugs are rated 10A, but in reality, one should not assume to work anywhere close to that "limit" for 24/7 operation.
Usually about half that is a safe maximum.
Why I didn't pay attention to a glaringly obvious stupidity on the part of Corsair is my own fault.
The Corsair, (and cables of all the PSU vendors for that matter), all have 4 Molex connectors in parallel. Now each Molex is rated to 10A, so how can one expect to pull half that, x4, (20A) through a single 10A plug/socket on the PSU?
Or if you want kindergarten logic, pull 4x 10A (molex) (40A) through a single 10A outlet?
I had stupidly assumed the PCIe risers were mostly inert, as power would in the whole come direct to the GPU.
WRONG!
In all cases I had used all 4 of those cable headers, whether those be molex or SATA power, and in all cases there were clear signs or damage after 3 months. (<2 months on rig2!)
I've rewired all my rigs, maximum 2 devices (PCIe risers, SSD, relay, fan-banks) per cable.
The Corsair PSU in all cases failed to trip safety cutouts, at least the HX1000i didn't log that it had, the RM1000x and HX1000, have no datalink so maybe they did, I have no way to tell.
But equally, this kind of failure is unlikely to cause a trip out, because the PSU is actually delivering LESS power, as current flow is inhibited by the degrading plug/socket!
I shipped 3 PSU back to Corsair.
Signs to look for.
Has a previously stable rig, become unstable, and you didn't change anything, drivers, hardware, etc?
Do you have more than 2 devices on a single power cable?
Checks/Inspections
Power off all PSUs, remove AC plugs, then remove the cable-sockets from the PSU outlet plugs.
Inspect the pins in the PSU outlet plugs.
Warning signs include: Pins no longer shiny/silver/gold, but dull, oxidised, black or burned.
Gently flex the cable near the FAR end of the cable, (farthest from the PSU), this should give you a feel for GOOD cable flex, (normal for THAT cable). Now repeat that flex-test at the other end of the cable, (right where it comes out of the PSU plug).
If you feel less flex, or it could be like a solid rod, no flex, that is a clear sign of overload.
This is a vicious cycle, as you overload, the wires heat up, they expand and abraid on each other, and oxidise. They do this more, right next to any connection, because there is a break in the insulation, allowing the ingress of air, and the oxygen component accelerates the oxidisation. The cables loose flexibility because of this, and also heat up more, accelerating their demise, in extreme cases this will melt away the wire insulation, and even the plug/socket.
If there was ANY human element during manufacture, (skin oils on the wires during handling, crimping, poor stripping, stand damage, poor crimping, bruising), these will drastically increase the likelihood of failure, especially if you pull more current through them.
ALL these signs were present on all my RIGs!!!
All have been rewired 2 PCIe risers per power cable, and 6 weeks on, all reinspected and there were no signs of degradation. A further inspection was done 2 months later, and again there were no signs of overload.
I have a feeling there will be MANY miners out there, who didn't give much thought to plug/socket ratings, and trusted the vendors would be using safe practice, WRONG!
Think: National Lampoons Christmas Vacation, (the Christmas lights scenes), because Evga, Corsair, and all the other vendors are shipping time bomb cables, and NO WARNINGS on them, or the PSU manuals.
Using 3 of the 4 headers might be ok, I opted for maximum of 2, because this is standard/safe practise in situations like this.
REPEAT:
Signs to look for.
Has a previously stable rig, become unstable, and you didn't change anything, drivers, hardware, etc?
Do you have more than 2 devices on a single power cable?
Finally: Don't jump to conclusions about Claymore or OS, or drivers, until you're satisfied the hardware is OK!
Good luck everyone.
Sorry to rehash the whole post, but damn I wish you had posted this two months ago - i spent weeks and plenty cash changing so many components only to find them burnt on the SATA connections on the psu port. We always look at risers etc but the real cost here is psu as they cost the same as a gpu and it isn’t safe based on this principle on a 6 card rig anymore. Cheers iSux- thanks for sharing Ahhh, man, I'm sorry, you are right, I should have got around to posting this earlier. ACTUALLY, in my defence, I DID write this up back in March, had most of it down, and palmed some key combination, (bottom left of keyboard), and the bitcointalk page refreshed and I lost the lot, I walked away in frustration, and an hour something lost. Actually that has happened a few times before, since, and even this morning, I have tried to work out what the hell does that, but it's bloody annoying. For bigger replies I use notepad now and paste in here. Anyway, I feel your pain man. BTW: It should be obvious, but I'll point this out now, as it missed this draft, FIRE FIRE FIRE! Running rigs, (a lot of fans), these actually do a fine job, pardon the pun, of chopping up airborne dust, in fact, the added airflow scavenges dust, with added convection, a fine coating of dust will accumulate over time. If you're not already considering it, I'd suggest scheduling a regular maintenance window of down time, to clean and vacuum away as much as practically possible, (heat sinks, fan blades, any area with a heat source). In reality those heat sources (e.g. chips) will not be enough to ignite a fire, but they will hold an accumulation of flammable dust at a nice starting level, ripe for a spark from a melted PSU cable for example. No need to overreact here, but if you're not thinking about this angle, you''d do well to consider it imho. Safety First! |
|
|
|
Built a new rig and my hashrate is down...
Old rig:
MB: ASROCK H81 Pro BTC 2.0
CPU: Intel Pentium G3260 (3.3GHz)
RAM: 8GB - 1333MHz
6GPU
New rig:
MB: Asus B250 Mining Expert
CPU: Intel Celeron G3930 (2,9Ghz)
RAM: 8GB - 2400MHz
updated Bios + Chipset to latest version
9GPU
Dual mining ETH+XVG with Claymore 11.7
Both times Radeon drivers 18.3.1, all compute.
4 of my cards that used to mine ETH at 30Mh/s and now do only 28,3 in my new rig... Those cards are on the same PSU I used in the old rig.
OC/UV used to be 1130 / 2035 / 890 / 890
Tried pushing them to 1130 / 2100 / 880 / 880, but I get minimal gain and seem to have touched the ceiling as I start getting invalid shares and have to get back to safer levels.
This might seem silly, but is it possible I have to flash the BIOS of the GPUs again as the configuration is different? Latest Windows10, so problems with ATIFlash to check... :-(
Thanks for any help
Hey there "Latest version" is not very informative, such things have numbers for good reason. Now, that said, there isn't enough data here for a differential analysis, nor any explanation as to why you are thinking, OC or BIOS as candidates. Assuming you didn't change either of those (OC/Bios) when you migrated your GPUs, from old rig to new rig, (did you?, as you mention 6 GPUs in old rig, and 9 in the new rig), so are 6 of those GPUs moved from old to new rig, and now seem to be hashing slower? What make/model GPU? Also, what is far more relevant here is, new motherboard, new ram, new cpu, new OS, new install of everything, and assuming you didn't change BIOS or Claymore config, I'd strongly suggest investigating all the former, before turning the spotlight on the latter. Some things to consider. What OS version on both rigs? IME Win10 Home version out performs Pro in almost every respect, gaming or mining. For one, it's loading a LOT less MS-crap that most people don't need. (If you're not joining a domain, you probably don't need Pro). The number of services is nearly double on Pro, and again, probably you don't need any of the pro stuff for mining. Mining and stability go hand in hand, and keeping the OS as lean as possible, updates disabled, (set all NICs to metered connection), and manually control/manage how/when you plan on updating, (if at all). FYI, I also have one rig on the B250ME, and have no issues with different hash rates given same GPU/driver/claymore ver. (I also moved GPUs to that rig, and from it, as I was able to consolidate same make/model/ cards on it) (mixed mem type still, and no issues). This has been so since day 1 with the B250. Where the B250 did become a pig, was getting it stable with the 12th GPU, and worse still with the 13th. That said, spot check, clocking through 75 hours, (claymore 11.7, Win10-64Bit-Radeon-Software-Adrenalin-Edition-18.3.4-March23, Win10Pro 10.0.14393) which is not a record, but I had to reboot last Sat), but the B250 is running well these last 4~5 weeks. (13x RX580) Sapphire, mix of Hynix/Samsung/Micron2, all on custom BIOS, all hashing >32. But as you asked, I HAVE seen some issues with ATIWinflash.exe, I've certainly taken some shortcuts, and regretted it. If nothing else, shortcuts add an element of doubt when analysing issues later on, and in some situations, you're unable to quantify those, (doubt remains). When working with networked systems, by "networked" I mean, multiple computers, (gpus), in a single entity, it's paramount to be systematic, anal always helps :-) Some tips. Note the serial numbers of your GPUs, backup the BIOS before you do anything, (use the serial number in the bios file names). Start off with stock BIOS, (for some days), so you establish a reasonable baseline of data. GATHER data, write it down. What is "normal" for each etc Make sure you know which GPU number (in Claymore, in GPU-z, in Radeon-settings), is which, and that way, you know what you are changing, (and can revert), and most important of all, DIFFERENTIATE when you see issues. I've seen stock BIOS on RX580s, as low as 18MH/s and typically no higher than 29MH/s. If you mod the BIOS, work on only ONE GPU at a time, version your BIOS edits, (CardMakeModel_SerialNumber_Ver) or something to that affect. Key point is, make SURE it's clearly identifiable. Get yourself a METHOD, you are going to end up managing and maintaining a complex system, there are a LOT of variables, so with a standard method, you can at least hope to rule out all the dumb human elements. Easier said than done, and one should consider "method" a work in progress, refine that as you go along, and maintaining rigs DOES get easier with experience, and systematic analysis. One thing about fine tuning BIOs: Initially I was struggling to break 30MH/s and made some mistakes, identified dead ends, had some cards that were real pigs, but actually turned out far better than I expected, even on more than one occasion considered returning. Try to use all the same make/model/mem-type of card if you plan on a small operation, (<10 GPUs). I don't say this to cherry pick, or exclude any vendor, but simply because with a small number of cards, it's very hard to know what ""normal" is for them. If you have only 1x Asus RX580, how do you know if it's good/bad/ugly? If you have 2 or more, you can at least hope to make some comparisons. Also, don't believe everything you read online, (and feel free to ignore me :-) but MAN I read a lot of utter RUBBISH online. In fact, finding the accurate data is the toughest challenge. One example, that still puzzles me, (note: puzzles me, not saying it's rubbish), is how many people rave about Samsung memory. In my experience, Samsung has been the best out-of-the-box GDDR5, but also the toughest to fine tune. In fact, I'd suggest it's not even worth trying memory strap edits with it. Drop the power consumption & core clock, up the memory to 2250, and you should be seeing 32.5, and stable. I wasted a lot of time trying to better that, only because I didn't see a big jump, and due to hype, assumed Samsung was the fastest. By the time I got my hands on my 2 and only Samsung GPUs, I had Micron running super stable at 32.6, up from 29~30 stock, and (mistakenly) figured I could see similar gains with Samsung. My present conclusion is, Samsung mem is already pretty tightly dialled in, so as an out of the box card, it's certainly the best I have seen, but it certainly is not the top performer in my rigs. Some notes on BIOS editing. Make sure you have a versioned stock bios file saved. Use THAT file for editing. (Do not use BIOS from the net). Depending on the card and editor, it's highly likely there are other bios elements that are not displayed or editable in the bios editor. Who knows what you change if you flash some random BIOS from the net. Make sure you have only a single card connected when you flash. (For SURE, I have done a enmasse deploy to 3 GPUs on multiple occasions, and in recent weeks identified that as a 100% confirmed issue). 2 different rigs, 1~2 cards started to show got incorrect share, after some hours. What was weird was, those were all cards that were mass-flashed. What solved that? Several things. Shut down rig, bleed down power, remove all but 1 GPU (usb cable), boot up, flash that one card, (I used the same BIOS ver for that same card as last flash), do NOT click ok to the "you must reboot message", but actually shut down, and bleed down the power. I have a suspicion the dual BIOs cards are capable of holding the BIOS in DRAM and not actually booting to the newly flashed BIOS. Sure, that will depend on the architecture of the card, but BIOS is typically EERAM, or some similar flash ram type chip. The card is NOT going to use this (new program), unless several things happen. A flag/trip is set, (by the flash app), to reload BIOS, (this seems to fail sometimes with Winflash), but for sure, what will force the card to load the new BIOS on next boot, is removal of power, (bleed-down), as this clears the DRAM, and leave the card no choice but to load from EERAM. Did you notice how slow it is to program BIOS? Those are usually 256 or 512 KB chips. That is KB, KB, nothing these days, yet flashing takes nearly 1 minute for 512 chips. Sure the write speed is slower, but even the verify is slow, and this is because the eeram is not intended to be fast, or used much, (written to), but is depended on to safely store data, without any powered backup. What typically happens is, as soon as power comes up, the dram content is crc checked with eeram, if ok, card boots, if not, it loads from eeram. As this happens at power on, before os init, that causes no delay in booting. What the winflash does is cause change in crc, and that SHOULD trigger the card to load the bios from eeram on init, but this has certainly failed for me. I saw no change in card performance after flashing. Stopped claymore, opened winflash, saved BIOS, and sure enough it WAS new, so flash was ok. I shut down, bled-down power, rebooted, and THEN I saw the improvement I was expecting. My point is, that winflash is only able to read the bios from the eeram, NOT from dram. Basically you can think of it much like your computer, eeram=hdd and dram=system memory. This architecture is not so by accident. The purest will also say you should not use winflash, but rather boot to a very light os, (Dos), and flash from there. This is actually very good advice, but I decided I'd use that as the fall back, and at least start out with WinFlash, as it IS vendor provided after all. But for sure, it has it's use case, and multiple flashing is a time-saver I've decided is not worth the gain. But at the same time, I've yet to see those issues insurmountable. OK, last work on OC. OC is pushing your luck, if you see issues, remember, you are pushing your luck. As for the silicone lottery, at least with Sapphire cards, having built rigs for a few people now, I've only had 1 card out of 30 something, that was clearly a dud. BUT the only way I can say that with certainly is because I documented all the 30+ other cards, (same make/model/memory), and no matter what I did to that one card, it was not stable with any oc at all. Is that the silicone lottery? I don't think so, I think it was simply a QC issue. I could be wrong, maybe someone with 100+ cards, data, and experience can chime in here. OK< last thing. Did you try setting the dcri? New rig has 9 GPUs, cmiiw. DCRI will be different for sure. Disable dual mining for a start, (pointless, no profit unless you have free power, and even then dubious imho). Try the "z" key during solo mining, and let claymore find the optimum. If those numbers are very different from your dcri value, (>2) then I'd suggest at least picking the mean for your config file. What happened to your hash rate after "z"? Side note, and no disrespect to Mr Claymore, but usually I find a better dcri value, by using the -+ keys, and set same for all gpu. But for sure, the z key is a nice feature and great tool to get you 95% optimised and quickly. Also, set -y 1 check your console during init and make sure you see both lines below. All AMD cards use Compute Mode already CrossFire is disabled already Otherwise, open admin console, start your batch file as usual, wait for the "all cards now use computer, please reboot" Reboot, and run claymore as normal, (no need for admin). THIS IS THE BEST FEATURE from Claymore of late, if you have more than 5GPU, otherwise it's hours of lame AMD-settings, and reboots, to configure each GPU. Finally, if still no luck, post your batch file, and some specifics on hardware/versions etc. Good luck. Thank you for so much good info. (In the meantime my rig is down to 8 GPUs, sold one together with the old MB) I tried working on the dcri value, hash got a little bit better, but I am stuck at the following values: ETH: GPU0 29.938 Mh/s, GPU1 30.101 Mh/s, GPU2 30.273 Mh/s, GPU3 30.097 Mh/s, GPU4 30.433 Mh/s, GPU5 28.517 Mh/s, GPU6 28.524 Mh/s, GPU7 28.521 Mh/s The last three GPUs reached 30 without too much overclocking on the old rig. I push the last 3 GPUs until instability (as you can see in my batfile), but it doesn't get any higher than 28.5 This is my current batfile: EthDcrMiner64.exe -tt 69 -fanmin 55 -y 1 -cclock 1130,1130,1130,1130,1130,1030,1030,1030 -mclock 2065,2035,2045,2035,2050,2100,2100,2100 -cvddc 886,890,889,890,885,888,888,888 -mvddc 885,890,889,890,885,888,888,888 -epool stratum+ssl://eu1.ethermine.org:5555 -ewal WALLET -epsw x -estale 0 pause GPU0,1,2,5,6,7 are MSI Radeon RX580 Armor OC 8GB GPU0,1,2,3 are on circuit A of the MB - PSU Corsair HX1000) GPU4,5,6,7 are on circuit B (tried C as well) - PSU LC-Power Platinum 1000W. Tried them first with the same BeQuiet 1000W PSU I used on my previous rig, where they reached 30Mh/s but even with this same PSU it was 28.5 on the new rig/MB. Bios of all cards flashed with their separate one-click-patch Polarisbios Motherboard Asus B250 ME - Bios 1010 (29-3-2018) Windows 10 Pro - 1709 build 16299.431 Any more tips? Thanks No worries. OK, what was immediately jumping out at me here, is how highly tuned your config file is. In comparison, I run all my rigs with identical settings for all GPUs, no card specific clock, voltage settings, (except 1 single card, an ASUS Dual, (a BAD choice I have come to realise, really REALLY shitty fans, 1 failed after 2 weeks, the replacement card failed 2 days after amazon 30day returns, anyway, I won't bore you with that story, but I down clocked it to keep it cooler). What I wonder here is why, with 6 identical GPU, do you have them dialled in so tightly? For sure that is accounting for the differences you see between those 6, do they have different memory? FYI, I've found Micron to be the best, (MT51J256M3 (MICRON)) also the one you'll probably read a lot of people moaning about too, and I confess, WAS a bit of a challenge, but also a learning curve for me. Samsung is very good, imho the best I've seen, out-of-the-box for mining,. Hynix and Hynix2, seem to be a bit petulant, and I probably need to do more work on refining those, but My point is, regardless of memory, I have no RX580 8GB cards running below 32MH/s, all have identical clocks and voltages, regardless of vendor. What I would say is, with your current config file, it's impossible to make any comparisons, and therefore any differential analysis is pretty pointless as it is. Also, your batch file is kind of a shambles :-) I don't say this as a criticism, but it makes it easy to make mistakes or miss seeing them, and I'd suggest you reorder that file, as per claymore examples. Also, I see some odd choices in there, why are you stratum mining SSL at Ethermine? Try this config, assumes you have populated your epools.txt file, you SHOULD get min speed 256, but I set this to 200 for now, otherwise you will get 5 min restarts below that level etc Make sure you have virtual memory to 48000, (should be enough, I have that on a 13GPU rig, with 16GB ram, no issues) setx GPU_FORCE_64BIT_PTR 1 setx GPU_MAX_HEAP_SIZE 100 setx GPU_USE_SYNC_OBJECTS 1 setx GPU_MAX_ALLOC_PERCENT 100 setx GPU_SINGLE_ALLOC_PERCENT 100 EthDcrMiner64.exe -epool ssl://eu1.ethermine.org:5555 -ewal WALLET.RIG -epsw x -checkcert 1 -epoolsfile epools.txt -minspeed 200 -gser 1 -esm 0 -etha 0 -ethi 16 -eres 2 -erate 1 -estale 1 -asm 1 -platform 1 -y 1 -dcri 9 -wd 1 -ftime 5 -r 14400 -cclock 1200 -cvddc 900 -mclock 2250 -mvddc 850 -tstop 83 -tstart 50 -tt 69 -fanmin 55 -fanmax 100 -ttdcr 80 -ttli 80 -mode 1 -dbg 0 -altnum 3 -mport -3333 -mpsw whatever -logfile logs\ Now, with your cards, claymore might not init with -mclock 2250, so if that happens, change that to 2100, (stock for RX580), and see what happens. If you need more help, please list each GPU number, make model, memory, and some logfile showing hash rate, it might be possible to spot something when every card is running the same settings, (or even stock settings for all is a good idea in this situation, as the data should be solid for analysis) Also, you could try running with the -di 0 parameter, (GPU0 only), and tuning that up, (probably dcri 4~6 will give better rates with a single GPU, but you will have to experiment on your own rig). To be clear, if I were approaching this situation, my working logic would be to break this down, it has 8 GPU, pick the worst performer, remove the others, and get that one GPU to 32MH/s something, by the time you get there, you should have the experience/know-how to apply to the others. If you have only a single rig, you can also run another instance of claymore with the parameter, -di 1234567 which will allow you to at least mine with the other cards while you focus on pumping up GPU0 to 32MH/s I'd also be interested to see a screen shot of gpu-z and polarisBios editor for GPU0, or GPU7. But for sure, something is very wrong there, (or those MSI cards are rubbish, (and I don't think I recall hearing they are, in fact a lot of miners use them, but I have none myself), but what I can say is, while I tried to stick with Sapphire, during late 2017 and Q1 2018, with shortages as they were, I ended up with some ASUS DUAL, (bad choice), Gigabyte Gaming, Aurous, (a bit tricky to bios edit initially), but regardless all are stable at 32MH/s, so your 28s look really painful man. Still, on the plus side , you have a nice gain of 28MH/s to aim for right now, and assuming those MSI cards are up for it, that should be achievable. Good luck man. Foot note: Thinking a bit more here, I wonder if there is a correlation with 28.5-ish rates and BIOS. There might be no connection of course, but it's interesting that 28-ish is usually what I see with out of the box BIOS. Then again, your clocks are all over the place, so hard to know. Worth following up on, if only to be discounted. |
|
|
|
@Claymore
Saw this today in my log file:
08:38:29:239 4304 checked ETH share on CPU, spent 4ms
08:38:48:975 43b8 checked ETH share on CPU, spent 3ms
08:39:09:055 43c0 checked ETH share on CPU, spent 3ms
Don`t think that is normal.
Nothing to worry about, this is totally normal. Look back through your old logs, (use grep for example), and you'll see it's a regular event in the log. Mr Claymore would be the only person who can explain why he's programmed this, but no doubt there is a logical reason. Side note: Generally, (assuming the programmer is not a total moron), log entries will have some prefix, or suffix, "warning", "error", "OK", "good" etc etc, which makes life easier when searching logs for problem events, or notable events you might like to check on. Conversely, if you don't see such annotations, and the log entry is not self explanatory, you can generally ignore such entries. (as in they are not things you need to worry about). And No, it's not a virus either. Thanks for your reply iSuX. I was just wondering why is there CPU share Thanks iSuX. I checked old logs and see that this event is in all of them. I never noticed it before. I was experiencing system instability yesterday, checked the log, saw this event, assumed it was a virus, ran virus scanner, removed viruses, and system went back to stable. IDK how I got a virus, but thanks for pointing out that it's not related to the cpu share. Like Snake, I would appreciate an explanation from Claymore for why the program is checking for eth shares on the CPU. Maybe it's checking for a virus mining on the cpu? @androstan1234 Bummer man, what virus was it you had? It was called coin-bitminer or something like that. First time this has happened to me in almost 10 months of mining. IDK how it happened. Maybe related to windows 1803 update since that's the only thing that's changed. But I updated both of my rigs, and both use the same router (really a 4G LTE hotspot). Only one caught the virus. On the subject of Virus, sigh, if you take 2 milliseconds to think about that, and you can probably assume a virus is unlikely to have your best intentions to heart, ergo, it's going to do something you'd rather not have happen, well, it's hardly likely to have the moronic goal of hacking the claymore binary to make it mine with the CPU or advertise itself, by writing it's own log entries.
Hahahaha.
I mean, people make stupid viruses, and stupid, lazy, and/or inattentive people fall for them. I figured, maybe someone found a way to force claymore software to mine on cpu and send shares to their wallet, thinking that a tiny amount of mining on a cpu would go unnoticed. A side effect could be that the claymore software dutifully reports and logs whatever is going on. If enough rigs get infected, all those tiny amounts could add up to a decent chunk of free money. I bet you watch a lot of sci-fi, lol, jk Joking aside, you make a lot of generalisations here, and while from a frustration pov, you might call a virus "stupid", probably understandably on an emotional level, but what you describe would be a highly sophisticated piece of software, IF it were even possible at all. In reality, if one had the time, money, resources and skills to pull that off, it would be highly unlikely you'd then advertise what was done in the logs. Hardly very stealthy, and ensuring alarm bells are going off everywhere. That ability/means would also be an exceptional asset, and one you would not squander on a poor gain, high risk, and advertising the fact. More or like less robbing every bank in town, and leaving your calling card, name and address at the crime scene, tripping the fire alarm for good measure, now THAT would be stupid. Equally, somehow decompiling claymore, and adding in code to CPU mine, recompiling, inventing some delivery method, (very challenging, very not-stupid I assure you), for some paltry gain doing CPU mining, something that would be very obvious to the user, when one already has a GPU miner application, and you could simply deploy a local man-in-the-middle method, and siphon off a share here and there, now THAT would give you some gain, could be quite stealthy, has been done already, the code is out there. Something to realise is, such actions are generally considered crimes, but these programmers are not stupid people, they are usually highly intelligent, and while their actions in use of their programs is probably stupid, that comes later, before then, the programming etc, is usually pretty sophisticated, cleaver, devious, and very well thought through and engineered, (so as to circumvent all the known detection methods). As time goes on, these programs get out there, get identified and tagged, and added to antivirus databases. This is also very big business, and is synergistic with malware, perversely a kind of malware in itself, but certainly reliant on malware programmers, feeding off them in fact. By this I mean, "I don't want antivirus software on my rigs, but I have to have it because of malware, which is just some other software I don't want". So, it's in their interest to tag as many applications as malware as possible. Why? Because it creates fear and worry in people, and makes them purchase anti virus software. Insurance companies have been doing exactly this for decades. Make people worry about something, then offer them "a solution", at a price of course, and one that ensures the insurance company is in healthy profit. In fact, if one looks specifically at Claymore, and how it's sometimes identified as malware, proves the point I'm making. He is an analogy. A kid goes down the street one night, gets into an altercation, and gets stabbed by a screwdriver. Weapon = screwdriver. A builder leaves site the same night, walks down the same street carrying his tool bag, are his screwdrivers weapons? The VAST majority of software tagged as malware, (weapons) are actually simply tools, what determines the difference is HOW YOU USE THEM. This is something the antivirus software vendors turn a convenient blind eye to, as they would have rather have you worried by the millions of malware items they have in their databases. Anyway, aside from all this, if I might offer some advice. If you ever get a detection, write it down, use a different computer to research it, make sure you know what it is, IF you need to remove it, and especially the method of infection. Otherwise you'll probably see it again in the future. While you might be right, there are a lot of stupid people out there, myself included at times, malware infection is designed to trick people. If you keep stepping on to the playing field, no matter how good you are, sooner or later, you'll be beaten. Does that make you stupid? |
|
|
|
@Claymore
Saw this today in my log file:
08:38:29:239 4304 checked ETH share on CPU, spent 4ms
08:38:48:975 43b8 checked ETH share on CPU, spent 3ms
08:39:09:055 43c0 checked ETH share on CPU, spent 3ms
Don`t think that is normal.
Nothing to worry about, this is totally normal. Look back through your old logs, (use grep for example), and you'll see it's a regular event in the log. Mr Claymore would be the only person who can explain why he's programmed this, but no doubt there is a logical reason. Side note: Generally, (assuming the programmer is not a total moron), log entries will have some prefix, or suffix, "warning", "error", "OK", "good" etc etc, which makes life easier when searching logs for problem events, or notable events you might like to check on. Conversely, if you don't see such annotations, and the log entry is not self explanatory, you can generally ignore such entries. (as in they are not things you need to worry about). And No, it's not a virus either. Thanks for your reply iSuX. I was just wondering why is there CPU share Thanks iSuX. I checked old logs and see that this event is in all of them. I never noticed it before. I was experiencing system instability yesterday, checked the log, saw this event, assumed it was a virus, ran virus scanner, removed viruses, and system went back to stable. IDK how I got a virus, but thanks for pointing out that it's not related to the cpu share. Like Snake, I would appreciate an explanation from Claymore for why the program is checking for eth shares on the CPU. Maybe it's checking for a virus mining on the cpu? @androstan1234 Bummer man, what virus was it you had? |
|
|
|
@Claymore
Saw this today in my log file:
08:38:29:239 4304 checked ETH share on CPU, spent 4ms
08:38:48:975 43b8 checked ETH share on CPU, spent 3ms
08:39:09:055 43c0 checked ETH share on CPU, spent 3ms
Don`t think that is normal.
Nothing to worry about, this is totally normal. Look back through your old logs, (use grep for example), and you'll see it's a regular event in the log. Mr Claymore would be the only person who can explain why he's programmed this, but no doubt there is a logical reason. Side note: Generally, (assuming the programmer is not a total moron), log entries will have some prefix, or suffix, "warning", "error", "OK", "good" etc etc, which makes life easier when searching logs for problem events, or notable events you might like to check on. Conversely, if you don't see such annotations, and the log entry is not self explanatory, you can generally ignore such entries. (as in they are not things you need to worry about). And No, it's not a virus either. Thanks for your reply iSuX. I was just wondering why is there CPU share No worries. I wondered the very same thing when I first saw those entries, but I don't think that means there was a CPU share as such. The CPU is not doing any mining computations in this Claymore, (note the subject header, "GPU miner". My guess was, Claymore has the CPU check the share was delivered, or check summed or against the pool. Purely a guess though, as I said, Mr Claymore would be the only person who can explain what his intentions are with this, so I could be totally wrong with that guess. What I can say, is those have been in logs since at least V11.2, although there is no mention of them in the readme or history. On the subject of Virus, sigh, if you take 2 milliseconds to think about that, and you can probably assume a virus is unlikely to have your best intentions to heart, ergo, it's going to do something you'd rather not have happen, well, it's hardly likely to have the moronic goal of hacking the claymore binary to make it mine with the CPU or advertise itself, by writing it's own log entries. Hahahaha. |
|
|
|
EthDcrMiner64.exe -epool etc-eu1.nanopool.org:19999 -ewal 0xa572dd9dcbcbe537e65c740f27cbd6de5b42a514/3 -epsw x -dpool stratum+tcp://mine.nlpool.nl:5133 -dwal DGr37NMCTSEXZqqPk7gHhikCCd3Ar2Py2b -dpsw c=XVG -dcoin blake2s -allpools 1
hi , i have 100% rejected for xvg
what I am doing wrong
Are you sure about your ETH address? That looks malformed to me. There should not be a /3 in that string. Update: looking at this some more, I don't recall "C=" or in fact that kind of method is being used by Mr Claymore. Note his syntax is a space and minus to indicate the next parameter, and I don't recall "C" in the documentation, nor the employment of the =. I could be wrong though, where did you get that config from? Ahh ok, sorry, are you meaning your password is actually c=XVG? That's a cheap hack I guess, kind of bizarre though, as the pool should do that via the address or the port. Anyway, some things to think about. Good luck. |
|
|
|
I'm using windows 10 version 1803 and nvidia driver 397.64. My vgas all are gtx 1070.
I'm stuck with this error....everytime I start the mining...in about 5 minutes or less I got these messages. I already lowered the OC via MSI and tried with no OC at all, but no luck.
These are the messages:
15:54:51:907 1098 ETH: 05/22/18-15:54:51 - SHARE FOUND - (GPU 3)
15:54:52:360 1098 buf: {"id":13,"jsonrpc":"2.0","result":true}
15:54:52:365 1098 ETH: Share accepted (453 ms)!
15:54:52:579 c24 NVML: cannot get current temperature, error 15
15:54:52:594 c24 NVML: cannot get fan speed, error 15
15:54:54:688 1884 GPU 7, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:692 1900 GPU 6, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:751 1360 GPU 8, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:754 1dcc GPU 4, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:759 9a8 GPU 1, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:761 b9c GPU 3, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:767 1700 GPU 2, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:799 140c GPU 0, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:819 14e8 GPU 5, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:834 12e0 GPU 10, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:836 11a4 GPU 9, GpuMiner cu_k1 failed 6, the launch timed out and was terminated
15:54:54:929 1884 GPU 7, GpuMiner kx failed 1
15:54:54:935 1900 GPU 6, GpuMiner kx failed 1
15:54:54:945 1360 GPU 8, GpuMiner kx failed 1
15:54:54:976 1dcc GPU 4, GpuMiner kx failed 1
15:55:00:302 9a8 GPU 1, GpuMiner kx failed 1
15:55:00:389 b9c GPU 3, GpuMiner kx failed 1
15:55:00:536 1700 GPU 2, GpuMiner kx failed 1
15:55:01:637 140c GPU 0, GpuMiner kx failed 1
15:55:01:638 14e8 GPU 5, GpuMiner kx failed 1
15:55:01:639 12e0 GPU 10, GpuMiner kx failed 1
15:55:01:639 11a4 GPU 9, GpuMiner kx failed 1
15:55:01:639 11a4 Set global fail flag, failed GPU9
15:55:01:645 11a4 GPU 9 failed
15:54:54:935 1900 Set global fail flag, failed GPU6
15:55:01:647 1900 GPU 6 failed
After these error, there is notification on windows that say : "Display driver failed to start;using microsoft basic display driver instead; check windows update for newer display driver"
I check it and all are updated
what's the problem?
This looks like an Nvidia driver crash. I'm not mining with Nvidia, but if you look back through your log, you will probably see (prior to this), Claymore is querying the GPU temperatures, and is expecting an ACK, I expect your log will show something like a GPU number, followed by temperature value, and possibly fan speed. What you see here is a failure to read out that data, and as that is coming via the Nvidia driver, and looking at the following entries, that would support the theory the driver has unloaded or crashedout. Some things to try. Remove all your GPU except 1. Download DDU, http://www.guru3d.com/files-details/display-driver-uninstaller-download.htmlBoot Win10 to safemode, (CTRL+SHIFT+restart), select troubleshoot, advanced, (sad that ms see that as advanced, lol), startup options, and on restart, numeric key 4 will enable safemode boot. Run DDU, default options, it will remove your Nvida display drivers, reboot to windows, and install Nvidia. Select a custom install, and install only the display driver, (you can skip audio, and experience for example), Less crap to worry about if things don't run with stability later. After install, reboot, and run claymore, (single GPU), and see if that works. BTW: Windows will fallback on the basic display driver, and in cases where it does not know of, (have installed), the vendors driver. Because you are seeing this happen, AND you clearly DO HAVE the Nvidia driver installed, (otherwise Claymore would bombout early init), then I suspect you have a corrupt install, reg entry somewhere. It's a weird one though, usually windows doesn't gracefully unload a peripheral driver if it's being used, and you'll get some kind of BSOD. Interesting situation, please feedback how you get on. Good luck with it too btw. Cheers |
|
|
|
@Claymore
Saw this today in my log file:
08:38:29:239 4304 checked ETH share on CPU, spent 4ms
08:38:48:975 43b8 checked ETH share on CPU, spent 3ms
08:39:09:055 43c0 checked ETH share on CPU, spent 3ms
Don`t think that is normal.
That's what happened to me yesterday. I had a virus. A windows virus scan detected and removed it. Jesus, let it go man. |
|
|
|
@Claymore
Saw this today in my log file:
08:38:29:239 4304 checked ETH share on CPU, spent 4ms
08:38:48:975 43b8 checked ETH share on CPU, spent 3ms
08:39:09:055 43c0 checked ETH share on CPU, spent 3ms
Don`t think that is normal.
Nothing to worry about, this is totally normal. Look back through your old logs, (use grep for example), and you'll see it's a regular event in the log. Mr Claymore would be the only person who can explain why he's programmed this, but no doubt there is a logical reason. Side note: Generally, (assuming the programmer is not a total moron), log entries will have some prefix, or suffix, "warning", "error", "OK", "good" etc etc, which makes life easier when searching logs for problem events, or notable events you might like to check on. Conversely, if you don't see such annotations, and the log entry is not self explanatory, you can generally ignore such entries. (as in they are not things you need to worry about). And No, it's not a virus either. |
|
|
|
use abcd
Minor correction here, you can use "abc" but not "d" This poses a problem, if you have a 13GPU rig, and use altnum -1 or altnum -3 to change from first GPU=0 to first GPU=1 You loose the ability in the console to toggle GPU 13 off/on, (you can still do this in ethman of course). Small bug for Mr Claymore. Happy mining everyone. |
|
|
|
There was a virus using claymore to mine eth on my cpu today. I use -mport 0. I leave windows defender turned on.
WOW, that would be quite a trick, as Claymore is not a CPU mining application to start with. Check your details, check your post, and suggest you correct the details, or better still, delete it. |
|
|
|
IM using windows 10 1709 build with 12 amd cards
I notice that my gpu 10 hangs opencl, I'll check all the cables and riser but all are okay, but Im using old driver.. Is my driver version is the reason why my card hang? What is the better amd driver is capable of this 11.7 version of claymore? Any help will appreciated!!
Such things can be frustrating, and the more GPUs you have, the higher probability you will see issues. But this same probability can be turned to your advantage, as you have 9 other "stable" GPUs to compare against. If you didn't recently change anything, or add #10, then I'd swap it with a known good GPU. e.g. Suppose you expanded this rig, from initially starting with a single GPU, (lets call that GPU1), and added 2,3,4~10 later, and only noticed this issue after adding 11~12. There would be 2 approaches. Undo the last changes, (remove 11~12), and see if #10 still causes the hang. or Exchange the position of #10 with #1. If you still see a hang with #10 (with #1 in the #10 bus location), you know it's probably not the GPU itself, (or the os, drivers etc etc), but something isolated to that node. (PCIe card, USB3 cable, Raiser, PSU cables etc. Note, all of these are hardware.) With 12 GPU, and always #10 hanging, it highly unlikely you have an OS or driver issue. I'd strongly suggest you investigate all your hardware, or even remove #10 from the rig, (see if you then get a hang on another #). Also, do a bleed-down power cycle, and if all this fails, (assuming all your GPU are same make/model), and you tested the above with no OC, and you still have the same hang, isolated to #10, (when moved to a different slot), you could have a bad GPU, or be overloading your PSU. If you flashed the BIOS on #10, revert to factory BIOS for that card, default clocks, and move it to a PCI16x native slot, (remove all the riser related hw etc). If #10 is an old GPU, and you've mined a lot with it, (check it's fans), clean it, try it in another rig would be additional suggestions. Best of luck. |
|
|
|
small bugreport:
mining didn't start if you set this two options at the same time:
-allcoins -1
-nofee 1
Did you read the readme? "-allcoins" and "nofee" section? Some real-world advice. If you're not going to pay for it, don't bitch about your issues! If you don't like the rules, (see the readme), you have very clear instructions right there. "you should find some other miner that meets your requirements, just don't use this miner instead of claiming that I need " etc etc. You might not like it, but it's honest, and you can't say you were not informed up front, and had a choice from the start. |
|
|
|
|
