Eliovp
Legendary
Offline
Activity: 1050
Merit: 1293
Huh?
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 28, 2016, 06:43:07 PM |
|
Just noticed this miner automatically determines the eth stratum protocol mode of the pool it is connecting to, at least for dwarf vs coinotron mode. Something I may try to add to Genoil's...
Strange, when I tried it did not want to connect to dwarfpool's 8080 port, only http 80 port was working. Ditto with any pools based on sammy's open-ethereum-pool.
|
|
|
|
nerdralph
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 28, 2016, 09:31:51 PM |
|
Just noticed this miner automatically determines the eth stratum protocol mode of the pool it is connecting to, at least for dwarf vs coinotron mode. Something I may try to add to Genoil's...
Strange, when I tried it did not want to connect to dwarfpool's 8080 port, only http 80 port was working. Ditto with any pools based on sammy's open-ethereum-pool. I tested with MPH port 20535 and Alpereum port 4001. Maybe it's just the pools auto-detecting the client stratum protocol. I'm still going to look at doing auto-detect on my fork of Genoil's client. When connecting to MPH, it sends an unsolicited mining.notify. Alpereum sends an unsolicited jsonrpc result. Dwarfpool requires the client to make a request before it responds. So it may be possible to auto-detect on the client.
|
|
|
|
yoyo1
Newbie
Offline
Activity: 47
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 29, 2016, 12:36:13 PM |
|
According to: RTFM https://github.com/genesismining/sgminer-gm/blob/master/doc/configuration.mdThank you for the guide. I'd like to summarize some findings: There are several ways of loading GPU via manipulating following parameters: *xintensity* put in config: "xintensity":"<value>" value=1~9999 *intensity* put in config: "intensity":"<value>" value=8~31 *rawintensity* put in config: "rawintensity":"<value>" value=1~2147483647 Keep in mind that only one parameter will work. So the config side related to GPU tweaking will look like: "gpu-powertune": "0", "worksize": "192", "name": "eth", "algorithm": "ethash", "gpu-threads": "1", "xintensity": "4096" *gpu-threads* is a number of mining threads per GPU I don't how effective can be this parameter changing but default is "1"
|
|
|
|
yoyo1
Newbie
Offline
Activity: 47
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 29, 2016, 01:24:55 PM |
|
I wonder what options should I specify for dual mining? Is it possible? May I use "ethash" and mine ETH & ETC at the same time for example?
|
|
|
|
scryptr
Legendary
Offline
Activity: 1797
Merit: 1028
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 29, 2016, 03:10:11 PM |
|
I wonder what options should I specify for dual mining? Is it possible? May I use "ethash" and mine ETH & ETC at the same time for example?
ETHEREUM (ETH) AND ETHEREUM CLASSIC (ETC) ARE ON DIFFERENT EPOCHS-- The DAG files woulkd be different in size and composition. Hash from one would be invalid on the other. Dual mining is done with a memory intensive algo (ETH) and a compute intensive algo like SiaCoin (SC). A dual miner is specially coded to manage two different algos without generating conflicts. SGminer is not a dual miner. --scryptr
|
|
|
|
yoyo1
Newbie
Offline
Activity: 47
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 29, 2016, 03:39:28 PM |
|
Thank you very much for the explanation. Can community expect to get some extra juice from the sgminer-gm?
And are there any news about AMD ADL and amdgpu-pro updates? How can it be possible to overclock AMD cards without flashing (i'm not so risky actually).
|
|
|
|
scryptr
Legendary
Offline
Activity: 1797
Merit: 1028
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 29, 2016, 04:08:05 PM Last edit: September 29, 2016, 09:07:30 PM by scryptr |
|
PROGRAMMERS CAN WORK MIRACLES--
But all I have heard for a year is that there is not much juice to squeeze from the DAG. Generating it on-the-fly was a big thing, saving start-up minutes.
Likely, card optimization will be the way to go. 29MH/s on the RX 480 is top speed reported. New cards (480x, 490, etc) are still top secret, not expected until next year. I search, and see the same old tech blogs. --scryptr
|
|
|
|
Inkdatar
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 29, 2016, 05:30:29 PM |
|
According to: RTFM https://github.com/genesismining/sgminer-gm/blob/master/doc/configuration.mdThank you for the guide. I'd like to summarize some findings: There are several ways of loading GPU via manipulating following parameters: *xintensity* put in config: "xintensity":"<value>" value=1~9999 *intensity* put in config: "intensity":"<value>" value=8~31 *rawintensity* put in config: "rawintensity":"<value>" value=1~2147483647 Keep in mind that only one parameter will work. So the config side related to GPU tweaking will look like: "gpu-powertune": "0", "worksize": "192", "name": "eth", "algorithm": "ethash", "gpu-threads": "1", "xintensity": "4096" *gpu-threads* is a number of mining threads per GPU I don't how effective can be this parameter changing but default is "1" I noticed your xintensity value is 4096. If I put that to be more than 1024, there are loads of hardware errors.
|
|
|
|
nerdralph
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 29, 2016, 09:10:03 PM |
|
PROGRAMMERS CAN WORK MIRACLES--
But all I have heard for a year is that there is not much juice to squeeze from the DAG. Generating it on-the-fly was a big thing, saving start-up minutes.
Likely, card optimization will be the way to go. 29MH/s on the RX 480 is top speed reported. Newcards (480x, 490, etc) are still top secret, not expected until next year. I search, and se the same old tech blogs. --scryptr
Unless you can find a flaw in the ethash algorithm, it is impossible to get more than 32Mh/s from a card like the RX480 with 256GB/s of memory bandwidth (i.e. memory clocked at 2Ghz). This is because each hash requires 8MB of random memory reads.
|
|
|
|
scryptr
Legendary
Offline
Activity: 1797
Merit: 1028
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 30, 2016, 12:01:55 PM |
|
PROGRAMMERS CAN WORK MIRACLES--
But all I have heard for a year is that there is not much juice to squeeze from the DAG. Generating it on-the-fly was a big thing, saving start-up minutes.
Likely, card optimization will be the way to go. 29MH/s on the RX 480 is top speed reported. Newcards (480x, 490, etc) are still top secret, not expected until next year. I search, and se the same old tech blogs. --scryptr
Unless you can find a flaw in the ethash algorithm, it is impossible to get more than 32Mh/s from a card like the RX480 with 256GB/s of memory bandwidth (i.e. memory clocked at 2Ghz). This is because each hash requires 8MB of random memory reads. THANK YOU FOR THE EXPLANATION-- I think that you have explained the theoretical maximum hashrate for an RX 480. Looking at posted data from various sources, a well tuned RX 480 Ethereum rig will mine at 29MH/s, and an RX 470 rig will mine at 27MH/s per card. It may take BIOS mods and a carefully adjusted OS to get there. Out of the box, the cards will mine at 22-24MH/s completely stock. RX 460 cards will reportedly mine at 10-11MH/s stock, similar to the performance of a previous generation R7 370 card, but at as little as 1/2 the wattage. I have seen posts at higher hash rates for single-card rigs running a short duration, but none more than the theoretical maximum as you explained it. The next generation of cards (Vega) may be a game changer, or may not. The top cards will be using a new memory type, and that does not always translate to better mining performance. I keep looking for new information, but it has not surfaced yet. --scryptr
|
|
|
|
sammy007
Legendary
Offline
Activity: 1904
Merit: 1003
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 01, 2016, 08:58:34 AM |
|
|
|
|
|
Kevinatin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 01, 2016, 10:19:25 AM |
|
PROGRAMMERS CAN WORK MIRACLES--
But all I have heard for a year is that there is not much juice to squeeze from the DAG. Generating it on-the-fly was a big thing, saving start-up minutes.
Likely, card optimization will be the way to go. 29MH/s on the RX 480 is top speed reported. Newcards (480x, 490, etc) are still top secret, not expected until next year. I search, and se the same old tech blogs. --scryptr
Unless you can find a flaw in the ethash algorithm, it is impossible to get more than 32Mh/s from a card like the RX480 with 256GB/s of memory bandwidth (i.e. memory clocked at 2Ghz). This is because each hash requires 8MB of random memory reads. THANK YOU FOR THE EXPLANATION-- I think that you have explained the theoretical maximum hashrate for an RX 480. Looking at posted data from various sources, a well tuned RX 480 Ethereum rig will mine at 29MH/s, and an RX 470 rig will mine at 27MH/s per card. It may take BIOS mods and a carefully adjusted OS to get there. Out of the box, the cards will mine at 22-24MH/s completely stock. RX 460 cards will reportedly mine at 10-11MH/s stock, similar to the performance of a previous generation R7 370 card, but at as little as 1/2 the wattage. I have seen posts at higher hash rates for single-card rigs running a short duration, but none more than the theoretical maximum as you explained it. The next generation of cards (Vega) may be a game changer, or may not. The top cards will be using a new memory type, and that does not always translate to better mining performance. I keep looking for new information, but it has not surfaced yet. --scryptr That is true. that is the reason why the R9 390 is faster than the RX 480 as its memory bandwidth is double that of the RX 480 if running at the same memory speed.
|
|
|
|
nerdralph
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 03, 2016, 03:05:20 AM |
|
Looks like there might be a bug handling the DAG change: [23:55:33] Error -2: Setting args for the DAG kernel and/or executing it. [23:55:33] Error: clSetKernelArg of all params failed. [23:55:33] GPU 0 failure, disabling!
I hit q(uit), started sgminer-gm, and it is once again working fine. I was testing with a single GPU (290x).
|
|
|
|
Slydrule
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 04, 2016, 03:56:46 PM |
|
I'm getting steady 30MH/s on each Fury X on stock clocks (1050/500). Claymore's can only get about 28MH. A 390 at 1040Mhz gets 29Mh, with some overclocking I can surely can 32-33MH, but my cards warm up too much. Definitely the best miner out there.
The only issue I can spot is the CPU usage, which makes this miner basically worthless on weak CPUs. I couldn't run it on a single-core AMD CPU and a friend of mine had his rig crashing with a dual core Celeron installed. most mining rigs have very weak CPUs, and if this miner gets updated to support them, I am sure it will get much more traction.
Has it been determined that this issues running on systems with weak CPUs is real? Is there a fix coming? I am wondering if this is the problem I am having on my multi-gpu mining rigs. One GPU run at the right hash rate while the others run at half. No matter what I do with the settings I cannot resolve this issue. Both rigs have single core AMD CPUs. I would love to use sgminer with its RPC capabilities but I am not going to invest in bigger CPUs for it. Thanks.
|
|
|
|
antantti
Legendary
Offline
Activity: 1176
Merit: 1015
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 04, 2016, 04:39:09 PM |
|
I'm getting steady 30MH/s on each Fury X on stock clocks (1050/500). Claymore's can only get about 28MH. A 390 at 1040Mhz gets 29Mh, with some overclocking I can surely can 32-33MH, but my cards warm up too much. Definitely the best miner out there.
The only issue I can spot is the CPU usage, which makes this miner basically worthless on weak CPUs. I couldn't run it on a single-core AMD CPU and a friend of mine had his rig crashing with a dual core Celeron installed. most mining rigs have very weak CPUs, and if this miner gets updated to support them, I am sure it will get much more traction.
Has it been determined that this issues running on systems with weak CPUs is real? Is there a fix coming? I am wondering if this is the problem I am having on my multi-gpu mining rigs. One GPU run at the right hash rate while the others run at half. No matter what I do with the settings I cannot resolve this issue. Both rigs have single core AMD CPUs. I would love to use sgminer with its RPC capabilities but I am not going to invest in bigger CPUs for it. Thanks. I am running 4 x hawaii with core2duo e8400. Cpu usage max 5%, W10.
|
|
|
|
Natilam
Newbie
Offline
Activity: 14
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 04, 2016, 05:28:41 PM |
|
I'm getting steady 30MH/s on each Fury X on stock clocks (1050/500). Claymore's can only get about 28MH. A 390 at 1040Mhz gets 29Mh, with some overclocking I can surely can 32-33MH, but my cards warm up too much. Definitely the best miner out there.
The only issue I can spot is the CPU usage, which makes this miner basically worthless on weak CPUs. I couldn't run it on a single-core AMD CPU and a friend of mine had his rig crashing with a dual core Celeron installed. most mining rigs have very weak CPUs, and if this miner gets updated to support them, I am sure it will get much more traction.
Has it been determined that this issues running on systems with weak CPUs is real? Is there a fix coming? I am wondering if this is the problem I am having on my multi-gpu mining rigs. One GPU run at the right hash rate while the others run at half. No matter what I do with the settings I cannot resolve this issue. Both rigs have single core AMD CPUs. I would love to use sgminer with its RPC capabilities but I am not going to invest in bigger CPUs for it. Thanks. If you search Wolf0's post in this thread, you will find that he posted a fix for the CPU usage bug.
|
|
|
|
nerdralph
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 04, 2016, 07:14:34 PM |
|
I'm getting steady 30MH/s on each Fury X on stock clocks (1050/500). Claymore's can only get about 28MH. A 390 at 1040Mhz gets 29Mh, with some overclocking I can surely can 32-33MH, but my cards warm up too much. Definitely the best miner out there.
The only issue I can spot is the CPU usage, which makes this miner basically worthless on weak CPUs. I couldn't run it on a single-core AMD CPU and a friend of mine had his rig crashing with a dual core Celeron installed. most mining rigs have very weak CPUs, and if this miner gets updated to support them, I am sure it will get much more traction.
Has it been determined that this issues running on systems with weak CPUs is real? Is there a fix coming? I am wondering if this is the problem I am having on my multi-gpu mining rigs. One GPU run at the right hash rate while the others run at half. No matter what I do with the settings I cannot resolve this issue. Both rigs have single core AMD CPUs. I would love to use sgminer with its RPC capabilities but I am not going to invest in bigger CPUs for it. Thanks. If you search Wolf0's post in this thread, you will find that he posted a fix for the CPU usage bug. Here it is again for those that don't want to look back through the thread. I can confirm it no longer hogs the CPU on one core. https://ottrbutt.com/miner/downloads/sgminer-gm/sgminer-gm-wolf-09222016.zipcopy sgminer.exe from the zip to the existing install directory.
|
|
|
|
Slydrule
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 05, 2016, 02:00:44 AM Last edit: October 05, 2016, 06:36:36 PM by Slydrule |
|
I'm getting steady 30MH/s on each Fury X on stock clocks (1050/500). Claymore's can only get about 28MH. A 390 at 1040Mhz gets 29Mh, with some overclocking I can surely can 32-33MH, but my cards warm up too much. Definitely the best miner out there.
The only issue I can spot is the CPU usage, which makes this miner basically worthless on weak CPUs. I couldn't run it on a single-core AMD CPU and a friend of mine had his rig crashing with a dual core Celeron installed. most mining rigs have very weak CPUs, and if this miner gets updated to support them, I am sure it will get much more traction.
Has it been determined that this issues running on systems with weak CPUs is real? Is there a fix coming? I am wondering if this is the problem I am having on my multi-gpu mining rigs. One GPU run at the right hash rate while the others run at half. No matter what I do with the settings I cannot resolve this issue. Both rigs have single core AMD CPUs. I would love to use sgminer with its RPC capabilities but I am not going to invest in bigger CPUs for it. Thanks. If you search Wolf0's post in this thread, you will find that he posted a fix for the CPU usage bug. Here it is again for those that don't want to look back through the thread. I can confirm it no longer hogs the CPU on one core. https://ottrbutt.com/miner/downloads/sgminer-gm/sgminer-gm-wolf-09222016.zipcopy sgminer.exe from the zip to the existing install directory. Thanks. I will give it a try. UPDATE: I tried this version and I get the same result. I have no idea what is causing this problem but I would love to hear any suggestions. Thanks. Update II: I resolved the issue. It turns out rather than increasing the fan speed from the lowest speed in the fan range, the miner was decreasing the GPU speed when the temp reached the target temperature but only on 2 GPUs for some reason. I resolved the issue by turning off auto-fan and setting the fan speed high enough to ensure the GPUs stay under the target temp. When I get a chance to shut it down I will try to specify fan ranges explicitly for each GPU.
|
|
|
|
Gotottack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 08, 2016, 04:05:30 PM |
|
I'm getting steady 30MH/s on each Fury X on stock clocks (1050/500). Claymore's can only get about 28MH. A 390 at 1040Mhz gets 29Mh, with some overclocking I can surely can 32-33MH, but my cards warm up too much. Definitely the best miner out there.
The only issue I can spot is the CPU usage, which makes this miner basically worthless on weak CPUs. I couldn't run it on a single-core AMD CPU and a friend of mine had his rig crashing with a dual core Celeron installed. most mining rigs have very weak CPUs, and if this miner gets updated to support them, I am sure it will get much more traction.
Has it been determined that this issues running on systems with weak CPUs is real? Is there a fix coming? I am wondering if this is the problem I am having on my multi-gpu mining rigs. One GPU run at the right hash rate while the others run at half. No matter what I do with the settings I cannot resolve this issue. Both rigs have single core AMD CPUs. I would love to use sgminer with its RPC capabilities but I am not going to invest in bigger CPUs for it. Thanks. If you search Wolf0's post in this thread, you will find that he posted a fix for the CPU usage bug. Here it is again for those that don't want to look back through the thread. I can confirm it no longer hogs the CPU on one core. https://ottrbutt.com/miner/downloads/sgminer-gm/sgminer-gm-wolf-09222016.zipcopy sgminer.exe from the zip to the existing install directory. Thanks. I will give it a try. UPDATE: I tried this version and I get the same result. I have no idea what is causing this problem but I would love to hear any suggestions. Thanks. Update II: I resolved the issue. It turns out rather than increasing the fan speed from the lowest speed in the fan range, the miner was decreasing the GPU speed when the temp reached the target temperature but only on 2 GPUs for some reason. I resolved the issue by turning off auto-fan and setting the fan speed high enough to ensure the GPUs stay under the target temp. When I get a chance to shut it down I will try to specify fan ranges explicitly for each GPU. I removed the auto fan and use the MSI afterburner to many the fan speed, it is much better.
|
|
|
|
Eliovp
Legendary
Offline
Activity: 1050
Merit: 1293
Huh?
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 15, 2016, 10:21:33 AM |
|
|
|
|
|
|