ok, here are my reports so far.
sometimes, the miner just doesnt submit any share for a long time, and needs to restart the miner. it hashes though, but no submits.
and my mixed gpu rig just cannot get the reported hashrate, both pool, and and client (pool report).
my uniform rig (all the same gpus) is ok.
sorry, cant back my reports with facts since we dont have logging yet.
Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 129. (Read 211877 times)
November 17, 2018, 04:21:05 PM
November 16, 2018, 04:14:30 PM
can you add versioning on the thread title? so we can be informed if there is an update?
Excellent idea, we'll add it for the next release.
can you add versioning on the thread title? so btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.
We can support an early abort mechanism, but it's not included right now. NiceHash is the only place where you would want it really. Like pbfarmer replied, you are throwing away gpu work every time a new job arrives otherwise. But, if you are 100% guaranteed than any found shares in the ongoing work will be rejected by the pool, then you should abort. We can look into introducing this mechanism if you want to try it.
great! an option for an early abort would be nice. sometimes i like to mine at nicehash. since they wont pay for stales anyway, so an option for this will be helpful.
thanks.
oh, and btw, i tried srb with micron, and it can achieve 1kh/s. maybe you can do something about it. no bios/oc changed.
November 16, 2018, 03:33:53 PM
Hello,
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors
In all cases my best results are 900H/s.
Thanks in advance!
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors
In all cases my best results are 900H/s.
Thanks in advance!
good ETH straps =/= good CN straps.
One click BIOS straps are crap anyway.
And this miner benefits more from higher core clocks.
November 16, 2018, 01:57:48 PM
Hello,
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors
In all cases my best results are 900H/s.
Thanks in advance!
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors
In all cases my best results are 900H/s.
Thanks in advance!
November 16, 2018, 11:38:50 AM
Here's an HTTP interface I wrote for the API. Requires python/pip to be installed first, docs on GitHub should explain the rest.
https://github.com/rdugan/cgminerhttpinterface
Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier.
After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner. Parameters are optional - values here are server defaults. Ctrl-c to exit.
Enjoy!
https://github.com/rdugan/cgminerhttpinterface
Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier.
After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner. Parameters are optional - values here are server defaults. Ctrl-c to exit.
Code:
SET HTTP_PORT=80
SET API_HOST=localhost
SET API_PORT=4028
start "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%
Enjoy!
excellent!
can you add a function reload config files, so it do not need to restart the miner?
Hi! I can't say that is on our TODO list, the downside of restarting the miner shouldn't be that big. Can you tell me more about what you would like to achieve with the changed config? Switching to another pool, another algo, turning on/off some gpus?
November 16, 2018, 11:35:56 AM
can you add versioning on the thread title? so we can be informed if there is an update?
Excellent idea, we'll add it for the next release.
can you add versioning on the thread title? so btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.
We can support an early abort mechanism, but it's not included right now. NiceHash is the only place where you would want it really. Like pbfarmer replied, you are throwing away gpu work every time a new job arrives otherwise. But, if you are 100% guaranteed than any found shares in the ongoing work will be rejected by the pool, then you should abort. We can look into introducing this mechanism if you want to try it.
November 15, 2018, 10:20:16 PM
Here's an HTTP interface I wrote for the API. Requires python/pip to be installed first, docs on GitHub should explain the rest.
https://github.com/rdugan/cgminerhttpinterface
Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier.
After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner. Parameters are optional - values here are server defaults. Ctrl-c to exit.
Enjoy!
https://github.com/rdugan/cgminerhttpinterface
Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier.
After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner. Parameters are optional - values here are server defaults. Ctrl-c to exit.
Code:
SET HTTP_PORT=80
SET API_HOST=localhost
SET API_PORT=4028
start "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%
Enjoy!
excellent!
can you add a function reload config files, so it do not need to restart the miner?
I have no affiliation w/ this miner, and the API is read only at this point - you'd have to ask the developers of the miner for this feature.
November 15, 2018, 10:18:59 PM
can you add versioning on the thread title? so we can be informed if there is an update?
btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.
btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.
What pool do you use? supportxmr accepts most stales - if your pool does too, then you don't want to use fastjobswitch. You'd just be throwing away work.
November 15, 2018, 06:05:53 PM
can you add versioning on the thread title? so we can be informed if there is an update?
btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.
btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.
November 15, 2018, 04:24:45 PM
oh great , I will wait
November 15, 2018, 08:55:42 AM
Thanks I will try it this weekend, the rig using teamredminer crash during the night ( same setting I use without problem on srb) and I lost remote access to reboot it.
Is there a way to force win 10 restart when miner crash ?
Is there a way to force win 10 restart when miner crash ?
The watchdog will be included in the next release, should be out in a few days.
November 15, 2018, 04:10:44 AM
What is the best tuning for RX Vega 56 and 64 reference blower.
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
https://ibb.co/b5ekC0
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
https://ibb.co/b5ekC0
When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!
I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though
.Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?
Try 1480cc 1080mc for vega64 and 56 flashed to 64 i get 2100-2190hs depending on brand
And 1480cc 925mc for vega 56 I get 2050hs for this.
All at 16+14.
Power table reg mod for 899mv
Thanks I will try it this weekend, the rig using teamredminer crash during the night ( same setting I use without problem on srb) and I lost remote access to reboot it.
Is there a way to force win 10 restart when miner crash ?
November 15, 2018, 01:32:40 AM
Here's an HTTP interface I wrote for the API. Requires python/pip to be installed first, docs on GitHub should explain the rest.
https://github.com/rdugan/cgminerhttpinterface
Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier.
After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner. Parameters are optional - values here are server defaults. Ctrl-c to exit.
Enjoy!
https://github.com/rdugan/cgminerhttpinterface
Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier.
After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner. Parameters are optional - values here are server defaults. Ctrl-c to exit.
Code:
SET HTTP_PORT=80
SET API_HOST=localhost
SET API_PORT=4028
start "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%
Enjoy!
excellent!
can you add a function reload config files, so it do not need to restart the miner?
November 14, 2018, 08:42:15 PM
What is the best tuning for RX Vega 56 and 64 reference blower.
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!
I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though
.Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?
Try 1480cc 1080mc for vega64 and 56 flashed to 64 i get 2100-2190hs depending on brand
And 1480cc 925mc for vega 56 I get 2050hs for this.
All at 16+14.
Power table reg mod for 899mv
November 14, 2018, 05:59:04 PM
You know, this is a little interesting. Nanopool has a broken rpc implementation which causes issues when e.g. submitting two or more shares in quick succession. Now, we assumed that we'd still get replies for all submitted shares, but there could cases where they actually drop rpc requests. I didn't do the fix though, need to check with todxx.
Comparing pool payouts is a different thing though. Unless you're sure the pools hit exactly 100% avg luck over the same period, it doesn't say much. The poolside hashrate displayed in the miner should match your miner hashrate minus dev fee and any rejected shares. If that looks good, we can't really do much more from a miner dev perspective. If that number is ok, but the pool reports a different hashrate, something is fishy.
After mining for a while on supportxmr, everything was good, readings on miner were avg 1850h/s and pool 1790h/s.
Yesterday my readings were avg 1850h/s and pool was down at 1750, now I'm down at avg 1850h/s and pool 1662h/s.
I've also switched to this pool yesterday, two really slow miners sometime before readings. I'll try switching them back to another pool..!
Supportxmr is generally nice allowing a static diff for maybe 1 share every 5 secs. It’s not super nice to run that way 100% of the time, but if you’re nervous about poolside hashrate not lining up with miner hashrate, that’s the way to go. 10k diff is the lowest allowed though, so add +10000 after your wallet.
November 14, 2018, 05:25:06 PM
You know, this is a little interesting. Nanopool has a broken rpc implementation which causes issues when e.g. submitting two or more shares in quick succession. Now, we assumed that we'd still get replies for all submitted shares, but there could cases where they actually drop rpc requests. I didn't do the fix though, need to check with todxx.
Comparing pool payouts is a different thing though. Unless you're sure the pools hit exactly 100% avg luck over the same period, it doesn't say much. The poolside hashrate displayed in the miner should match your miner hashrate minus dev fee and any rejected shares. If that looks good, we can't really do much more from a miner dev perspective. If that number is ok, but the pool reports a different hashrate, something is fishy.
After mining for a while on supportxmr, everything was good, readings on miner were avg 1850h/s and pool 1790h/s.
Yesterday my readings were avg 1850h/s and pool was down at 1750, now I'm down at avg 1850h/s and pool 1662h/s.
I've also switched to this pool yesterday, two really slow miners sometime before readings. I'll try switching them back to another pool..!
November 14, 2018, 05:23:06 PM
What is the best tuning for RX Vega 56 and 64 reference blower.
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!
I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though
.Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?
1.25v (56) and 1.356mv (64) are the real, coded in bios, voltages for the mem. The values in your profile tool of choice are for the controller/infinityfabric/SOC/whatever you call it, and are really a floor under the core voltage, as they seem to share the same line.
As for the clock/voltage drop in hwinfo64 vs your settings, it's a result of the applied load, and the AVFS feature of vegas. In general, higher load + lower voltage = bigger clock throttle.
November 14, 2018, 05:13:43 PM
What is the best tuning for RX Vega 56 and 64 reference blower.
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
https://ibb.co/b5ekC0
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
https://ibb.co/b5ekC0
When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!
I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though
.Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?
November 14, 2018, 04:57:52 PM
What is the best tuning for RX Vega 56 and 64 reference blower.
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?
PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?
When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!
I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though
. November 14, 2018, 04:52:08 PM
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!
As others have pointed out, this stuff doesn't really belong in the miner, and is incredibly easy to add to your startup script...
Apply settings w/ overdriventool:
"
Restart gpus w/ devcon (vegas):
"
timeout /t 3
"
For example:
Code:
"C:\Users\pbfarmer\mining\OverdriveNTool.exe" -consoleonly -r1 -r2 -p1vega-profile-1 -p2vega-profile-2
timeout /t 3
"C:\Users\pbfarmer\mining\devcon.exe" disable "PCI\VEN_1002&DEV_687F"
timeout /t 3
"C:\Users\pbfarmer\mining\devcon.exe" enable "PCI\VEN_1002&DEV_687F"
timeout /t 3
teamredminer.exe ...
timeout /t 3
"C:\Users\pbfarmer\mining\devcon.exe" disable "PCI\VEN_1002&DEV_687F"
timeout /t 3
"C:\Users\pbfarmer\mining\devcon.exe" enable "PCI\VEN_1002&DEV_687F"
timeout /t 3
teamredminer.exe ...
Btw, restarting w/ devcon shouldn't be necessary w/ any recent driver version.
Thank you pbfarmer, works, and it is very simple (now for me too) :-)
I know there is no need to enable/disable Vegas on Adrenalin drivers, But, if my one problematic vega 56 "hang" on mining, i need to enable/disable it and again apply overdriveNtool (sometimes, not always, when card crash, it was reset in overdrive). I don't know why, but disable / enable and reapply ONT work for my rig in most cases on different miners.
We'll detect the state where the miner thread(s) for a gpu is stuck in an OpenCL API call, and there has been zero new hashes reported for the gpu for ~20 secs. At that point we (1) attempt to shut down the miner, like if you'd press ctrl-c and (2) execute a user .bat/shell script in a forked process, i.e. in parallel with the shutdown.
Now, what you choose to do in that .bat/shell script is entirely up to you. If you're sure you'll get an ok miner shutdown, then wait 20 secs + reset cards + apply clocks + start miner, in your .bat file. For others, it's more likely they'll do a "shutdown /r now". I mean, on my testing workstation I'm even having a hard time to get a clean reboot when I mistreat my Vega too badly, I need a manual power cycle. So, in the general case the guarantees we can provide are very weak. We'll let you run a .bat file, that's pretty much it.
For examples, sure, we can whip up some restart.bat examples, or other people can post theirs here. I have the devcon Vega restart snippets somewhere, been a while since I last used them...
Kerney thanks for clarification, now with the help and examples, everything is clear to me, and I know that reboot is safer solution...
For testing start.bat now, i was forced to close down the miner after 1 day and 22 hours of mining without a problem :-)
Great stable miner is TRM!
Jump to: