1.8.1.3 Pre-release

[DillonN]

Please post issues related to the pre-release here!

If you would like to help out with testing, some areas that would be particularly useful:

• ClaymoreDual

  • Ensure that CD uses the correct cards, particularly in NVIDIA/Mixed setups. Claymore stated that NVIDIA indexing changed in this version, but in my testing there were no changes to be made in NHML so if others could provide input it would be helpful. If you wish to remain on the pre-release and do have a problem with indexing, you can safely overwrite with the last version of ClaymoreDual since nothing in NHML changed for this.
  • Ensure that CD windows for one device do not restart when another device switches algorithms (unless that restart would be necessary for the switch, e.g. the other device is entering or leaving the same CD instance)

• xmr-stak-cpu

  • Ensure that benchmarking and speed display work as expected

Thanks!

EDIT: There is also now a page on how to change ccminer/sgminer paths: https://github.com/nicehash/NiceHashMinerLegacy/wiki/Customizing-ccminer-and-sgminer-paths. Testing that would be great as well! Note that not all errors in the file are handled in the first pre-release so try not to change anything but the path itself. You can always delete the file and NHML will make a new one on next launch with the defaults.

EDIT 2: Pre-release 2 is out. Included is a possible fix for the CD indexing anmong other things.

Please keep this discussion to pre-release issues only. If you have an issue that is also present on 1.8.1.2 or prior versions, make a new issue (after searching to make sure it isn't already posted)

[ChriscomIT]

Thanks for the prerelease. So far I found no issues. XMR features (benchmarking, stats, ...) definitely working for me. CD indexing seems to work also proper. Ccminer feature still needs to be tested. Great work @DillonN, as always!

[DillonN]

@ChriscomIT thanks for letting me know!

[ChriscomIT]

Nobody else reporting smt... looks like a clean pre. Ccminer pathfinding works as intended too 4 me btw...

[rbj325]

I noticed performance issues on my GTX1080(Non Ti). Hashrate was significantly slower($1.80/day to $.40/day) on Equihash(EWBF), Lbry, DaggerLbry and DaggerPascal. The GTX 980 on the same computer was about the same using both releases. Did not test on any of my GTX1070s due to network issues.

There were no errors so I'm not sure if logs will help?

Edit: I also confirmed latest drivers, etc and 1.8.1.2 is working normally with the same setup.

[lmlim]

CD now indexes cards according to afterburner order, but NHML indexing is still the same as previous. i have not tested this thoroughly, but in one run, EWBF on 1 NVID card gives very low hashrate, possibly conflicting index with my AMD card?

i reverted back to previous install until i have time to test again.

[streaml1ne555]

Retested my situation and it's fine. Disregard my prior comment.

[rbj325]

It looks like an indexing issue for sure. Both miner windows reference GPU #0 and disabling one of the cards gives me accurate numbers.

[ChriscomIT]

Guys, all of you with problems can you for god sake please post log files? Thanks in advance!!!

@rbj325 Can you give your hashing rate values, not the $ values, please. $ values are in no way an indicator of the performance (even they were significantly lower as before). Thanks.

[ChriscomIT]

@jackpot1136 Can you go troll somewhere else (or did ur mail acc got cracked)??? Thanks!

[ChriscomIT]

@jackpot1136 U was not. I literally could feel the sarcasm. BTW remember ur last 10 comments (I do!)? Ur answer says everything. My lil bro/sis actually are a hell lot smarter than you. Take my genuine FU and spread your cancer anywhere else or make some useful contributions. Actually, it seems you're just the script kiddie who cracked this email acc you're writing from.

[ChriscomIT]

Dude I really want to help you but your grammar is that confusing that I actually don't understand anything (are you drunk?). Thanks for your serious "thank you". I just take it as it.

So what else other you talking about I don't really know but if you just have 1$ balance than your not able to transfer it. Check the payout values, please. For internal wallet, the smallest amount is 0.002BTC.

As well this thread/issue is just for problems with the 1.8.1.3pre so if you have questions/problems with the service itself, please ask NiceHash support.

[ChriscomIT]

@deleted_user This helps a lot actually! Thanks for sharing!

[ChriscomIT]

@jackpot1136 Thanks for being one of the biggest retards I ever met and thanks for spamming various projects. I finally reported you now to GitHub and I hope they get you banned very soon. Have a great day!

THIS IS NOT YOUR MAIN LOG FILE... stop it!!!!!

[ChriscomIT]

@deleted_user Thanks, good to see I am not the only one! This guy is that annoying (not only here) I hope they kick em off the platform asap. Is it correct that you experience this with every miner, not just ClaymoreDual?

@jackpot1136 You have some real serious issues. Don't worry it will be taken care of. BTW that are not even logfiles from NiceHash app (its logs from ethereum blockchain transactions) who you are trying to fool. Would be fun to see how your backup ur big mouth in real life.

[ChriscomIT]

@jackpot1136 Wohoo ur such a smart ass! Thanks for the continuous insults. Gets you banned even faster. You're blocked now btw.

[ChriscomIT]

@deleted_user Thanks for the heads-up. It looks like an obvious indexing error (device id getting not properly propagated if I am correct). @Dillon should easily able to fix it. Just wait for him to check the .log file.

Yep got you already in the first time ;-). That's exactly what your .log file shows as well.

[DillonN]

Thank you all for posting about indexing issues, as I said I suspected there may be problems with that but was not able to test many card setups. I'll try to get a new pre-release up that can fix it (for now you can copy over the bin_3rdparty\claymore_dual\EthDcrMiner64.exe from 1.8.1.2 which has the old indexing style, the benefits are mainly AMD anyway)

Please keep it civil people

[BaalMarduk]

Im testing with a new Gigabyte RX VEGA 64 card, mining Ether only with Claymore Dual Ethereum work well, I'm getting 44 Mh /s, I can mine hours without any issues. But if I enable dual mining with Decred then after few minutes the system will reboot automatically. I'm on Windows 10 64bit, I tried different AMD drivers (BETA Block chain Aug23, 17.8.2 and 17.9.1) and dual mining do reboot after some time with all of them. Anyone are getting similar issue?

[casnmar]

I'm having issues with xmr-stak-cpu. I have a Ryzen 1700 and I can't benchmark it or mine with it after the switch to 1.8.1.3 bin files. I am also running a 1080 Ti in this system if that matters, but it appears to be functioning normally. Also, I don't know which of these log files you need, so I have attached both. log.1.txt log.txt

[DillonN]

@casnmar you must use the 1.8.1.3 pre-release version of NHML, along with the newer bin files. Neither are compatible with 1.8.1.2 files for xmr

@Jonbros01 do you get this behaviour if you run ClaymoreDual manually, i.e. without NHML using the same startup command? (If you search your logs for "starting miner" you should be able to find the startup command used)

[BaalMarduk]

Yes I'm using the 1.8.1.3 pre-release. I didn't tried Claymore Dual manually only through the NHML...

That being said now I have been able to make it run properly with the AMD 17.9.1 drivers in Dual. I was doing the tweak to set the memory to 1100MHz (1.356V), but I figured out how to keep the voltage of the GPU at 0.825V with those drivers and now its not rebooting anymore, its running perfectly in dual since last 6 hours!!!. I'm getting 39Mh/s in Eth and 110Mh/s in LBC. system is taking only 240watt total.

(Note: Beta Blockchain still crash in DUAL, but cant get the low voltage on GPU and its consuming about 400Watt)

[casnmar]

I actually was running 1.8.1.3 sort of, I had just overwritten files in the old directory as opposed to a "clean install" and I guess there was some cross-talk or maybe I didn't replace a file or two. I made a clean folder for this one, re-extracted it, re-ran benchmarks, and it solved my problem. Thank you!

[DillonN]

@casnmar from your logs it looked as though NHML itself was still at 1.8.1.2, glad it's working now though!

[DillonN]

There is a new pre-release, @deleted_user if you are able to test your CD indexing again that would be helpful!

[DillonN]

@deleted_user good to hear, thanks!

[rakeesh]

performance drop amd instabillity for my old amd HD6670 card using claymore cryptonite. Went from a steady 107 kh/s at 1.8.1.2 to a random 0-90kh/s at 1.8.1.3 pre2 wich slows down my pc. log_rak.txt

[Nicheuji]

@DillonN I'm still getting better hash rates with XMRig for CPU mining (i5-7500) even after factoring out the 1% dev fee (Fee can be set to 0 if you build it yourself) Please refer to #226 Thanks in advance

[rakeesh]

I also get frequent disconects, especially from the european server, getting "SOCKET ERROR- RECEIVE error" for xmr-stak-cpu miner and "Cannot establish SSL/TLS conection" or " Job timeout, disconnect, retry in 20 sec" for claymore cryptonite miner. When that happens I cannot connect for a time frame of minutes to several hours. The same was true for the previews version. log.txt

[rapra]

I cant download files with NHML and also bin - NHML is empty, bin is stopping download on about 25% progress. General issue report: NHML (now I am using 1.8.1.2) is causing display driver crash on change of miners - very often, about 30-40% of switches causes a crash. I am using overclocked GTX1060 - +666MHz mem to mine daggerhashimoto a lot faster. I must watch and reapply overclock after switches of algos, or mine only daggerhashimoto if I go outside. Yesterday @derubm wrote on ethminer by chfast site, that problem is caused by nvidia driver - driver is trying double overclock on miner closing/exiting. So maybe it is possible to ad (for testing or for good) a feature: before closing miner suspend a thread of the miner (like with option 'work on idle') - maybe it will prevent that effect of the driver and making work on overclocked gpu stable?

[derubm]

Yesterday @derubm wrote on ethminer by chfast site, that problem is caused by nvidia driver - driver is trying double overclock on miner closing/exiting.

i think there is a missundertanding. in many cases, when you close / shut down the mining process, nvidia drivers switch into P0 state (sometimes it gets stuck on P0, sometimes it switches back to P2), which causes ramspeed adding extra 200 mhz, which can lead ( in cases of high Ram overclocking) a freeze / crash of the system or crash of the graphic driver. you can watch this behavior when running high memory speed, close miner - and watch a monitoring tool for your GDDR5 memory. ( Afterburner etc ...) this happens only when you close/kill / restart the mining process. so idling while waiting on a new work does NOT show this activity.

see screenshot (closed miner with save memory speed and restarted some seconds later)

https://imgur.com/a/StFYK

[rapra]

Oh, now I see what do you mean. But it is not my case. I set memclock at fully stable frequency after testings in Furmark, it is going on +666 without any artifacts for hours. Problem of 200Mhz is a bit different: driver is setting -200MHz just after start any miner (I think, that this is a kind of save-mode from nvidia with CUDA operations on card are started. When you close miner, frequency is going back to default (set by afterburner for example). Please run Furmark in windowed mode, read mem clock, then start/close miner and observe mem clock - it is always set lower for 200MHz with CUDA on board.

[derubm]

this leads us into the problem that you set the memory on max frequency you can get with that -200. after miner exits, p0 state snaps in and adds those 200 to your allready oc´d card ("fully stable@ +666 in your case +200 = @866 (not so save) so ( i asume hynix memory) to much) . puff and there goes the gfx driver. ( no artefact or anything, just drivercrash / freeze etc..) if you get artifacts, your memory is prob. allready done. - check imgur link below image to see p states , posted them there. w/o restart p0 state stays. ( which is not like it is before mining )

[rapra]

Please... read once more what I wrote, don't treat me like a dumb, I am not novice. I set frequency tested as fully stable in P0 state in benchmarks. If miner is started, that frequency going down by 200Mhz from this frequency (this is 200MHz less than tested before fully stable frequency). When miner is closed, frequency is going back to that stable frequency, but driver often crashes . Most often it crashes with eth+lbry (almost always), x11gost (very often), with eth ocasionally. What is my proposal: maybe function killing process could suspend it before kill - maybe it would help. This is my proposal, and imo it would be easy to provide in code (program has functions to suspend precesses in 'work on idle' mode), I not ask for invention of wheel.

[streaml1ne555]

You could try nvidiaprofileinspector and disable CUDA P2 State (section 5) see if it still crashes when stopping the miners.

[rapra]

@streaml1ne555 this is it! I previously tested that program but in another version, and it wasnt that option. In google I also found, that GTX1060 has disabled P0 state and works in P2, so I didnt search anymore. In addition NHML P0 state enabled also didnt works - I had always P2 with miner I changed that option, and voila! A second after start miner on +666 hard freeze, at least! No I will test setting, but first fast tests showing that +580-590 could be the real limit. There is a big advantage in hashrate when forced P2 state on cuda by driver is disabled. Previously I had 23.3Mh/s (2666 - 200 = 2466MHz), now it is 24.0Mh/s (4566MHz). Thank you so much @streaml1ne555!

There is a work for Nicehash team (I am to lazy to revert settings and look at registry): with GTX1060 (maybe more) P0 state enabler dont works, but nvidiaprofileinspector 2.1.3.6 (exactly that version) works well. It could be great if you will inspect how that tool works.

@jackpot1136 no problem, situation solved.

[rapra]

Or maybe using this tool with command line options: https://github.com/ethereum-mining/ethminer/issues/202#issuecomment-318523568 You could add to nicehash custom overclock options for different algos and cards to make it easier and automatic. For example for eth I use option -400 gpu, +566mem (still testing), 60% power target, 66 temp target, for other algos I change that to +100, +566, 80% power target, 75 temp target. If it would be automatic...

[streaml1ne555]

Keep in mind, every time you update drivers, you need to run nvidiaprofileinspector again to disable P2 Cuda states. It always resets here, which is annoying.

[rapra]

@streaml1ne555 thank you, I know oc/hardware better than women. We have a resolve for GTX1060, this is most important

[dinicthis]

back to 1.8.1.2 I think...

[dinicthis]

S E R I O U S L Y ? 0.36 BTC per day with Lyra? Where I do I sign up?

Benchmarking is beyond retarded or flawed, all the way over to insane.

[dinicthis]

And if you try to run the GPU AND CPU miners same time: Notice the Special Black Bar blanking out the entire area where profitability might be read, were it a functioning software. Sorry, Charlie!

[dinicthis]

So, you all just going to let this sit? The software does not work. No comment? No fix? Nothing?

[DillonN]

@dinicthis The freezing is being covered in issue #334, it seems to be caused by not following the upgrade instructions. The CPU miner bin is not updated and the old version is incompatible