Quote from: tenmoi on February 18, 2018, 06:42:42 AM

Phoenixminer,
My rig config: win 10 pro, 6 x msi 570 gaming x 4G, mining at Nanopool, mclock 2030, vcddc 870, cclock 1100, vcore 950, fan 80%.

Miners 2.6 and 2.7a both crash win, BSOD. Claymore doesnt, but it resets the voltages and clocks after sometime after the decree sessions I guess. Now Im running 2.7a with -mi 8. This reduces the local hashrate to around 173 from 175 of claymore.

Hopefully this will be resolved once the hardware control options are supported by PhoenixMiner (in 2.7b). In our tests roughly the same clocks/voltages that work with Claymore should work with PhoenixMiner with small exceptions.

Quote from: dagarair on February 18, 2018, 03:26:40 PM

For a guy like me with a ton of miners I would really like to see a global update or a push feature to push an update from a main console. Claymore has this issue as well so it's not just you all. But for a guy that has 50-100 + miners man it would rock. That is what makes linux so nice. I'm half and half right now but might go full linux because of the console push features.

Hats off to you all though. You are for sure getting better by far since 2.3! Testing 2.6 on 10 machines again.

This is a good idea but it also would be a dangerous way to sneak some malware via this vector. Perhaps when we implement fully encrypted (and authenticated) remote management API, it would be safe enough.

Quote from: Rufgenia on February 18, 2018, 09:04:35 PM

Hello,
need option for controlling fanspeed like claymore " -tt 60 -fanmin 75 " for example.

Coming soon (a few days until release of 2.7b with all hardware control functionality).

Quote from: Bwaite43 on February 18, 2018, 09:30:30 PM

Any update on the Linux version?

Soon-ish (TM) Embarrassed

It will have to wait until the hardware control and dual mining are implemented. It would help if you tell us what distro of Linux you are using (or intend to use) and (if you are using AMD cards), which drivers, so that we now what to test first.

Quote from: P00P135 on February 19, 2018, 12:34:29 AM

https://www.virustotal.com/#/file/237d6f3f781d9a4a718559c956d2da0bf81e82c374e7ce6dca44e397bcd404ff/detection

Detected 9 times for specifically Troj.Win64.Wdfload Roll Eyes

Well, we were starting to worry that something happened to you - no posts stating for the Nth time the false positives of AV software Grin

Seriously, use your brain please. We are busting our asses and using considerable time and expertise to ... install a shitty trojan or your mining rig?! This is like building a flying saucer in order to use for shoplifting. There is quite simple explanation for this - some of our anti-debug code has the same signature as part of this stupid trojan. As our anti-debug code is randomized and scrambled in each build, there is no way we would chase the exact few dozens of bytes for weeks, or to turn off our anti-debug measures just to get "clean" report from these AV programs.

Quote from: ckai93 on February 19, 2018, 02:38:14 AM

a few hours back pool shows that rig went offline but the miner still submit shares.
i've restarted the miner and still submit shares as usual but pool still doesn't show that.
been in touch with ethermine support but they insist that it wasn't a server side fault.

still not sure if it was a pool or miner issue but till then, i'll continue using claymore.

Please check in the log if the miner is not redirected by someone using the Claymore's remote debugging to mine for another address. As a rule, do not use the commnad-line option -cdm 2 (or -mport with positive port number) if your CDM port is accessible from outside your LAN, or specify a remote management password with -cdmpass and use something like OpenVPN to control PhoenixMiner outside of your LAN.

Quote from: zeii on February 19, 2018, 04:45:20 AM

I have many Incorrect shares after switching DAG size.
Could you please add commands to restart miner when get more than xx incorrect shares?
I mine to nicehash and found this problem every time when switch DAG size.(if not switch DAG,they not have any incorrect share)
Rig Rx560 4Gb.
Thank you.

This means that the new DAG contains errors. Probably this is result of overclocking or undervolting (especially on memory). If there is an error during DAG generation, there is no easy way to find it and it would create a log of "random" incorrect shares. To solve the problem, lower the memory overclock a bit. We are thinking about a better solution like checking the DAG for integrity or something like this but it would slow down the DAG generation considerably.

Quote from: axe0911 on February 19, 2018, 02:48:20 PM

I was testing out the 2.7a version. Getting this error -

17581:20:02:46.344: main Increase the Windows page file size to at least 16 GB to avoid out of memory errors and unexpected crashes.

And the GPU OC gets removed. My page size has already been increased.

This is just a warning that is shown if the total size of virtual memory (physical memory plus current page file size) is less than about 20 GB. The overclock drop is known problem with AMD drivers that randomly reset voltages and/or clocks on some of the cards. We will resolve the issue in 2.7b when we will support the hardware control options. We will be checking periodically if the settings are still in effect and set them again if they aren't.