Compiled from master, after a few minutes I get this. Mining on CUDA using GTX 1070's. Not sure what is this, the error is not very descriptive and I am not code wizz. CUDA error in func 'search' at line 365: unspecified launch failure. ✘ 15:26:10 cudaminer0 Error CUDA mining: unspecified launch failure CUDA error in func 'search' at line 365: unspecified launch failure.

✘ 15:26:10 cudaminer4 Error CUDA mining: unspecified launch failure CUDA error in func 'search' at line 365: unspecified launch failure. ✘ 15:26:10 cudaminer1 Error CUDA mining: unspecified launch failure CUDA error in func 'search' at line 365: unspecified launch failure. ✘ 15:26:10 cudaminer3 Error CUDA mining: unspecified launch failure CUDA error in func 'search' at line 365: unspecified launch failure. ✘ 15:26:10 cudaminer2 Error CUDA mining: unspecified launch failure. During a another run, I got this.

The miner crashes each time. CUDA error in func 'search' at line 365: an illegal memory access was encountered. CUDA error in func 'search' at line 365: an illegal memory access was encountered. CUDA error in func 'search' at line 365: an illegal memory access was encountered. ✘ 01:14:46 cudaminer1 Error CUDA mining: an illegal memory access was encountered ✘ 01:14:46 cudaminer2 Error CUDA mining: an illegal memory access was encountered ✘ 01:14:46 cudaminer4 Error CUDA mining: an illegal memory access was encountered CUDA error in func 'search' at line 365: an illegal memory access was encountered. ✘ 01:14:46 cudaminer3 Error CUDA mining: an illegal memory access was encountered CUDA error in func 'search' at line 365: an illegal memory access was encountered. ✘ 01:14:46 cudaminer0 Error CUDA mining: an illegal memory access was encountered.

It may be related to overclocking, contrary to my prior observation in. I ran it for about 90 minutes at stock GPU settings with no error. Changed to +165 core and +2000 mem using the nvidia x server settings gui. It ran stable for about 2 minutes and errored in this way. I dropped the mem to +1500 and started again. It ran for about 30 minutes with no problems. Increased mem to +1900 on only one card and the error occurred again.

It was reported on both GPUs simultaneously as usual, despite only changing the rate on one of them. I am able to restart ethminer over and over at these high mem transfer rates and it fails in a short period each time. I don't have any experience with C, or any low level hardware programming. So I'm not going to even attempt to understand what the code does. I hope reporting how to reproduce the problem helps someone find a solution, or at least better error catching for this reproducible problem. Ideally, the miner would catch the error and restart, while incrementing a counter showing the number of restarts due to errors.

There is a point where higher transfer rates reduces performance due to failures. But it's hard to find it when the crashes are hard to detect without standing by and watching the scrolling terminal. More info, each time there is a crash, there is a kernel driver error. Jun 30 06:08:58 ubuntu kernel: [44] NVRM: Xid (PCI:0000:02:00): 31, Ch 0000001b, engmask 00000101, intr 10000000 Xid 31: according to Nvidia driver site, this error is generated when it is Driver/Application fault. So not a hardware problem, which is good because it rules out a hardware issue.

I have tried different version of the driver and I get same errors. I think we need someone who knows how the miner works to take a look at this may be help us. For reference: I am running Ubuntu 16.04, Driver 64 bit, 381.22 and Cuda 8.0. Been doing some digging, I have been gradually upgrading from Driver version 367.27 to 381.22.

Dec 07, 2017 MonaCoin did not have enough power to continue to the upside. MonaCoin (MONA). Inside of a HUGE BITCOIN mining FARM!

The crashes are consistent, you get them regardless. It is really annoying because there is no watchdog feature in the miner to restart on failure.

How To Data Mine ZenCash ZEN on this page. And you can't baby sit it 24/7 or auto restart. Some more information, depending on your driver version, you get different crash error. So at I got 381.22 driver version, I got illegal memory error, but at 375.66 I get unspecified launch failure. All of it relates to some sort of search code in ethash library for this miner.

Guys your comments please. Really struggling to find the root cause here. Sorry to reply late. Reading through all your comments, issue should be overclocking makes the GPU fetch wrong data/instruction. To be honest, I have no experience in overclocking gpu/mem.

My roughly thoughts are: • will the fault occur again if we only over clock memory clock? Since ethereum is memory bound, I think it is more important to over clock memory clock. • can we malloc all the data structures of ethereum in host memory, while only place the dag buffer in video memory? • can we add watchdog into the code to restart it when error occurs?

• can we use cuda-gdb or cuda-memcheck to find out which instruction/data is wrong, so that we can add guard among them? Thanks for getting back. Please see my comments below. • The crash occurs with only Memory overclocked.

It gets worst as the overclock gets closer to limit. But happens regardless. I have verified this by trying to gradually reducing the memory clock speed. It gets better as you get close to stock clocks but you still get crashes (sometimes 12hours apart). • Probably good idea, I am not expert in CUDA programming, but would that any performance penalty? • Absolutely a must have in my opinion, the entire miner code should be thread that gets initiated by a watch dog thread.

It should try to recover miner when possible. • Sorry my wizardry powers end here, you are gurus I am just a convert trying to help and report:) I will try this today, I will try to leave the display card out of the list of devices to mine. Hopefully that should prove if that is the problem. Here is my experience so far in case it helps. I have 2 rigs one with 1070's only and one with 's and 1060's. The rig with the 1060's is using --cuda-parallel-hash 4 and the 1070 rig is not using that flag at all.

Both are running Ubuntu 16.04.2 with Nvidia driver version: 378.13 Regarding 's comment, I have no monitors connected to my rigs, I only use SSH and the crash occurs while I am asleep as well. For me this error doesn't seem to correlate with using monitor/remote desktop, however it could be an additional trigger perhaps. Coming from Claymore's I had to drop my memory clocks (I don't OC core) just to get it somewhat stable.

With the lower clocks the best I've had so far is around 24 hours without the error. I haven't dropped lower as if I do I will switch back to Claymore's as it will provide a better hashrate. I have had a similar experience to with stability increasing as clocks are lowered but never fully disappear. Small update, I have upgraded to driver 384.47. This version of the driver is generally more stable than all the previous versions.

My 6th card in the rig has started to work now, which never got working in any of the previous versions of the driver. In Nvidia changelog for the driver, they seem to have a fixed a bug with it. I have been playing around with settings, so far what I have observed is below. • If the memory clock of GPU with primary display is not overclocked, I don't get crash on 384.47. • If the memory clock of GPU with primary display is at same clock as all other cards (overclocked), then I get crashes within minutes.

So what I have been doing is to keep the clock of GPU with display slightly lower (-100 to -150) than all other cards. This keep the system stable and keeps it running on 384.47. I will report back soon if I observe crashes. As pointed out earlier, there is a beta driver 384.47 that you can try.

I am running it and my miner is stable now, the clocks are not at max (may be 10-15% less), but I have not seen a crash in 24 hours. Still in monitoring state, but I believe the issue was with the driver mainly. I think we should monitor this a bit and then close this, as it seems to me the issue with is with the driver.

I would however want to see auto-restart feature of the miner in case of a recoverable failure, that will be very neat and handy to have. If you do not set cuda-parallel-hash in your command, then you are using the default value cuda-parallel-hash=4. Mind telling us or pointing to an explanation of what exactly does this flag does? I'm a bit puzzled with what I tried. Actually I think it should be included in readme.md since the default is automatically applied without setting the flag. Also, one thing to note, like, gpu0 has to have a lower clock than the others, I thought this was just a bad card but maybe its due to being gpu0.

Note: First NVidia GPU that's connected to main slot PCIe (x16). It doesn't have to be connected to a display, still have a lower limit of mem clock compared to the other cards. It will crashed ethminer (same error) when pushed past certain speed. Win 10 with beta 384.47 as suggested. The --cuda-parallel-hashflag changes how the miner processes the hashes. This is very simplified but part of the cuda kernel's work is the search part of the mining process. It runs the same operation in parallel across many cores in the gpu.

When improved the kernel he added the --cuda-parallel-hash flag to allow changing the number of threads which it processes simultaneously. It needs some value to be automatically applied without setting the flag because otherwise the miner would not work! In theory as many threads as possible would be best but there's going be an optimum imposed by the hardware. By default the miner uses 4 because that was the best value which arrived at through testing and this has been confirmed by most users who have experimented with it. I don't think there is any need to promote tweaking advanced settings in the read me because for most people changing them will probably reduce performance. The same applies for the --cuda-block-size --cuda-grid-size and --cuda-streams flags.

These are set to sensible defaults and I have only reduced my hashes by changing them. Thank you for the explanation, i feel like that's aligned to what I suspected. I don't think there is any need to promote tweaking advanced settings in the read me because for most people changing them will probably reduce performance. The same applies for the --cuda-block-size --cuda-grid-size and --cuda-streams flags. These are set to sensible defaults and I have only reduced my hashes by changing them. Actually i managed to increase my hashrates by using those flags. Just as an all-size t-shirt works for everyone, customizing your size according to your proportion works better.

Customizing the flags to fit your hardwares works better. And I feel this is especially true on overclocking in mining with multi GPUs, which is ~80-90%(?) of miners do.

There are even differences in the number of CUDA cores in a same model line. Think of it as warning them instead of trying to decide what's good for them. At least include the explanation in --help.

I get this crash as well, and it seems to only occur with higher memory transfer offsets (usually around +1350 or +1400 for me). Curiously, of my 4 rigs it's happening mostly on the rig with EVGA GTX 1070s. The traditional memory overclock symptom I'd encounter would be one card failing, which makes sense in the overclock context. Yet, in this thread's scenario all cards (in my case 6) simultaneously crash. So, I do agree that this is overclock exacerbated, but I also think there's something in software that's weird and worth investigating. For those on linux who want to keep using ethminer but don't trust the process due to this: simply write a script that watches the wattage output of nvidia-sli. When it drops below 70w (that's the threshold I use) you know the ethminer process has failed and you can simply kill/restart.

Works like a charm for me. Here's the relevant sed/cut: /usr/bin/nvidia-smi -q -d POWER grep 'Power Draw' sed 's/[^0-9.]*//g' cut -d. I can't take credit for this, am quoting from something someone wrote to me. But I can't remember who wrote it.:( Anyway, this should solve your problem: you don't need a monitor connected to make X work.

At the time of installation save the EDID of the monitor using nvidia-settings and then use the edid.bin file in your xorg.conf to fake X that there is a monitor connected. I have this working on my rig and X has no issues.

You can add edid by using nvidia-xconfig --custom-edid=. This will generate your xconfig using fake edid, X should start fine after that. I am using these, which I probably wouldn't need with the above in place:. But they can also work. My rig is not running on Ubuntu, but I had the same issue.

The problem first occurred after I added a 5th card(Evga GTX 1060 6GB) to an already running 4 x Evga GTX 1060 6GB machine. After some test I noticed that the fifth gpu had a micron ddr5 memory and was using a differen vbios version compared to the other 4 gpus. Today I flashed the Bios of the GPU and upgraded it to the same version as the others. The gpu still can't handle the OC-ing that I'm using on the ones with Samsung gddr, but it is stable at 50% of their overclock values. For example gtx 1060 with Samsung running at +625 memory, with Micron running at +300, both at 80% power. So far 3 hours no problem. Before the BIOS flash, it was crashing the whole miner even at stock or slight overclock.

I will keep tracking and updating here. Hope my findings help you further. It seems to me to be clearly related to overclocking too much. Reduce overclocking on the GPU that crashes first and you can keep the rest higher. I have one card out of 6 that is more sensitive and heats up way faster than all the others, even from the same manufacturer. I wonder if a script could be devised to automatically find the setting that doesn't crash on each GPU.

Edit: I gave up tweaking the 'card that crashes first' as I think it's inaccurate. I do kill ethminer and restart it when that happens, but now I only decrease overclock when a card goes offline.

I really like your solution, but for some reason minerlamp crashes on my system. The program itself works, but soon after I start mining windows says the program has stopped working. On further attempts ethminer wont start at all. In or out of your program. I have to reboot.

If the devs are reading this, I hope a watchdog feature is high on the priority list. I've so far refused to use Claymore as I don't like what he stands for.

Not so much the fee, but to me there's no doubt he's ripped genoils CUDA optimizations. That's wrong.

Then there's the impact his dev fee server switching has on pool servers, but that's a debate for somewhere else. Ethminer is the best ETH miner, and asks for nothing more than a donation (which I gladly give). For ETH mining only, Claymore has no benefit other than a watchdog.

I hope ethminer gets one so I never even have to consider paying him a cent. Thanks for all your hard work. Just a final note. I've definitely been able to increase the memory overclock by a decent amount (+100, 4x1060's) with far fewer crashes using the latest ethminer 0.12 dev releases.

I'm fairly comfortable leaving miner restarts an hour apart. Crashing occurs just once or twice a day. There's no way I could do that before with these clocks. Maybe these new cards are just being nicer to me now (highly unlikely), or the devs have been looking into the issue. A watchdog would still give that needed peace of mind. As this one is not closed yet: as mentioned by many miners allready: Illegal memory access error is in case of Nvidia cards happen due to having a card running on max overclocked memory on Power state 2. When your miner does switch to P0 state for whatever reason, memory gets an additional 200 mhz and can (or will) get unstable, which causes this error.

Thanks for the clear input! I've not had any issues with illegal memory access since switching to P0 state with NVIDIA Profile Inspector 2.1.3.10 (Force P2 State ->Off). That is on Windows 10 with a single GTX 1070.

For some reason it has been stable with P2 for a long time on my other machine Windows 10 with four GTX1060. But I guess I'll switch to P0 there as well just to be safe. With Linux I've not been able to switch to P0, right now the cards go to P0 state when they are on idle, but as I start ethminer they go to P2.

I'm very interested in any suggestions on good solutions, feel free to share your scripting knowledge:). On Linux it stays at P2 but you can still overclock the cards as high as they'll go. It depends on each card but I get between 22.52 and 25.10 on GTX 1060s.

Basically I set the card a little high then observe how much hashrate comes out of it to determine the memory type (~22-23 micron, ~25 samsung) then decrease to where it's stable and doesn't get knocked offline. [rig1] ethminer Speed 144.06 Mh/s gpu/0 23.00 gpu/1 24.94 gpu/2 22.52 gpu/3 24.86 gpu/4 25.10 gpu/5 23.65 [rig2] ethminer Speed 163.83 Mh/s gpu/0 23.40 gpu/1 22.76 gpu/2 23.48 gpu/3 23.40 gpu/4 25.02 gpu/5 22.92 gpu/6 22.84 I do my config by device UUID so things don't get mixed up.

Here's my script and file. Send me ETH at 0x5f8f7166c9920ea2d786e0810defdc611544fbfe:). This is my experience with 7 x ASUS GeForce DUAL-GTX1060--O6G(edit: currently 9) on Win10 rig on ASRock H110 Pro BTC+ with ethminer 0.12 (and Claymore as a short test) First I tested with only 2 cards but it is consistent with 7 (soon I'll add at least 2 more possibly up to 5).

I have tested with a single ethminer process for all GPU's and a separate for each GPU as well as a combinations like 1+6 etc. The best result was while running separate processes for each GPU - in a case of failure only one card drops out. When some GPU starts failing usually it fails within a minute again so no point restarting the process again (I didn't check whether reboot would give better result. I have just started testing so I didn't come so far - I need to tweak few things with delayed start of Asus GPU Tweak II and then shutting it down, read more about the reason below).

There is always one card (usually the same) where ethminer is failing with the error message 'CUDA error in func 'ethash_cuda_miner::search' at line 346: unspecified launch failure' With 2 GPU's it was on card0 with 7 it is now (usually) on card1. Monitor is now connected to the built in Intel GPU so theoretically RDP should not influence the outcome though I have to investigate this some more (I used RDP before when I was checking/testing things so I'm not really sure whether it was influencing the outcome). I believe I'm pretty conservative with OC and I lowered memory speed by 200 (to 9.300) compared with the recommended for the optimal hash speed/power consumption (65% - 65 degrees) just to be on the safe side (reported 22,9MH/s/card). The cards are the 'OC' model so I can't lower GPU speed below the 'min' value given in the GPU Tweak interface (1.607). FYI, I'm using Asus GPU Tweak II - pain in the ass due to some glitches like resetting my settings every time something goes wrong with GPU and GPU Tweak is running in background which means I'll run it once in the beginning and close it afterwards to prevent this happening (edit: Adding new card resets the values to default ones so it is necessary to setup values every time GPU configuration is changed + when something breaks like OS getting frozen).

If one card fails all others are stable nevertheless (at least for 8 hours, my longest test so far). Trying to use Claymore on the failing card forces the error to migrate to the card2 and hash rate for Claymore is around 19MH/s. In other words the alternative 6 ethminers + 1 Claymore wouldn't work either. I'll post some updates after I've tested few more things like what will happen without using RDP nor Teamviewer that I used on the other system to reboot where I have 1 x AMD Vega 64 + 1 x Asus GTX 1060 6G (not OC) and where 1060 usually drops out once every 24-48 hours so I used Teamviewer to access the computer from abroad. I'm not sure whether Teamviewer itself could be source of any problem (I'm running it on my 7xGPU rig too). After last reboot I didn't use RDP and so far it was running without any problem for 45 minutes which is promising. I have also been running one 'rig' with 2 x ASUS GeForce DUAL-GTX1060--O6G on MacPro (2011) with Ubuntu 16.04 + ethminer rock stable (is it correct English?;) ) for weeks though without been able to tweak memory/GPU speed (only power target) so it has average 35.4 MH/s.

My plan is to eventually move those 2 GPU's to the ASRock rig. If I figure out how to tweak memory/GPU speed on linux my plan/hope is to kick out Windows so any advise is welcome. I've googled a few that I couldn't get working (honestly I didn't put so much time on it so far - had some other things to do). 2 hours later: no RDP =>no error (seems like).

I've just plugged in 8th GPU and I'll come back with the update. Unfortunately I have no more PCIe power connectors available and it seems like the secondary PSU is trying to be smart and won't supply any current for GPU/SATA without the threshold load on the ATA power connector.

Or my brand new PSU is not working (not probable but I'm not really sure yet). So far there is strong indication that the quoted error is (directly) related to RDP messing up with/for ethminer. After plugging in 8th GPU the system became unstable again (without connecting RDP) so few tweaks later (memory speed down to 9.100) + couple of reboots it became stable again (for one hour). Then I found the work-around for connecting 9th GPU scrambling from all the cables I had around: type4 to 4 x AMP MATE-N-LOK + Molex to PCIe power / Molex to sata power. At a same time I ordered 20 PCIe power splitter cables from AliExpress $1.29/piece so in 3-4 weeks I'll be able to build another 12-13 x GPU rig with one PSU for each (1.200W).

Anyhow back to the rig: First Windows got stuck because I started first miner too soon (before GPU Tweak has been able to shut down completely - impatience I know:) ). Reset button and after logging in and starting miners the 9th started complaining about 'out of memory' error. Few tweaks later with paging values ended at 35.000/45.000 MB - min/max and I could start even 9th miner. 20 minutes later still no error with reported hashrate 22,6MH/s in average. If it stays like this I would be more then satisfied:) Edit 3. 50 minutes later - still no error Question: Any suggestion about choosing between GTX1060 'normal' or 'OC'.

I ordered 10 OC's because 'normal' were out of stock with several weeks estimated delivery time. The price was few bucks cheaper too though I would've stick with 'normal' if they were available at a time. Now I'm not sure any more what is to prefer for ETH mining.

15,5 hours later no error and still counting. Current reported hash rate: 22,4-22,5, in average 20,3 - 24,2 MH/s (average of 9: 22,4MH/s) I even lowered memory speed for the non OC card and its ethminer process hasn't crashed yet neither (small change in hassrate as a result though it maybe had been higher in average since, currently: 23,8MH/s) So case is closed for my part.

Ethminer on card9 produced an error after 23:27 first time and second time after roughly 22 hours. After second time I decided to use RDP to restart the miner and see whether it would cause an earlier error (to compare with the situation without running RDP). I'll come back to you with an update. Update edit 5. Same card dropped out next time after 60:56h(RDP used 2-3 times). 7 days later and still running. Take and my 5 cents.

On GPU I start mining a week ago. For now i have 14 1070ti -+ OC, 2 farms and mining eth with auto restart ethminer if it stops on errors. This two scripts is not best solution, writen from scratch but works fine.

Writed only for nvidia but i think it maybe rewriten for ati too )) All this tested on Ubuntu 16.04 Ok, Lets go!!!! Nvidia coolbits must be enabled if you want OC settings to work. I have a small rig, but it has a similar xconfig (that trick to emulate a monitor took a while to learn), but maybe the coolbits value is different, and the oc values as well. I have to try some of your oc values, in gtx 1060 i remember I couldn't control the fan for instance. I either had the wrong coolbits value or it just doesn't work with 1060s, but there's nothing like trying.

Again, yours is a very complete solution, so thanks for posting it here. Like I said I have a tiny rig with one 1060, from which I squeeze at most 23.6 MH/s. I was wondering how many MH/s do you get from one board with those oc configs? On Thu, Dec 21, 2017, 08:29 H05ted ***@***.***>wrote: Take and my 5 cents. On GPU I start mining a week ago.

For now i have 14 1070ti -+ OC, 2 farms and mining eth with auto restart ethminer if it stops on errors. This two scripts is not best solution, writen from scratch but works fine. Writed only for nvidia but i think it maybe rewriten for ati too )) Ok, Lets go!!!! Nvidia coolbits must be enabled if you want OC settings to work. I'm just finished with setting up second rig (Asus new miner MB - max 19 GPU's) with 3 Asus GTX 1060 OC/1 non OC (old batch). H05ted inspired me to dive into linux again and it is up and running (I will bi needing some adjustments so miner is automatically started after reboot but everything else is working great. I'll post some scripts later but I would like to make some suggestion to H05ted xorg.conf I was struggling for hours to be able to change nvidia settings for card>0 and I've just came across this command: sudo nvidia-xconfig -a --cool-bits=13 --allow-empty-initial-configuration that makes perfect xorg.conf without need for any editing afterwards.

And bonus is that nvidia-settings is now working for all cards. I'm not sure whether it is related to the installing (apt install) xserver-xorg-dev prior to reboot (running nvidia-xconfig complained about missing xorg-server so I installed it). Anyhow it is working now. As I wrote I'll post some updates in the future. Ethereum Miner Monitor released - v1.0.2 - FREE! This is a python application for monitoring linux based ethereum miners and keep alive the miner in 24/7. If you have a linux based mining rig, but don't have monitoring system, you can use this standalone script to keep your miner always running without manual checks.

The application is continuously checking the 'ethminer' process is running and the current GPUs utilization average value. Script can restart the ethminer, or reboot the system. The script doesn't need any extra package/module of python, just pure python3. You can use virtualenv too. The current version was tested on Ubuntu 16.04.3 LTS (xenial), with GeForce GTX 1070 Ti && AMD Radeon R9 290X cards. Added AMD Utilization query support! MariusVanDerWijden -- benefits of open source software?

But when it comes to mining, it all about making money. That kind of renders slower miners totally useless. And please don't tell me you mine for educational purposes. Tonyaik, don't look at hashrate reported, did you count the actual number of shares submitted?

I got two identical rigs, I can run a test, say, for an hour and see. What exactly is 'correct setup ethminer'? I looked thru --help output, I don't see a lot of options there. I use same settings as with Claymore's. VERDICT: It's a good thing to be 'convinced' about something, but reality is a bit different.

Reality is subjective. I had the same tests over and over again.

To compare with you I have a 6x EVGA 1060 3Gb on Micron (not Samsung) and I can squeeze from each one roughly 18.67 Mh/s. Using -200/+850 at 72.50 Watts using Claymore (pushing harder makes the whole system unstable and/or unresponsive), while on ethminer I get 18.52 Mh/s using -200/+750 at 72.50 Watts (system quite stable running for batches of 12 hours each). I am limiting power as much as i can as I do my maths. The drop in reported hashrate is nothing in respect of the 1% fee. In addition must say claymore's uses, on average, 26% more of CPU which causes my rigs with not very powerful celerons quite laggy. With ethminer my machines work smoothly. My measurements using ethermine.org depicts that the reported hashrate is quite overlapping the effective and average hashrate.

Those overlapping lines where never seen with claymore's. (disregard the last 3 hours where I had connectivity problems.) I always had suspicion that claymore's reports higher hashrate than effective. But as we cannot read the code. Last but not least: ethminer is free to use without your 'cheats' (which may well be worked around by claymore's in near future). And is open-source: the value of being able to read the code and being sure that nothing unwanted or unexpected happens behind the curtains is much appreciated. VERDICT: to express absolute verdicts is always not a good idea. And I stop here.

Tonyak>>Claymores shows aprox 10% more than actual hashrate at the pool. That's absolutely NOT true! The reported hashrate is sent to the pool for people to actually be able to make a comparison of real hashrate vs reported. Here, I've run a 4x 1060 1x 1050ti rig for 20 hours in a row. Results: Average Hashrate for last 6 hours: 105.3 Mh/s Last Reported Hashrate: 106.2 Mh/s Pool is eth.nanopool.org. The slight difference is actually 1% devfee of Claymore's.

This is also a good way to check if pool is stealing shares. Probably your experience is due to the fact of share theft, not Claymore misreporting hashrate. AndreaLanfranchi>>To compare with you I have a 6x EVGA 1060 4Gb on Micron (not Samsung) and I can squeeze from each one roughly 18.67 Mh/s. Using -200/+850 at 72.50 Watts using Claymore (pushing harder makes the whole system unstable and/or unresponsive) I can express verdicts because I have built many rigs. I do it for myself and also for money for other people. Micron memory is pretty fast too, it should give you about 21 mh/s (at least!).

If your system gets unstable/unresponsive with further OC, it's not GPU problem, it's your power supply or wiring. Because OC over limit should just throw 'GPU is off the bus' error, the rig should not hang or get unresponsive. By lowering clocks and playing with powerlimit you just get system stability as a tradeoff instead of providing steady power to your equipment.

If you use SATA ->6PIN power converters, ditch them. Solder quality thick wires directly to your PSU and you'll be surpirsed how much better your rig would perform.

I've been thru that. Alternatively, you might want to try removing 5x GPUs and running your system on 1 GPU. See if you can OC it better. My bet is, you can (as the GPU gets more power). Also, that you mention system becoming unresponsive, suggests your CPU/motherboard/memory is underpowered because of too many GPUs in your rig, or, again, bad wiring.

If by 'manipulate', you mean 'buying and selling a lot,' I'm afraid there isn't much that can be done. Tips to help: • never buy or sell for emotional reasons (fomo or fud) • for every position, have an exit strategy • Take profits now and then. No one knows where the top is - if you've profited, you've done well.

• never invest more than you're willing to lose • Attempts at price manipulation are all over reddit. Keep a keen, suspicious eye.

• Ultimately, you're in control of the decisions you make during trading. For many people (including myself), it's probably better to just buy and hold, rather than to stress over market swings. For low volume coins, it's hard to draw the line between manipulation, and the sheer fact that any trade seems to have a disproportionately large impact on the price - the problem is there's so little activity that any movement looks significant. People who think they are 'pumping and dumping' in low volume coins are kidding themselves.

If someone is will to buy or sell at the price you offer, you haven't fooled anyone but yourself, if the market will bear those prices, they are real, and any perceived hand you believe you had in that, is just your ego playing tricks on you.