Often see this on Windows rig of 2 GPUs with 4.5. As I suspect, the issue is linked to PCI-e risers. Without them all works with no issues, but any card on riser reports that with some probability. If error started to occur, maybe 10 to 50 restarts may be needed to finally create the DAG. -gser 1 does not help. Riser changes do not help. Interestingly, when DAG changes itself by block number, this system never has any problem. But again the probability matters.

I have no idea what to do, currently trying to replace the motherboard by another model since both cards were worked in another system.

Can you confirm if it has any stability improvements on Linux regarding statistics socket? 4.4 had issues, 4.5 didn't have as I thought but there was a report of them here. Today I also found the issue of loosing socket by 4.5 on Linux. What about 4.6, were any changes done for it?

I am asking since improving my open-source cross-platform monitoring utility adding few features like email notifications on failures (no response from miner since time shown, low hashrate since time shown, etc), miner restart on specific failures (programmed reject rate, etc). And the stability of monitoring and control socket is a must for all such features.

And that's great, thanks! Switched my rigs to Linux since stable 4.5 version (I like cmdline UI for administration).


Simplest method is the 'top' utility that refreshes a screen with a list of processes every second or so. You may see that memory used by ethcmdminer64 process grows every time.


top - 22:23:27 up  9:10,  2 users,  load average: 0.26, 0.13, 0.10
Tasks: 159 total,   1 running, 158 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.2 us,  2.9 sy,  0.0 ni, 97.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   3529812 total,  2176220 used,  1353592 free,   171264 buffers
KiB Swap:        0 total,        0 used,        0 free.  1194856 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  986 root      20   0  467712 160300 117116 S   4.0  4.5  14:43.68 Xorg
29995 work      20   0 7559356 193588  71832 S   1.7  5.5   1:02.57 ethdcrminer64
 9472 work      20   0  727680  76300   8864 S   0.3  2.2   0:04.77 node
28301 root      20   0       0      0      0 S   0.3  0.0   0:01.51 kworker/0:1

There is a Linux native version of this miner, but:

@Claymore:
- can you confirm my observations that Linux version has lower hashrates comparing to Windows one? With 7950 I see around 1MH/s difference using same PowerTune, cclock and mclock set externally.
- did you notice that Linux version has some memory leaks? I see around 8MB/s of virtual memory leak using top utility. I can restart miner once a week, but still not a good sign.

I run GenEthOS Linux distro using 8GB USB flash with no HDD/SSD on 2GB RAM system with no issues. Still, it's possible to use even 4GB flash (didn't try since GenEthOS distro comes on 8GB image, but only 3.3GB is used).

Yes: http://ss64.com/nt/setx.html
Delete registry key/value.

Actually, as I just read, setting them for the first time does NOT change current environment (only new processes), so it was even more stupid using them in a batch file just for the miner.

+1

Like this?



Open Source and manual: https://github.com/osnwt/ethmon

setx command puts them into environment variables. Unlike set (that puts them for current process and child processes only), setx puts them into a global environment and saves in the Registry. So any process started later will use them even after reboot.

Actually I don't know who and why first put them with setx - I see no reason to change global environment for local task (miner). Simple set is enough and it doesn't affect other programs.

I saw it definitely on HD7950 cards, did not pay attention to others since I see no reason to NOT mine DCR. It adds a value even with extra 1% devfee and extra electricity. At least, now for me.

It was already explained and should be written in a FAQ.

GPU has a lot of processors and a single memory array. When all computing threads hash Ethereum (memory-bound), there are memory access delays. When some of processors hash Decred (GPU-bound), they relax memory stress, and remaining threads can get memory data a bit faster. This is an unintentional side effect.

For those who may be interested: as a first try of writing javascript applications (I never did that) I wrote a small web app using nodejs that provides the same web page as Claymore's utility.

The advantage is that my app runs on any OS under nodejs (I wrote it on Mac, tested later on Linux, and now it also runs on Windows with no changes at all). And that will be open source, I am going to put it on github later when time permits. Anyone is free to change the source and/or update web page templates to do anything he wants. Honestly, I wish someone with designer skills updates the template so it will look cool on mobile screens with variable screen sizes.

Sorry, short of time now, but here is how it looks like at the moment:

Another suggestion for the config file:

- add '-config' option to specify a location for the config file (was already suggested)
- add '-log' option to specify a location for log file and/or directory (was already suggested)
- add '-rig' option for miner instance. If this option presents, then the miner still reads a config file (if no other cmdline options defined), but will understand the rig-specific syntax suggested above. That way we can use the same configuration file for both local config file and uploaded via remote manager. For configs sent remotely the '-rig' option may be ignored (since the manager knows where to send config - so the manager MUST edit the config file and send only options for THIS rig), or may be interpreted the same way (that is, use common options unless specialized ones defined for that rig name - so remote manager just uploads the generalized config file, and then the miner interprets is the same way).

I tend to the 2nd option: no '-rig' - use only common unprefixed options. There is '-rig' parameter - use common options unless specialized ones override them. This keeps compatibility with current behavior.

Of course, in this case the option is only applied to rig01:

And config processing should first collect all unprefixed active options (defaults), then override them with rig-specific options (if some are defined and there is the '-rig' option on the command line or even in the same config).

@Claymore:

- please add a notice about %NAME% to README/HISTORY files. I could not remember where did I see it, and finally found only in the help of remote manager. Would be good to see it in the main manual.
- didn't you implement the same functions for the config file? If not yet, one of implementations could be:


PS. May be this variant is better since options for the same rig are aligned:

Maybe read the README.txt of miner then? Or the same text in the 1st message of this thread on page 1? There is an example of DwarfPool command line there. All you may want is to replace the eu by us in the pool address to get better responses from nearest pool.

Important about GenEthOS (from there: https://forum.ethereum.org/discussion/comment/28114/#Comment_28114):

Talking about DAGs, you can copy and run any miner from tmpfs in RAM, and in that case it will be faster than using HDD. Talking about Claymore's miner, I think we should find out why it works a bit slower, and fix it instead of dropping the Linux version.

WebUI is horrible, but actually it is Webmin with few custom commands added, and a set of scripts. You may use UI to edit them or may edit the same files with ssh and vi, then just run and forget. I see nothing that requres that UI to be used all the time. You may use ADL monitor, but again, having an application for Claymore's miner (say, written in nodejs), there is no need in that either.

In short, it needs some polish, but can be used as is and is very stable and (almost) ready to use with this miner (and ready to use with few others). I may expect that commercially sold alternative (https://forum.ethereum.org/discussion/4298/ethos-linux-ethereum-mining-platform) might be better in that respect. But anyway, for me it is a "run and forget" system, we only should fix the miner to have the same performance on both platforms.

Actually, I also found that. I have identical 7950 on both platforms. Both run at 1050/1550 +20%. But they have different hashrate.
Linux:  19.494, Windows: 20.013

I thought it is due to non-identical powerplay options.

I could recommend trying GenEthOS distro: https://ethereum-mining.info/en/
It is ubuntu 14.04.4 LTS-based distro that includes many tools for ETH mining (proxies, miners, GPU tweakers and monitoring tools) and is free to use. Runs from USB stick (8-16GB) if you want it, or HDD/SSD. It does not contain CDM (since it is not an open source), but perfectly runs the binary. You need to tweak few files via ssh or using Webmin GUI. It also runs basic web rig monitoring UI that includes GPU temps, fans, frequencies and core voltages. The only disadvantage is that by default it uses Russian and most comments in files are in both English and Russian duplicated or mixed, you shoud change /etc/default/locale (or via web UI) to English if you like. Still, it runs very stable and unlike some other distros is free to download. I remember some other ETH mining distro that is sold on SSD using open source Linux, that's against GNU license.