Quote from: syraka76 on January 28, 2018, 05:28:35 PM

New Version? Huh

?

Unfortunately we have found a bug in the new version which caused crashes on few of our test rigs. The good news is that we managed to reproduce it after a few hours and it was fixed but as a result we have run the latest build of 2.5 only for an hour so far, so we are not feeling confident to release it tonight even for a beta test. It will be released first thing tomorrow, unless something else comes up during the overnight testing.

Quote from: RIGED on January 28, 2018, 12:14:38 PM

QUESTIONS TO DEV: do i have to take any additional steps for the buggy Vega64s and the super buggy Frontiers? can i expect at least the same hashing speeds maybe a little faster?
im using moded Reg tables and unlocked SoC with Ntool to regulate GPU values

migration can cause serious issues for my rigs (i have previous experience) as the 64s and FEs are like Supercars, faster than anything around but super sensitive to changing telemetry (and before you start yelling efficiency rating i pay $0.04kW/h so i litteraly dont care about Wattage my concern is max stable hashing speed, in any case they are running at av 180W)

btw DEV, you really want to make a difference? write the miner which will utilise 4 simultaneous threads for the FE on Cryptonight addressing the 16Gb mem into 4Gb per thread, much like the 2x4Gb on the 64-56 getting 2000H/s from cryptonight.

We only have a pair of Vega56s to test here and it seems that right now to get anything Vega-based is mission impossible. On Vega56 we are getting slightly better speed than Claymore but please only test on one rig first, and only after PhoenixMiner 2.5 is released (the official release will be most likely in Wednesday), as we have found that 2.4 and earlier versions can be occasionally unstable on highly overclocked rigs so we've made a lot of stability changes in 2.5.

While we see a CryptoNight version in our future, for now we are firmly focused on ethash, as we have a lot of features to add to PhoenixMiner.

Quote from: gsrcrxsi314 on January 27, 2018, 09:56:17 PM

can you please add the -tt command functionality? maybe it works? but its not listed in the readme or command list so i assume its not there currently.

this is my favorite feature on Claymore. auto fan speed control without having other software is extremely useful. without it, the cards to to target 85C and i dont want them running that hot. -tt 70 on claymore keeps eveything nice and kosher.

No, it isn't supported in the current version (and won't be included in 2.5) but we have planned for it and we are definitely going to implement -tt and the clocks/voltate options in the near future (at least for AMD cards).

Quote from: Dhino on January 27, 2018, 07:08:58 PM

The problem is something else. Let me explain my situation. I have 7 rigs at home out of which 1 was running your miner and other were on claymore. I have another 20 rigs at my warehouse, all running claymore. All 27 rigs are on us1 servers of ethermine. At night all my home rig had connection issue but my warehouse rigs were fine. My internet connection was good as I was able to mine on other pools. us1 servers of ethermine was good as all my warehouse rigs were doing fine. It seems that us1 and eu servers of ethermine were blocking my IP after using your miner.

I dont know what happen but us1 servers of ethermine was good yesterday.

We have used three different ISPs to analyze the problem and we think we found what is causing it. Basically their servers are extremely busy and sometimes they refuse new connections (the devfee requires a different connection to the pool). This affects all miners but what seems to make matters a bit worse for us is the short default reconnect period of 7 seconds. So in version 2.5 we've increased the reconnect period to 20 seconds and added some failover devfee pools. However the network hashrate is increasing so fast that the pools are going to be strained for some time. It is best to have a least a few failover pools to avoid downtime as much as possible.