Okay. In that case, if you have another power supply, I'd try it because the power usage on Grin jumps around alot, but I would think it would run a little bit before that caused an issue. Hopefully you can get it figured out.

Are you using SMOS? Have you tested it without the 1080ti? I had this issue in February when I tried to run a rig with two 20-series cards (2080ti + 2070) and four 10-series cards (1080ti x2 + 1080 x2) on SMOS. I tried every configuration I could come up with and every time a 20-series card was mixed with a 10-series card, the fan on one or more of them wouldn't work right and that(those) card(s) would crash. I had to split the rig, which added 40-50W, but back then it was still more profitable in my situation to run the 1080s on Grin31 instead of Grin29. When you consider the extra electricity, it is now more profitable for me to run all the cards on one rig using Windows and just have the 2070 and two 1080s mining Grin29. I have no real technical expertise here and no idea if this is just an SMOS issue or more broadly a Linux issue.

I have the logfile for the last couple days. Here's a screenshot of where the most recent issue happened (Jun 19 03:08:13 to 03:19:20):
https://imgur.com/a/fkGx3hh

I can send you the rest of the logfile if you need...what's the best way to get it to you?

I've run into this issue again, where my Z9 Mini is disconnecting from the pool (presumably to dev fee mine), then won't connect again for several hours or until I restart it. I thought it was just an issue with Prohashing's pool since I wasn't entirely sure I'd seen it at other pools. But recently when I've mined on Slushpool, I'm getting the same issue. Again, I have two Z9 Minis - one works fine at 750Mhz without your firmware, so I only use your firmware on the other, which has to run one hashboard at lower clocks. I switched both over to Slushpool at the same time and the one without your firmware has been connected the whole time, while the one running your firmware has disconnected and submitted no shares to my pool for 2+ hours at least 3 times in the last week - in fact, one of the times was over 6 hours before I realized.

Screenshot of my miner status page showing an example of the latest issue:
https://imgur.com/a/rOXBkde

And my support id:
****

Can you look into this?

I have two Z9 Minis running - one with your firmware and one without. This issue only occurs on the one with your firmware. I don't use AwesomeMiner or any other software to monitor, track, etc. It happens when I am mining on prohashing and I could be mistaken, but I thought at least once when I was mining on flypool. I never tried to see where it was actually mining or any other info; I just restarted and moved on. It hasn't been a big enough deal to date for me to worry about - just thought it might be useful info for you if others run into the same issue. Until it happened while I was mining flypool, I assumed it was probably issue on Prohashing's side. And since I'm not 100% sure it did occur mining flypool, I'm still not ruling out that its a Prohashing issue.

Just a data point regarding this: I've noticed several occasions where my Mini has continued to mine for a few hours, but is not mining my pool. I know it has happened with Prohashing multiple times, and I think at least once on Flypool. To the best of my knowledge, its been maybe 5-10 times since 2.1d came out, but I've never spent time on it or looked into any further - I've just restarted and it fixes itself (though that is actually adding some dev mining on restart).

I've only tested BTM using v20.0, but my 2070 gets 9030 h/s at stock settings (1665core/6800mem/100%power on my card). With power set to 80%, the hashrate drops to about 8350 h/s. I was happy with that, so haven't played around with lots of settings.

I've been running Bminer v15.0 for a few days now. Some users were reporting stability issues, and I had some early with my prior overclocks, but running with stock core/memory and slight undervolt on SMOS, I've only had two restarts in a little over 3 days between two rigs. One rig has 2x 1080Ti (0/0/225W) + 2x 1080 (0/0/155W) and gets a combined 4.19gps poolside (miner reports 4.38gps) on C31 using Luxor, with less than 0.2% rejects. I haven't tested it on any other pools. If you're just looking at 1080Tis, mine report ~1.26 poolside (1.32gps on the miner). I've also got a 2080Ti running at 1.84gps poolside (miner reports 1.91gps) on C31. The new NBMiner looks interesting and I'd like to test it, but I have testing fatigue, so it'll probably be a few days before I get around to it.

Firstly, I made a mistake in my prior post. I intended to say Bminer showed 6.0 gps (not 5.6gps), but poolside, I got 6.1 gps. You mentioned in your prior post that you were getting a solid 7.1 gps per card, but this post shows you're getting 6.5 gps poolside - that was my whole point. Gminer shows significantly higher hashrates than the pool, while other miners do not and/or it is less pronounced.


Rather than spewing numbers about, I'd encourage you to continue testing. I've tested Luxor, F2pool, sparkpool, and Grinmint using Minerbabe's Kbminer, Bminer, Gminer, and Grinminer on Linux (mostly SMOS) plus Bminer, Gminer, and Grinpro on Windows 10. I've done some with a P106 x6 rig + 2 1080s, 2 1080 Ti's, a 2070, and a 2080 Ti in various configurations. (Side note: Every time I add 20xx cards to a rig with 10xx cards on SMOS, one 10xx card fan will stop working correctly, so I have to separate them). I'm located in the southeast US, and in every test I've conducted, Luxor has shown lower rejects and higher reported hashrates than F2pool, sparkpool, on grinmint (in that order). Additionally, Gminer has always shown a higher hashrate than reported poolside, and Bminer has always shown a lower or equal hashrate to that reported poolside.

If you are only going to use Windows, I've found that, for my circumstances on the pools I've tried and the cards I have, Bminer 14.0+ shows better results than Gminer 1.31.

No, I'm using Linux.

With v14.3, I'm getting 2.5gps (GRIN31) poolside using two 1080 Tis at +180/+600/85% on F2pool with 1.2% rejected  I found in the past that both sparkpool and grinmint had too high rejected shares, so haven't bothered with them. I did have pretty good luck with Luxor on Grin29 - near 0% rejects, which makes sense because my ping is ~55ms at Luxor compared to ~330ms on F2pool. I'm planning to go back to Luxor after my next F2pool payout.

After mining GRIN for about 1 1/2 weeks with bminer, I've consistently had higher hashrates on F2pool than has been shown on the miner. I thought it might be an outlier *luck* result, but it has held true the whole time on both my 1080Rig (1080Ti x2 + 1080 x2) on GRIN-31 part of the time and GRIN-29 the rest of the time and on my P106Rig (P106-100 x6) on GRIN-29 the whole time. I've also seen that going from version 13.2 to 14.1 decreased rejects from ~1.8% to ~1.3% (again on F2pool). I've tried sparkpool and grinmint for a few days with different rigs and have had much poorer results, with sparkpool's reject rate hovering above 4.5% now (it was over 5% on v 13.2). Not sure what to make of all that except to keep using bminer on F2pool.

Each place I've lived in the US, the electric company had a base charge of some sort + charges for usage. Unless you have a separate meter specifically for mining, the only thing that matters is the usage charges. If you have a separate meter for mining, the base charge is irrelevant when determining whether or not to add cards/rigs/ASICs.

Been using version 4.12 for just over 24 hours mining Grin31 on F2pool. My two 1080Ti's are showing 0.55 / 0.56 gps (+180/+600/200W OC) and my two 1080's are showing 0.35 / 0.36 gps (+100/+500/150W OC) for a total of 1.82 gps. F2pool shows 24hr hashrate of 1.969 gps and 1.3% rejects. I don't have a Killawatt on it right now, so can't report at the wall power.

Update: Killawatt reads 800W +/-10W with platinum psu for this setup.

This is great. One of my batch 1 minis ran at 750Mhz for a long time before one board started crapping out and i had to run all three at 550Mhz because of that board, so I'm very happy you put this out. Can't wait for the increased frequencies.