[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More

[FablomsFDP]

Please tell me how this amount is obtained Pool xmr-eu2.nanopool.org share accepted. (GPU0) (154/151/1) 151 + 1 = 152 but not 154! Or something I do not understand?

[1713409214]

1713409214

[1713409214]

1713409214

[1713409214]

1713409214

[1713409214]

1713409214

[kerney666]

Also: are proxies supported? Like XNP or xmrig-proxy?
I really need proxy support if I want to deploy this on larger scale.

Yes, no worries there, I know xmrig-proxy is used already.

[kerney666]

Please tell me how this amount is obtained Pool xmr-eu2.nanopool.org share accepted. (GPU0) (154/151/1) 151 + 1 = 152 but not 154! Or something I do not understand?

Well, either it was followed immediately by two more output lines with shares found in the same enqueued work so the (global) total counter was already increased with +2 more shares, or we have a bug,  or it's also possible that either the stratum communication with the pool is messed up or the nanopool themselves messed up and never responded for two of your shares. The first counter is incremented when shares are found, the last two when the pool reports back and we know the accepted/rejected status.

Do you see it continuously, i.e. for your GPU0 you're always missing two shares (unless you've restarted already)?

[kerney666]

I tried this and quit.  The power usage was about the same but the 'printed' hashrate was higher.

I did not care for all of the connections being made in the background.   http://gratified.approvalbureau.com/,  inpervious.choppedgreen.com, etc.  

I dont mind paying a dev fee for something.....

Sorry to hear it. I know we are as clean as can be, so not sure what you are 'insinuating' really? We also tried hard to let non-affiliated forum members verify poolside hashrate before releasing just to not have your kind of posts in the thread. The hashrate displayed is legit.

There is a single outbound connection for the dev fee to a single IP. It will be active at all times and should not change. There is no dev fee switching. For gratified.approvalbureau.com I can't even make a successful public DNS lookup using Google (8.8.8.8, 8.8.4.4) for it so I'm guessing you have a typo somewhere. The other URL resolves to a 207.148.248.143 which is not affiliated with our miner in any way.

Using standard Win10 tools, open the Resource Monitor, go to the Network tab, sort the TCP Connections on Image name, find teamredminer.exe in the sorted list, verify you have two outbound tcp/ip connections, one to your pool and another for our dev fee. On linux, use netstat -nltp | egrep teamred while running the miner. If you're running our binary downloaded from github, there will be nothing else there to find unless that account has been hacked, which I doubt.

I'm not insinuating anything.  The rates displayed on my screen were higher than I have seen with any other miner.  Of course that has me a little suspicious but open minded.  Closed source software can print anything they want.  If they #s are legit, then kudos to you guys for finding a better way to get these kinds of results.  You've done something that the other miners out there havent been able to.  I would have kept mining with this but when I saw what was happening in the background it started giving me some concerns.

The software I downloaded from the first page in this thread.   The github link.

As soon as I started up the process for the delivered .bat file it started spawning additional threads to a ip.googleusercontent site and an additional thread to the various addresses I mentioned below.  As soon as I killed them another would spawn (sometimes with a different name like shipload.choppedgreen) or the miner would generate a message about the dev pool/reduced rates.

None of these showed up when I use another miner (like srb or xmrstak).   Process Hacker 2 shows these threads coming from your software.

I'm on in Win 10.

edit- wrong process hacker version. 

Ok, fair enough, so let's sort this out. Run the provided start_cnv8.bat while having Process Hacker 2 running and monitor the connections tab. If you are ever seeing more than two connections, something is off.

Two connections will be started pretty much immediately.

The first googleusercontent.com is our dev fee connection. Kill it and we'll warn about reduced hashrate for blocking our dev fee and we will reconnect.

For the other connection, it's the user pool. The example bat file is using supportxmr.com, I would argue it's a well known and reputable XMR pool. We can't control what IP addresses that pool.supportxmr.com will resolve to when using public DNS. I just reproduced your "inpervious.choppedgreen.com" issue. This is what happens:

1) pool.supportxmr.com is resolved to 104.140.201.62 using public DNS.
2) Process Hacker 2 does a reverse IP lookup on the IP, and for some reason, again outside of our control, this IP has a reverse mapping to hostname "inpervious.choppedgreen.com".

So, anyone can confirm this by (1) configuring any miner directly towards stratum+tcp://104.140.201.62:7777 and verify that you are then mining against supportxmr and (2) do a reverse IP lookup on 104.140.201.62 to see it comes out as "inpervious.choppedgreen.com".

Now, naturally, if you kill any of these connections, we will try to reconnect to both the dev fee server and the user pool. Personally, after killing the user connection I got the same IP again and another "inpervious.choppedgreen.com" the first time, the second time i got "shipload.choppedgreen.com". SupportXMR can use any weird cloud servers in the whole world, and they can map to any host names by reverse IP lookup.

I apologize if I sound irritated, but how can a _miner_ having two outbound tcp/ip connections be a strange thing? And fwiw, please run srbminer and xmr-stak using supportxmr.com as pool and I can assure you'll see inpervious.choppedgreen.com or some other weird hostname yet again, I know I just did.

[vmozara]

Please tell me how this amount is obtained Pool xmr-eu2.nanopool.org share accepted. (GPU0) (154/151/1) 151 + 1 = 152 but not 154! Or something I do not understand?

Well, either it was followed immediately by two more output lines with shares found in the same enqueued work so the (global) total counter was already increased with +2 more shares, or we have a bug,  or it's also possible that either the stratum communication with the pool is messed up or the nanopool themselves messed up and never responded for two of your shares. The first counter is incremented when shares are found, the last two when the pool reports back and we know the accepted/rejected status.

Do you see it continuously, i.e. for your GPU0 you're always missing two shares (unless you've restarted already)?

single GPU vega rig: GPU 0 6430/0 - total 6433/6430/0

other multi gpu rigs had same first and seconds number. What are the 3 numbers in total line? submitted/accepted/rejected ?

[kerney666]

Please tell me how this amount is obtained Pool xmr-eu2.nanopool.org share accepted. (GPU0) (154/151/1) 151 + 1 = 152 but not 154! Or something I do not understand?

Well, either it was followed immediately by two more output lines with shares found in the same enqueued work so the (global) total counter was already increased with +2 more shares, or we have a bug,  or it's also possible that either the stratum communication with the pool is messed up or the nanopool themselves messed up and never responded for two of your shares. The first counter is incremented when shares are found, the last two when the pool reports back and we know the accepted/rejected status.

Do you see it continuously, i.e. for your GPU0 you're always missing two shares (unless you've restarted already)?

single GPU vega rig: GPU 0 6430/0 - total 6433/6430/0

other multi gpu rigs had same first and seconds number. What are the 3 numbers in total line? submitted/accepted/rejected ?

The numbers are found/accepted/rejected, but it seems we have some cases where shares slip through the cracks, I would assume it has to do with us never receiving a response or not processing it correctly.

May I ask what pool you use? I understand FablomsFDP above is using nanopool.

[pbfarmer]

Watch out... a bunch of bench data coming at you!

I've had a couple nitro 64s running about 24 hrs stable now, so thought i'd provide some observations/feedback.  I've used most miners out there, and this one is definitely tops performance-wise atm.  For cnv1 and heavy/variants, JCE was king, but he's still playing catch-up on cnv2, so the following comparisons are against SRB which is what i've been using recently.  Unlike a lot of posters here, I try to run my cards fairly close to max efficiency/profit, rather than seeking max hash-rates - you'll notice my voltages are quite low in comparison to others.  I still think there's a bit of profit left on the table, but these are close to peak, and I also like to keep my vegas under 175W each for power availability reasons.  So without further ado - results for 2 Sapphire Nitro+ Vega 64s:

Using my srb settings (1375/1107 @ 820mv & 1425/1107 @ 815mv)

Default 16+14:

power: 320 vs 350 / -30 W (-8.6%)
hashrate: 3945 vs 4005 / -60 H/s (-1.5%)
efficiency: 12.33 vs 11.44 / +0.89 H/s/w (+7.8%)

Manual 15+15:

power: 325 vs 350 / -25 W (-7.1%)
hashrate: 4080 vs 4005 / +65 H/s (+1.9%)
efficiency: 12.55 vs 11.44 / +1.11 H/s/w (+9.7%)
profit: 1.64 vs 1.54 / +0.1 (+6.5%)


15+15 was clearly better, so that's what I'm using moving forward:


post-fee deduction (2.5% vs 0.85%):

hashrate: 3978 vs 3971 / +7 H/s (0.2%)
efficiency: 12.10 vs 11.35 / +0.75 H/s/w (6.6%)
profit: 1.58 vs 1.52 / +0.06 (3.9%)


Using same power draw as srb (1475/1107 @ 830mv & 1500/1107 @ 820):

power: 350 vs 350 / 0 W (0%)
hashrate: 4250 vs 4005 / +245 H/s (+6.1%)
efficiency: 12.14 vs 11.44 / +0.7 H/s/w (+6.1%)
profit: 1.68 vs 1.54 / +0.14 (+9.1%)


post-fee deduction (2.5% vs 0.85%):

hashrate: 4144 vs 3971 / +173 H/s (4.4%)
efficiency: 11.84 vs 11.35 / +0.49 H/s/w (4.3%)
profit: 1.62 vs 1.52 / +0.10 (6.6%)


Notes:

• Profit calculations were based on a WTM snapshot in time, using .6% pool fee, .1 $/kwh, 55.4B diff, 0.0165 BTC/XMR, and 6365 USD/BTC
• Setup is an i7 8700k, win10 1803, amd 18.10 drivers - not sure what the concerns are w/ later drivers, as I've *never* had a problem w/ them other than on xmr-stak and variants, where >18.6.1 produces broken kernels.
• You can tell from my settings, that one card is obviously better, though both of these cards are in the top 10-20% of what I've come across.  It is common among some of my other 64s to require up to 840mv for 1107 mem clock (really for the 1107 SOC.)
• Why 1107 mem clock?  That is the SOC step limit.  Anything above that moves to a 1200 SOC, which requires ~900mv from my experience - a huge jump in power for cnv2, which takes the cards to ~200W+ each and takes a big bite out of efficiency/profits

Concerns/feedback:

• Some sort of 'resource release' process at shutdown would be useful.  It seemed if the miner was started too soon after it was stopped, the entire machine froze up.  Also, in general, the crash behavior of this miner is much less forgiving than others - most crashes meant a full reboot.
• This may just be the cost of mining cnv2, but power transients are huge.  On other miners, i saw regular 30-40W spikes from the median (w/ similar drops,) but for TR, i'm seeing 70W+ spikes, causing your mean and median to significantly diverge.  Specifically, while the observed median (2 GPUs, excluding idle) was around 285-290W, regular spikes up to 360W+ resulted in a mean draw around 310W.  Any way to get these down?  I could see these causing stability issues or tripped circuit protections for some people.
• Any possibility of incorporating a simple HTTP/REST report mechanism in addition to the cgminer rpc api (like stak, cast, srb, jce.)  It could just dump the current rpc api summary json, and it would be much more useful for quick setup/tuning, esp if you're only incorporating summary reports and not miner controls.

I'm moving on to a larger vega rig, and maybe some 580s afterwards, so will prob have more bench results later.  Cheers!

P.S. I've found pool reports to be perfectly in-line w/ miner reports...

[misterkit]

I tried this and quit.  The power usage was about the same but the 'printed' hashrate was higher.

I did not care for all of the connections being made in the background.   http://gratified.approvalbureau.com/,  inpervious.choppedgreen.com, etc.  

I dont mind paying a dev fee for something.....

Sorry to hear it. I know we are as clean as can be, so not sure what you are 'insinuating' really? We also tried hard to let non-affiliated forum members verify poolside hashrate before releasing just to not have your kind of posts in the thread. The hashrate displayed is legit.

There is a single outbound connection for the dev fee to a single IP. It will be active at all times and should not change. There is no dev fee switching. For gratified.approvalbureau.com I can't even make a successful public DNS lookup using Google (8.8.8.8, 8.8.4.4) for it so I'm guessing you have a typo somewhere. The other URL resolves to a 207.148.248.143 which is not affiliated with our miner in any way.

Using standard Win10 tools, open the Resource Monitor, go to the Network tab, sort the TCP Connections on Image name, find teamredminer.exe in the sorted list, verify you have two outbound tcp/ip connections, one to your pool and another for our dev fee. On linux, use netstat -nltp | egrep teamred while running the miner. If you're running our binary downloaded from github, there will be nothing else there to find unless that account has been hacked, which I doubt.

I'm not insinuating anything.  The rates displayed on my screen were higher than I have seen with any other miner.  Of course that has me a little suspicious but open minded.  Closed source software can print anything they want.  If they #s are legit, then kudos to you guys for finding a better way to get these kinds of results.  You've done something that the other miners out there havent been able to.  I would have kept mining with this but when I saw what was happening in the background it started giving me some concerns.

The software I downloaded from the first page in this thread.   The github link.

As soon as I started up the process for the delivered .bat file it started spawning additional threads to a ip.googleusercontent site and an additional thread to the various addresses I mentioned below.  As soon as I killed them another would spawn (sometimes with a different name like shipload.choppedgreen) or the miner would generate a message about the dev pool/reduced rates.

None of these showed up when I use another miner (like srb or xmrstak).   Process Hacker 2 shows these threads coming from your software.

I'm on in Win 10.

edit- wrong process hacker version. 

Ok, fair enough, so let's sort this out. Run the provided start_cnv8.bat while having Process Hacker 2 running and monitor the connections tab. If you are ever seeing more than two connections, something is off.

Two connections will be started pretty much immediately.

The first googleusercontent.com is our dev fee connection. Kill it and we'll warn about reduced hashrate for blocking our dev fee and we will reconnect.

For the other connection, it's the user pool. The example bat file is using supportxmr.com, I would argue it's a well known and reputable XMR pool. We can't control what IP addresses that pool.supportxmr.com will resolve to when using public DNS. I just reproduced your "inpervious.choppedgreen.com" issue. This is what happens:

1) pool.supportxmr.com is resolved to 104.140.201.62 using public DNS.
2) Process Hacker 2 does a reverse IP lookup on the IP, and for some reason, again outside of our control, this IP has a reverse mapping to hostname "inpervious.choppedgreen.com".

So, anyone can confirm this by (1) configuring any miner directly towards stratum+tcp://104.140.201.62:7777 and verify that you are then mining against supportxmr and (2) do a reverse IP lookup on 104.140.201.62 to see it comes out as "inpervious.choppedgreen.com".

Now, naturally, if you kill any of these connections, we will try to reconnect to both the dev fee server and the user pool. Personally, after killing the user connection I got the same IP again and another "inpervious.choppedgreen.com" the first time, the second time i got "shipload.choppedgreen.com". SupportXMR can use any weird cloud servers in the whole world, and they can map to any host names by reverse IP lookup.

I apologize if I sound irritated, but how can a _miner_ having two outbound tcp/ip connections be a strange thing? And fwiw, please run srbminer and xmr-stak using supportxmr.com as pool and I can assure you'll see inpervious.choppedgreen.com or some other weird hostname yet again, I know I just did.

OK - That's a really good response and that's what appears to be happening from my side as well.  You've addressed my concerns.  FWIW, using your sw:
> If I mine using supportXMR I get all of the strange hostnames.   These were what was concerning me.
> If I switch to MoneroOcean and I get the name I expected.

Not all miners use two outbound connections to support a dev fee.  I've seen ones that will just switch to a different pool for a period of time and then switch back.

Either way, I'm giving your sw a try again.

On my rig of 10 vegas I get about 1500 h/s more than SRB.   1800 h/s more than XMR-stak.  That's without doing any special config.

One last question for the time being.  Is there a detailed explanation for what each of the output columns represent in the stats?   Most of them are self explanatory but I'd like to know more about what the Pool value and #/# represent.  Also the pool xys share accepted (#/#/#).

[cryptomanman]

So far getting approximately 5 to 7% increase over xmr-stak on cnv8. That's great!  But, it seems to only work on about half of my rigs. They other half, it says it's initializing and getting work from the pool but the hashrate stays at 0 H/s. Same symptoms when trying to mine lyra2z also.

Same rig setups, though various models of cards. Ubuntu 16.04 server and Lubuntu 16.04, amdgpu-pro 17.30 and 18.30, server grade computers with Xeon CPU's, MSI and ASUS 470's, 480's, 560's, and 570's. No consistant pattern to which cards work or don't work with driver version, OS version, or card model that I been able to figure out.

Since there doesn't seem to be a way to enable any debug logging, I'm asking for some ideas here.

Thanks!

[kerney666]

OK - That's a really good response and that's what appears to be happening from my side as well.  You've addressed my concerns.  FWIW, using your sw:
> If I mine using supportXMR I get all of the strange hostnames.   These were what was concerning me.
> If I switch to MoneroOcean and I get the name I expected.

Not all miners use two outbound connections to support a dev fee.  I've seen ones that will just switch to a different pool for a period of time and then switch back.

Either way, I'm giving your sw a try again.

On my rig of 10 vegas I get about 1500 h/s more than SRB.   1800 h/s more than XMR-stak.  That's without doing any special config.

One last question for the time being.  Is there a detailed explanation for what each of the output columns represent in the stats?   Most of them are self explanatory but I'd like to know more about what the Pool value and #/# represent.  Also the pool xys share accepted (#/#/#).

No worries, glad we could sort it out! I was bit surprised to see the weird reverse mapped hostnames that supportxmr uses myself.

For the separate dev fee connection, we believe this is the most fair way of doing dev fee hashing. We do it in realtime, all the time. There is never ever any downtime for switching between pools, and the question of when you switch (early, late, random times etc) is removed completely. No penalty for restarting the miner often for anyone, highest possible granularity for splitting up hashes between user and dev. It's just better in every way imho.

For stats, we should really include a better documentation. For the time being though:

1) Shares states X/Y/Z: X=found shares, Y=accepted shares, Z=rejected shares. It seems there are cases where X != Y+Z after some time, I believe it's because we lose or never get a response for submitted shares. Need to look into it.

2) Poolside hashrate. This is imho the one stat you want for checking if a pool isn't cheating on you and the miner hashrate matches the expected realized hash over time. I believe some other miners calls it the "effective" hashrate. It's your hashrate based on accepted pool shares only, so dev fee and rejected shares are removed. It is also the basis for payments from the pool. After sufficient time has passed, it should be equal to 0.975 * miner hashrate, this assuming no network downtime etc.

[kerney666]

So far getting approximately 5 to 7% increase over xmr-stak on cnv8. That's great!  But, it seems to only work on about half of my rigs. They other half, it says it's initializing and getting work from the pool but the hashrate stays at 0 H/s. Same symptoms when trying to mine lyra2z also.

Same rig setups, though various models of cards. Ubuntu 16.04 server and Lubuntu 16.04, amdgpu-pro 17.30 and 18.30, server grade computers with Xeon CPU's, MSI and ASUS 470's, 480's, 560's, and 570's. No consistant pattern to which cards work or don't work with driver version, OS version, or card model that I been able to figure out.

Since there doesn't seem to be a way to enable any debug logging, I'm asking for some ideas here.

Thanks!

May I double check that you are running the latest version, v0.3.5? Also, are you doing any cpu mining in parallel when you start the miner?

[herrdrone]

This miner is great and thread has a lot of helpful information. Added this miner to mining software section: https://monerobenchmarks.info/tools.php  

[MoneroCrusher]

Tried the Linux miner with my proxy, proxy sends job to miner but the miner never starts hashing away even after minutes.
My workers are not connected to the internet for security purposes. Is there a way to solve this?

Code:

x@x:/teamredminer-v0.3.5-linux# ./start
          Team Red Miner version 0.3.5
[2018-11-01 22:58:50] Auto-detected AMD OpenCL platform 0
[2018-11-01 22:58:50] Initializing GPU 0.
[2018-11-01 22:58:52] Pool x.x.x.x login succeeded.
[2018-11-01 22:58:52] Pool x.x.x.x received new job. (job_id: JCvLEjTjdETh5efULZhaxvMOZbC8fd0)
[2018-11-01 22:58:52] Pool x.x.x.x set difficulty to 500054
[2018-11-01 22:58:57] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 2 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 7 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 8 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU 9 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU10 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats GPU11 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:58:57] Stats Total - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s
[2018-11-01 22:59:02] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 2 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 7 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 8 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU 9 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU10 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats GPU11 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:02] Stats Total - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s
[2018-11-01 22:59:07] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 2 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 7 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 8 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU 9 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU10 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats GPU11 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:07] Stats Total - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s
[2018-11-01 22:59:12] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 2 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 7 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 8 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU 9 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU10 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats GPU11 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-01 22:59:12] Stats Total - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s
[2018-11-01 22:59:12] Dev pool failed to connect.

I gave this rig internet acess too and it still stayed at 0 H/s. This time it's Baffin 550 (not Lexa Pro).

[misterkit]

So I just had my first crash with.  On a vega 56 it started reporting a 3kh hash rate...and a few minutes later it crashed.  I restarted it and it seems to be running ok.

Are there any plans for a hashrate monitor or the ability to restart a crashed gpu while miner is running?

What about a logging feature?

Other cn v 7 algorithms? Algo switching?

I also tried this on a mixed rig of 550s and a vega...it didn't like the 550s being involved.

[MoneroCrusher]

Here are my results (miner/pool comparison) for a RX 550 Baffin on Windows that I let mine for exactly 2 hours.

Code:

[2018-11-02 00:14:18] Stats GPU 0 - cnv8: 456.7 h/s, avg 473.1 h/s, pool 461.4 h/s 217/4
[2018-11-02 00:14:20] Stats GPU 0 - cnv8: 486.0 h/s, avg 473.1 h/s, pool 461.2 h/s 217/4
[2018-11-02 00:14:22] Stats GPU 0 - cnv8: 483.8 h/s, avg 473.1 h/s, pool 461.1 h/s 217/4
[2018-11-02 00:14:24] Stats GPU 0 - cnv8: 479.7 h/s, avg 473.1 h/s, pool 461.0 h/s 217/4
[2018-11-02 00:14:26] Stats GPU 0 - cnv8: 466.2 h/s, avg 473.1 h/s, pool 460.8 h/s 217/4

Pool side: 1 hour average: 453 H/s

So it's about 5% off but 2 hours is not very meaningful.

Edit: manual calculation
mining time: 7502 seconds
hashes: 3,467,622
=462,2 H/s
so in that case its spot on:
4 rejected shares = 1.84%
1.84% of 462.2 H/s = 8,5 H/s

= "supposed" hashrate without rejected shares = 470.7 H/s, which is much closer to the 473.1 H/s (avg)

[cryptomanman]

Yes, running the current 0.3.5 version. Yes, CPU mining going on in the background both on the cards that successfully initialize and those that don't.

Quick edit. Just tried starting without CPU mining on 1 rig. Same result.

So far getting approximately 5 to 7% increase over xmr-stak on cnv8. That's great!  But, it seems to only work on about half of my rigs. They other half, it says it's initializing and getting work from the pool but the hashrate stays at 0 H/s. Same symptoms when trying to mine lyra2z also.

Same rig setups, though various models of cards. Ubuntu 16.04 server and Lubuntu 16.04, amdgpu-pro 17.30 and 18.30, server grade computers with Xeon CPU's, MSI and ASUS 470's, 480's, 560's, and 570's. No consistant pattern to which cards work or don't work with driver version, OS version, or card model that I been able to figure out.

Since there doesn't seem to be a way to enable any debug logging, I'm asking for some ideas here.

Thanks!

May I double check that you are running the latest version, v0.3.5? Also, are you doing any cpu mining in parallel when you start the miner?

[Uaciuganadu]

Hello kerney666,

Good to see such an efficient miner. Any plans of adding direct algo switching for MoneroOcean? Would this work as it stands with the mm.js miner wrapper?

Please also for debugging purposes add an option to create vebrbose logs so we can submit them after crashes and a basic HTTP report like JCE or SRB.

[kerney666]

Hello kerney666,

Good to see such an efficient miner. Any plans of adding direct algo switching for MoneroOcean? Would this work as it stands with the mm.js miner wrapper?

Please also for debugging purposes add an option to create vebrbose logs so we can submit them after crashes and a basic HTTP report like JCE or SRB.

Thank you for the kind words! And, trust me, debug logs and better reporting is in our interest as well, even more so after the last couple of days .

We're currently trying to sort out initial issues to get the miner stable enough. We've tested a boatload of hours on different rigs, but it's never enough it seems.

As soon as we reach a stable point and have had breather we'll discuss the roadmap going forward. Adding more CN variants will definitely be in there.

[kerney666]

Team Red Miner v0.3.6 released

https://github.com/todxx/teamredminer/releases

Changes in v0.3.6

• Added support for Rx550 cards (gfx804).
• Improved stability on larger rigs, especially with weaker cpus.
• Improved error reporting on failed initialization.

Hopefully this is another step to achieving stability on larger rigs, especially with weaker cpus. It has been tested by one of the forum users who had both early initialization issues, then stability issues. His rigs have gone from crashing every 30-120 mins to running smoothly for 15+ hours except for (I think) a single crash due to insufficient voltage. I believe we have more work to do though, we'll monitor carefully and try to address all problems that appear.

For people with specific startup issues that are willing to help us nail them down and solve them, please reach out to me with a PM.

The ANN post will be updated shortly by todxx.

[wyzdic]

0.3.6 version feedback
Vega56 1448/950 0.875 2050 h/s 168w/card at wall
Vega64 1448/1100 0.875 2150 h/s 200w/card at wall
Rx550 1350/1905 480 h/s