kerney, when developing watchdog, can you make option to: restart miner + reset vega cards + reapply OverdriveNtool? Like SRB have?
For me, never need to reboot whole rig, restarting, reseting vega and reapply clocks and voltages and mining is ok again...

And is it possible now in start.bat input code to reset vega cards with devcon or something, apply overdriveNtool and start mining? Any examples?

Txs!

Eish, sorry to ask, but how do I do that?

One of my rigs, the cards are being picked up by software like afterburner, device manager etc., but no mining software sees the cards. Any ideas?

terry1

Hi dev,my 6xvega cannot login pool.Do you have any idea?

bat is :    teamredminer.exe -a cnv8 -o stratum+tcp://xmrv7-bj.ss.poolin.com:443 -u terry1.%computername%   -p x

thanks ku4eto,  7+7 for my 470/480/570/580 4G is ok
v0.3.7 in auto = bsod or 0h/s
v0.3.6 auto = ok .

no card  monitor connected .

I'm glad to hear the miner is running well for you and that the new features are going to good use
The problem of hashrates varying is known to us, and seems to happen with other miners as well.  We plan to address this in the future so that max hashrate is always achieved, but we don't have an ETA for when we will get to that.
Lately we've mostly been working on getting the miner to be stable for everyone.

Hi ku4eto,

These stability issues seem to have no end.  It seems like every time we change something to get some rigs to be more stable, some else's start having problems.

That said, can you provide a bit more information about your rig and how the miner is behaving?
What OS are you running?
What version drivers are you using?
What GPUs are you running?
Can you post the output of the miner when it is having the issues you described?

This information would help us a lot in trying to find the cause of the problem.

Yes, with X.
I tried. It did'nt help.

Also, i get 0 h/s for most of the cards.
Only 1 or 2  cards from each start mining.

I tried to run the miner with stock clocks and voltages, with config 2+2...  Nothing helps.
Strange thing is that i can mine on my rigs without any problems ethash or Cryptonight v7, but have problems with v8.
SRB crashes out in 1-2 hours, TRM gives 0 h/s on almost all cards.

hi man, nice results! please can u share with me what cards are u using for each number? also maybe timings for elpida and sasmung? im not able to go above 950h/s or so...u have 4gb or 8gb?

Miner hangs the RIG when trying to close it.
Same problem on two different RIG's.
1- G3900 / ram 4gb / 4xRX570 4GB + 3 RX470 8GB / LTSB 14393 / 18.6.1
2- G3900 / ram 4gb / 7xRX470 4GB /  / LTSB 14393 / 18.6.1

hello, hope this helps someone:

my bat:
teamredminer.exe -a cnv8 -o stratum+tcp://xmr-eu1.nanopool.org:14444 -u mywallet -p x -d 0,1,2,3,4,5,6,7,8,9,10,11 --cn_config 7+7,7+7,7+7,8+8,8+8,8+8,7+7,8+8,8+8,8+8,7+7,8+8

my cards
core is for all cards 1200/900mV, mem is or each cards below:

1   XTR 8G Hynix 2200 H5GQ8H24MJR
2   XTR 8G Hynix 75,4 2225 H5GQ8H24MJR

3   GIGABYTE RX 580 GAMING 4 GB  Hynix 76.1 2000 H5GC4H24AJR
4   XFX RX 580 GTS XXX 8 GB Samsung 73.8 2025 K4G80325FB

5   GIGABYTE RX 580 GAMING 8 GB Hynix 74.4 2200 H5GC8H24MJR
6   GIGABYTE RX 580 GAMING 8 GB Hynix 78.2 2200 H5GC8H24MJR

7   GIGABYTE RX 580 GAMING 4 GB Hynix 73.9 2000 H5GC4H24AJR
8   GIGABYTE RX 580 GAMING 4 GB Hynix 71,5 2000 H5GC4H24AJR
9   GIGABYTE RX 580 GAMING 4 GB Hynix 75.8 2000 H5GC4H24AJR
10 GIGABYTE RX 580 GAMING 4 GB Hynix 77.2 1975 H5GC4H24AJR
 
11 Sapphire PULSE RX 580 8 GB Samsung 76.3 2050 K4G80325FB
12 GIGABYTE AORUS RX 580 8 GB Hynix 71,3 2100 H5GC8H24MJR

this is my results:
855
871
912
953
858
860
912
755
910
894
1032
822

i dont understand why i cant get above 900 for almost all cards..any advice?
P.S. ignore cn_config order as it is not the same, just 4GB has 7+7 and 8gb has 8+8 results and my cards match,thats important.

ku4eto@KU4ETO:/mnt/c/Users/ku4eto/Desktop$ echo -n "gpu|1" | nc 192.168.0.106 4028
STATUS=S,When=1541273696,Code=17,Msg=GPU1,Description=TeamRedMiner 0.3.5|GPU=1,Enabled=Y,Status=Alive,Temperature=0.00,Fan Speed=0,Fan Percent=0,GPU Clock=0,Memory Clock=0,GPU Voltage=0.000,GPU Activity=0,Powertune=0,MHS av=0.001071,MHS 30s=0.001073,KHS av=1.071,KHS 30s=1.073,Accepted=3513,Rejected=2,Hardware Errors=0,Utility=2.115,Intensity=20,XIntensity=0,RawIntensity=0,Last Share Pool=0,Last Share Time=1541273664,Total MH=106737536.0000,Diff1 Work=105460424.693228,Difficulty Accepted=105390424.41133447,Difficulty Rejected=60000.24162330,Last Share Difficulty=30000.12081165,Last Valid Work=1541273664,Device Hardware%=0.0000,Device Rejected%=0.0569,Device Elapsed=99665|

Ah, we should integrate the CN config better into the API.

The numbers are only about the nr of pads per thread, so directly related to mem consumed. The +- is a little mode tweak that sometimes does nothing and other times something.

If your cards are 4GB, 8+8 would consume everything, and it won't work. 7+7 or 8+7 should be doable depending on how much the driver has grabbed on the card(s) already.

It's an unfortunate side effect of the algo and the efficiency level of this miner in the various stages of CN. I'm 100% sure we will solve it in a good way in the end though. See I reply I wrote ~30 mins ago here: https://bitcointalk.org/index.php?topic=5059817.msg47528064#msg47528064 for more details.

Intensity: 20

Ha! That would def be cheating, wouldn't it? No, I can assure you that the lower power draw is from the continuous gpu work. After all, cpu verifications are for found shares only, so depending on your pool diff you maybe crunch one CN hash on the cpu every 10 secs (max)? It's tiny work in the grand scheme of things. Love the question though!

Thanks for reporting back! In the current version our miner doesn't have cpu verification of the hashes, probably the only one that doesn't. We just send everything to the pool and let them check the shares. We're just about to add the cpu verification parts though, so when that's in place we will be reporting bad shares as "HW errors" as well and not piss of the pool(s) when you push your mem straps too hard .

echo -n "gpu|N" | nc IP PORT > log.txt 

#!/bin/bash

echo -n "gpucount" | nc IP PORT > log.txt
GPU_COUNT=$(grep -oP '(?<=Count=)\w+' log.txt)

i=0

while [ $i -lt $GPU_COUNT ]
do
        echo -n "gpu|$i" /n | nc IP PORT /n >> log.txt
        true $(( i++ ))
done


sed -i 's/STATUS/\n&/g' log.txt
sed -i '1,2d' log.txt
sed -i 's/^.*GPU=/GPU=/' log.txt
sed -i 's/Temperature=0.00.*KHS//' log.txt
sed -i 's/Utility=[0-9].*Rejected%=[0-9]\.[0-9]//' log.txt
echo -e  >> log.txt

We haven't changed anything API-related per se, but maybe you're hitting this thing: there is a very confusing design aspect with the sgminer API that we just had to follow to be compatible. The json keys for e.g. avg hashrate last N secs change when you change the period between prints. We did change the default period from 60 secs to 30 secs at some point, so the API keys have changed as well. The proper (and annoying) way to do it is to first send a "config" command, check the reported "Log Interval" value there. That value, in our case "30" for 30 secs, will then be used in the keys for all other messages, for example the "summary" command will return the key ""KHS 30s". Imho it's an idiotic design, but we had to follow it. We have a command line option for changing the period. If there's anything else you're noticing, let me know.


This looks very strange. We only have one pool connection that is shared by all cards, and the shares we submit are for sure CNv8. I'm guessing the pool might not have updated their error message after the fork? Moreover, in your printout above you have 0.46% rejected shares though, nothing out of the ordinary. I tried the same pool now, no problem for my 550/580/Vega 64 test workstation. In the reported stats every 30 secs, are all four cards hashing ok?