Search content
Sort by
Showing 20 of 80 results by Gagana
Re: [Awesome Miner]- Powerful Windows GUI to manage and monitor up to 5000 miners
Hi guys! I have a bunch of iBeLink DM11G with Awesome Miner to control them. When I change the pool via the Awesome Miner software, it works, but until any miner reboot. After rebooting I see the same pool configuration as before any change implemented. Looks like the Awesome miner does not save the new pool configuration.
When I change the pool configuration in the web interface of the miner itself, I have to press "Save configuration" button to really save the new config. Patrick, could you resolve it?
When I change the pool configuration in the web interface of the miner itself, I have to press "Save configuration" button to really save the new config. Patrick, could you resolve it?
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v10.1 (Windows/Linux)
Hi, Mr.Claymore
Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
I guess that there are people who need the opposite from what you describe (they need the -minspeed to get triggered from internet connection loss). I am not one of them but I am sure that there are cases where that makes sense.Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
I agree with you though on what you are saying. I would modify your request like this:
"Please add a flag that indicates whether internet connection loss will trigger -minspeed"
Ok I will add an option in next update so you can set if "-minspeed" should work if miner cannot reach pools or not.
Yes, the default behavior is exactly how i use this flag.
I am one of the users that suffer from the already reported problem:
Every 2- 3 days my internet connection drops and reconnects after 5 minutes.
After reconnection the cards work at a lower speed than normal almost half speed.
I can easily reproduce it with just unplugging and replugging the Ethernet cable.
Only solution was for me to manually close the miner and reopen it to regain full speed.
"-minspeed" option provided me a solution and when the internet reconnected, the miner detects the lower speed and restarts by itself and regains full speed.
If Claymore needs it, i can provide a video clip with this issue or whatever info he needs.
Thanks for development efforts either way!
Hmmm... I will try to check if the speed drop is connected with the "internet connection lost" problem... Thanks for pointing this out!
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v10.1 (Windows/Linux)
Hi, Mr.Claymore
Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
Ok I will add an option in next update so you can set if "-minspeed" should work if miner cannot reach pools or not.
Thanks a lot! Do you have ETA for the next update?
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v10.1 (Windows/Linux)
Hi, Mr.Claymore
Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
I guess that there are people who need the opposite from what you describe (they need the -minspeed to get triggered from internet connection loss). I am not one of them but I am sure that there are cases where that makes sense.
I agree with you though on what you are saying. I would modify your request like this:
"Please add a flag that indicates whether internet connection loss will trigger -minspeed"
I think there is another uncovered case that bothers. There is a set of cool "failover" options in the miner. But all of them don't handle the trivial "internet connection lost" problem. O would prefer to run a "no_internet.bat" instead of stupid switching between mining pools. So, I understand your point, but I think it's really different. But lets Mr.Claymore to decide.
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v10.1 (Windows/Linux)
Hi, Mr.Claymore
Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
I use "-minspeed" because of AMD issue with Polaris cards. They published the driver that solves the issue, but sometimes the rig drops the speed to 60Mh instead of 160. And the only cure is to reboot. So, I'm on the fork. I need "-minspeed" to detect the real speed drop problem, but I have troubles with the "-minspeed" logic.
Please, calculate the speed for "-minspeed" only if the mining is really in progress (there is a connection to the pool).
Please, make the "-minspeed" option understand, that there is no internet connection, so it doesn't actually mine. So, the reason of hitting "-minspeed" limit is not a hardware issue. So, I don't want the miner restarts (reboot the PC) in this case. You understand, that it triggers all other signaling like e-mail/messages "I have to reboot", "I have been rebooted" and so on from every miner affected.
I use "-minspeed" because of AMD issue with Polaris cards. They published the driver that solves the issue, but sometimes the rig drops the speed to 60Mh instead of 160. And the only cure is to reboot. So, I'm on the fork. I need "-minspeed" to detect the real speed drop problem, but I have troubles with the "-minspeed" logic.
Please, calculate the speed for "-minspeed" only if the mining is really in progress (there is a connection to the pool).
[UPD]: The problem is solved! Write to @feeleep directly
Guys, is anybody in touch with the COINMINE.PL pool support or the owner? Why don't they answer to the support requests? Why is the last post of @feeleep dated July, 28?
https://bitcointalk.org/index.php?action=profile;u=110422;sa=showPosts
If the pool out of control, miners should know!
Guys, is anybody in touch with the COINMINE.PL pool support or the owner? Why don't they answer to the support requests? Why is the last post of @feeleep dated July, 28?
https://bitcointalk.org/index.php?action=profile;u=110422;sa=showPosts
If the pool out of control, miners should know!
Dear @feeleep!
If you still alive, please, let us know. The password reset procedure is not working for the DASH pool. It says "Unable to invalidate used token" when I come to set the new password.
Please, answer! Did anybody hear from this pool recently?
If you still alive, please, let us know. The password reset procedure is not working for the DASH pool. It says "Unable to invalidate used token" when I come to set the new password.
Please, answer! Did anybody hear from this pool recently?
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v9.8 (Windows/Linux)
Guys, what do you dual mine with 1060 and why? I used to mine DCR with -dcri 44, but is DCR the best choice? I see that ETH+SIA gives me 10% more USD now...
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v9.3 (Windows/Linux)
Sometime EthMan stops work properly - show all rigs offline and if i try close there are error message "Cannot terminate an externally created thread". Need kill and restart process via ProcessExplorer.
How many rigs in EthMan do you have?
Currently I'm rewriting some parts of EthMan, network routines too, probably it will help.
Confirm this bug from time to time. There were 25-50 nodes in the list.
I'm confused. It think I found a bug. And I also want to suggest a big improvement, Mr.Claymore.
My rig is a mixed 290/390/480
16:27:54:976 12e4 AMD Cards available: 6
16:27:54:976 12e4 GPU #0: Hawaii, 4096 MB available, 40 compute units
16:27:54:992 12e4 GPU #0 recognized as Radeon 290
16:27:54:992 12e4 GPU #1: Ellesmere, 8192 MB available, 36 compute units
16:27:54:992 12e4 GPU #1 recognized as Radeon RX 480
16:27:54:992 12e4 GPU #2: Ellesmere, 8192 MB available, 36 compute units
16:27:55:008 12e4 GPU #2 recognized as Radeon RX 480
16:27:55:008 12e4 GPU #3: Ellesmere, 8192 MB available, 36 compute units
16:27:55:008 12e4 GPU #3 recognized as Radeon RX 480
16:27:55:023 12e4 GPU #4: Hawaii, 8192 MB available, 40 compute units
16:27:55:023 12e4 GPU #4 recognized as Radeon 390
16:27:55:023 12e4 GPU #5: Hawaii, 8192 MB available, 40 compute units
16:27:55:023 12e4 GPU #5 recognized as Radeon 390
I use -di detect option and apply the output to the config.txt
-di 540231
and it works:
16:23:16:876 5f0 args: -di 540231 -gmap 540231 -tt 75 -ttli 82 -mport 3333 -retrydelay 5 -ftime 10
...
16:23:18:516 5f0 driver 10, 0, 2117, 13
16:23:18:516 5f0 AMD Cards available: 6
16:23:18:516 5f0 GPU #0: Hawaii, 8192 MB available, 40 compute units
16:23:18:532 5f0 GPU #0 recognized as Radeon 390
16:23:18:532 5f0 GPU #1: Hawaii, 8192 MB available, 40 compute units
16:23:18:532 5f0 GPU #1 recognized as Radeon 390
16:23:18:548 5f0 GPU #2: Hawaii, 4096 MB available, 40 compute units
16:23:18:548 5f0 GPU #2 recognized as Radeon 290
16:23:18:548 5f0 GPU #3: Ellesmere, 8192 MB available, 36 compute units
16:23:18:563 5f0 GPU #3 recognized as Radeon RX 480
16:23:18:563 5f0 GPU #4: Ellesmere, 8192 MB available, 36 compute units
16:23:18:563 5f0 GPU #4 recognized as Radeon RX 480
16:23:18:579 5f0 GPU #5: Ellesmere, 8192 MB available, 36 compute units
16:23:18:579 5f0 GPU #5 recognized as Radeon RX 480
Then I see this in the console log:
16:24:51:915 aa0 GPU #5: Ellesmere
16:24:51:915 aa0 ZEC - Total Speed: 1824.257 H/s, Total Shares: 79, Rejected: 0, Time: 00:01
16:24:51:930 aa0 ZEC: GPU0 395.950 H/s, GPU1 388.046 H/s, GPU2 323.483 H/s, GPU3 158.419 H/s, GPU4 281.087 H/s, GPU5 277.272 H/s
16:24:51:930 aa0 Pool switches: ZEC - 0
16:24:51:946 aa0 Current ZEC pool share target: 0x0020c49b (diff: 2000H)
16:24:51:946 aa0 Currently -ttli reduces intensity for: GPU3 (-80%)
16:24:52:008 aa0 GPU0 t=75C fan=91%, GPU1 t=80C fan=99%, GPU2 t=79C fan=100%, GPU3 t=86C fan=100%, GPU4 t=69C fan=47%, GPU5 t=79C fan=66%
I say: OMG, I turn off GPU3 until I understand what's happening. And press "3" button. What I see some time later?
16:25:25:183 aa0 ZEC - Total Speed: 1656.333 H/s, Total Shares: 104, Rejected: 0, Time: 00:01
16:25:25:199 aa0 ZEC: GPU0 390.400 H/s, GPU1 387.266 H/s, GPU2 322.875 H/s, GPU3 off, GPU4 280.499 H/s, GPU5 275.293 H/s
16:25:25:199 aa0 Pool switches: ZEC - 0
16:25:25:199 aa0 Current ZEC pool share target: 0x0020c49b (diff: 2000H)
16:25:25:214 aa0 Currently -ttli reduces intensity for: GPU3 (-80%)
16:25:25:277 aa0 GPU0 t=72C fan=91%, GPU1 t=79C fan=99%, GPU2 t=79C fan=100%, GPU3 t=87C fan=100%, GPU4 t=63C fan=22%, GPU5 t=76C fan=96%
Mmm? It looks like GPU3 is still working, but GPU4 is turned off instead. Isn't it a bit confusing, Mr.Claymore? OK, I say, may be it is related to -gmap option? Comment it by # And... Yes! After deactivating -gmap I see that the key pressed matches the GPU. If I press "3", then GPU3 stops mining, as I see on the temperature values. So, here is a bug, I suppose.
There are 3 lists of GPUs.
The first list is the GPU list to use in the config. It doesn't correspond with any other software. There is no way to reorder GPUs here. So, there is no way to make it corresponding to Atiflash, Whattool, MSI Afterburner, GPU-Z, HWinfo and other tools.
The second list is about the performance in the console log. By default it is the same as the first one. But you may reorder the GPUs here by using "-di" option.
The third list is about the temperature and it does correspond with Atiflash, Whattool, MSI Afterburner, GPU-Z, HWinfo and other tools. But if you want, you may reorder it with "-gmap" option.
They are completely independent!
I don't think that using OpenCL enumeration as the main one (with no alternative) is a good idea because it falls into conflict with most all of the other software. It confuses users. But OK, it's your choice, Mr.Claymore and the community has accepted it.
But let's explain it carefully in the docs. Let's say clearly, that there are two independent lists of GPU. That -di affects the performance list only, -gmap affects the temperature list only. And "0..9" keys in runtime matches ... which list?! And if I use "-di 210", then "0..9" keys in runtime matches ... which list?
And if I use
-tt 80,82,85 for GPU0, GPU1, GPU2 respectively, then these 0,1,2 means the ORIGINAL enumeration (from OpenCL), but not what I see in the console if I use also "-di 210"!
The things are going less complicated with "-altnum" option introduced in the latest Dual miner. With "2" value we will see exactly GPU numbers, that is great! But it's possible to solve most all the issues by implementing something like
-alo - adapter list order, that is applied to the OpenCL output first of all. All other indexes are applied to the list, already reordered by "alo" option.
Really! All I need is to order the adapters either the same way as the other software does or as these adapters physically placed. Both options are achievable with this new option.
Dear Mr.Claymore, please, stop all our troubles with those ... ATI programmers of OpenCL forever!
My rig is a mixed 290/390/480
16:27:54:976 12e4 AMD Cards available: 6
16:27:54:976 12e4 GPU #0: Hawaii, 4096 MB available, 40 compute units
16:27:54:992 12e4 GPU #0 recognized as Radeon 290
16:27:54:992 12e4 GPU #1: Ellesmere, 8192 MB available, 36 compute units
16:27:54:992 12e4 GPU #1 recognized as Radeon RX 480
16:27:54:992 12e4 GPU #2: Ellesmere, 8192 MB available, 36 compute units
16:27:55:008 12e4 GPU #2 recognized as Radeon RX 480
16:27:55:008 12e4 GPU #3: Ellesmere, 8192 MB available, 36 compute units
16:27:55:008 12e4 GPU #3 recognized as Radeon RX 480
16:27:55:023 12e4 GPU #4: Hawaii, 8192 MB available, 40 compute units
16:27:55:023 12e4 GPU #4 recognized as Radeon 390
16:27:55:023 12e4 GPU #5: Hawaii, 8192 MB available, 40 compute units
16:27:55:023 12e4 GPU #5 recognized as Radeon 390
I use -di detect option and apply the output to the config.txt
-di 540231
and it works:
16:23:16:876 5f0 args: -di 540231 -gmap 540231 -tt 75 -ttli 82 -mport 3333 -retrydelay 5 -ftime 10
...
16:23:18:516 5f0 driver 10, 0, 2117, 13
16:23:18:516 5f0 AMD Cards available: 6
16:23:18:516 5f0 GPU #0: Hawaii, 8192 MB available, 40 compute units
16:23:18:532 5f0 GPU #0 recognized as Radeon 390
16:23:18:532 5f0 GPU #1: Hawaii, 8192 MB available, 40 compute units
16:23:18:532 5f0 GPU #1 recognized as Radeon 390
16:23:18:548 5f0 GPU #2: Hawaii, 4096 MB available, 40 compute units
16:23:18:548 5f0 GPU #2 recognized as Radeon 290
16:23:18:548 5f0 GPU #3: Ellesmere, 8192 MB available, 36 compute units
16:23:18:563 5f0 GPU #3 recognized as Radeon RX 480
16:23:18:563 5f0 GPU #4: Ellesmere, 8192 MB available, 36 compute units
16:23:18:563 5f0 GPU #4 recognized as Radeon RX 480
16:23:18:579 5f0 GPU #5: Ellesmere, 8192 MB available, 36 compute units
16:23:18:579 5f0 GPU #5 recognized as Radeon RX 480
Then I see this in the console log:
16:24:51:915 aa0 GPU #5: Ellesmere
16:24:51:915 aa0 ZEC - Total Speed: 1824.257 H/s, Total Shares: 79, Rejected: 0, Time: 00:01
16:24:51:930 aa0 ZEC: GPU0 395.950 H/s, GPU1 388.046 H/s, GPU2 323.483 H/s, GPU3 158.419 H/s, GPU4 281.087 H/s, GPU5 277.272 H/s
16:24:51:930 aa0 Pool switches: ZEC - 0
16:24:51:946 aa0 Current ZEC pool share target: 0x0020c49b (diff: 2000H)
16:24:51:946 aa0 Currently -ttli reduces intensity for: GPU3 (-80%)
16:24:52:008 aa0 GPU0 t=75C fan=91%, GPU1 t=80C fan=99%, GPU2 t=79C fan=100%, GPU3 t=86C fan=100%, GPU4 t=69C fan=47%, GPU5 t=79C fan=66%
I say: OMG, I turn off GPU3 until I understand what's happening. And press "3" button. What I see some time later?
16:25:25:183 aa0 ZEC - Total Speed: 1656.333 H/s, Total Shares: 104, Rejected: 0, Time: 00:01
16:25:25:199 aa0 ZEC: GPU0 390.400 H/s, GPU1 387.266 H/s, GPU2 322.875 H/s, GPU3 off, GPU4 280.499 H/s, GPU5 275.293 H/s
16:25:25:199 aa0 Pool switches: ZEC - 0
16:25:25:199 aa0 Current ZEC pool share target: 0x0020c49b (diff: 2000H)
16:25:25:214 aa0 Currently -ttli reduces intensity for: GPU3 (-80%)
16:25:25:277 aa0 GPU0 t=72C fan=91%, GPU1 t=79C fan=99%, GPU2 t=79C fan=100%, GPU3 t=87C fan=100%, GPU4 t=63C fan=22%, GPU5 t=76C fan=96%
Mmm? It looks like GPU3 is still working, but GPU4 is turned off instead. Isn't it a bit confusing, Mr.Claymore? OK, I say, may be it is related to -gmap option? Comment it by # And... Yes! After deactivating -gmap I see that the key pressed matches the GPU. If I press "3", then GPU3 stops mining, as I see on the temperature values. So, here is a bug, I suppose.
There are 3 lists of GPUs.
The first list is the GPU list to use in the config. It doesn't correspond with any other software. There is no way to reorder GPUs here. So, there is no way to make it corresponding to Atiflash, Whattool, MSI Afterburner, GPU-Z, HWinfo and other tools.
The second list is about the performance in the console log. By default it is the same as the first one. But you may reorder the GPUs here by using "-di" option.
The third list is about the temperature and it does correspond with Atiflash, Whattool, MSI Afterburner, GPU-Z, HWinfo and other tools. But if you want, you may reorder it with "-gmap" option.
They are completely independent!
I don't think that using OpenCL enumeration as the main one (with no alternative) is a good idea because it falls into conflict with most all of the other software. It confuses users. But OK, it's your choice, Mr.Claymore and the community has accepted it.
But let's explain it carefully in the docs. Let's say clearly, that there are two independent lists of GPU. That -di affects the performance list only, -gmap affects the temperature list only. And "0..9" keys in runtime matches ... which list?! And if I use "-di 210", then "0..9" keys in runtime matches ... which list?
And if I use
-tt 80,82,85 for GPU0, GPU1, GPU2 respectively, then these 0,1,2 means the ORIGINAL enumeration (from OpenCL), but not what I see in the console if I use also "-di 210"!
The things are going less complicated with "-altnum" option introduced in the latest Dual miner. With "2" value we will see exactly GPU numbers, that is great! But it's possible to solve most all the issues by implementing something like
-alo - adapter list order, that is applied to the OpenCL output first of all. All other indexes are applied to the list, already reordered by "alo" option.
Really! All I need is to order the adapters either the same way as the other software does or as these adapters physically placed. Both options are achievable with this new option.
Dear Mr.Claymore, please, stop all our troubles with those ... ATI programmers of OpenCL forever!
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v9.0 (Windows/Linux)
@Claymore, what does it mean? Which GPU? There are 6 ones. Why? ( I expect GPU5 because of the temperature, but...
Every GPU has two threads.
I mean this:
Code:
18:01:21:376 13a8 WATCHDOG: GPU error, you need to restart miner :(
It does not say, which GPU is failed.
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v9.0 (Windows/Linux)
@Claymore, what does it mean? Which GPU? There are 6 ones. Why? ( I expect GPU5 because of the temperature, but...
v9.0
v9.0
Code:
18:01:13:672 d78 ETH: GPU0 28.221 Mh/s, GPU1 28.234 Mh/s, GPU2 28.234 Mh/s, GPU3 28.225 Mh/s, GPU4 27.614 Mh/s, GPU5 0.000 Mh/s
...
18:01:21:329 13a8 GPU0 t=74C fan=94%, GPU1 t=71C fan=66%, GPU2 t=73C fan=75%, GPU3 t=73C fan=96%, GPU4 t=72C fan=65%, GPU5 t=57C fan=20%
18:01:21:329 13a8 em hbt: 0, dm hbt: 0, fm hbt: 78,
18:01:21:329 13a8 watchdog - thread 0, hb time 141
18:01:21:329 13a8 watchdog - thread 1, hb time 63
18:01:21:329 13a8 watchdog - thread 2, hb time 141
18:01:21:344 13a8 watchdog - thread 3, hb time 63
18:01:21:344 13a8 watchdog - thread 4, hb time 0
18:01:21:344 13a8 watchdog - thread 5, hb time 78
18:01:21:344 13a8 watchdog - thread 6, hb time 94
18:01:21:360 13a8 watchdog - thread 7, hb time 31
18:01:21:360 13a8 watchdog - thread 8, hb time 63
18:01:21:360 13a8 watchdog - thread 9, hb time 0
18:01:21:360 13a8 watchdog - thread 10, hb time 16688
18:01:21:360 13a8 watchdog - thread 11, hb time 16672
18:01:21:376 13a8 WATCHDOG: GPU error, you need to restart miner :(
...
18:01:21:329 13a8 GPU0 t=74C fan=94%, GPU1 t=71C fan=66%, GPU2 t=73C fan=75%, GPU3 t=73C fan=96%, GPU4 t=72C fan=65%, GPU5 t=57C fan=20%
18:01:21:329 13a8 em hbt: 0, dm hbt: 0, fm hbt: 78,
18:01:21:329 13a8 watchdog - thread 0, hb time 141
18:01:21:329 13a8 watchdog - thread 1, hb time 63
18:01:21:329 13a8 watchdog - thread 2, hb time 141
18:01:21:344 13a8 watchdog - thread 3, hb time 63
18:01:21:344 13a8 watchdog - thread 4, hb time 0
18:01:21:344 13a8 watchdog - thread 5, hb time 78
18:01:21:344 13a8 watchdog - thread 6, hb time 94
18:01:21:360 13a8 watchdog - thread 7, hb time 31
18:01:21:360 13a8 watchdog - thread 8, hb time 63
18:01:21:360 13a8 watchdog - thread 9, hb time 0
18:01:21:360 13a8 watchdog - thread 10, hb time 16688
18:01:21:360 13a8 watchdog - thread 11, hb time 16672
18:01:21:376 13a8 WATCHDOG: GPU error, you need to restart miner :(
Again: if someone thinks that encrypted connection is a bad idea, do not use it, miner allows you to do it, I doubt you will ever notice 0.5% difference in your income. I'm not going to remove plain connection, restrict pools, increase fees, etc, there is not any conspiracy theory or evil plan. It seems some people have too rich fantasy.
In my opinion, ability to encrypt connection as an option is a good feature (and I'd like to support it a bit by reducing devfee), so I'm not going to remove it right now, though if I see that noone uses it I can remove it in future. Actually, I think about adding this feature to dual miner too, but now I'm not sure because here I've read a lot of ideas about bad sides of encryption, which looks really strange for me. Don't forget you mine cryptocurrencies, they all consist of pure encryption
In my opinion, ability to encrypt connection as an option is a good feature (and I'd like to support it a bit by reducing devfee), so I'm not going to remove it right now, though if I see that noone uses it I can remove it in future. Actually, I think about adding this feature to dual miner too, but now I'm not sure because here I've read a lot of ideas about bad sides of encryption, which looks really strange for me. Don't forget you mine cryptocurrencies, they all consist of pure encryption
Please, don't forget about some users are happy to have SSL connection. At least, they don't want by any reason that anyone between them and the pool could read the data transferred. They don't want anybody expect, that it is mining. They don't want anybody to steal their wallet number and so on. So, an ability to use SSL is generally good.
v9.1:
- additional range checks in code for better stability.
- reduced devfee, it's 2% now (72sec instead of 90sec) if you use secure SSL/TLS connection, currently Flypool and Suprnova pools support encrypted connections, see Readme for samples.
- improved "-di detect" option: now after GPU order detection miner starts mining with the detected order.
- added ability to use environment variables in "epools.txt" and "config.txt" files. For example, define "WORKER" environment varibale and use it as "%WORKER%" in config.txt.
- additional range checks in code for better stability.
- reduced devfee, it's 2% now (72sec instead of 90sec) if you use secure SSL/TLS connection, currently Flypool and Suprnova pools support encrypted connections, see Readme for samples.
- improved "-di detect" option: now after GPU order detection miner starts mining with the detected order.
- added ability to use environment variables in "epools.txt" and "config.txt" files. For example, define "WORKER" environment varibale and use it as "%WORKER%" in config.txt.
Great! Thanks!
Report:
470 4GB Power Color Red Devil get 210-215 sols on v9!
Good job clayyyyy
470 4GB Power Color Red Devil get 210-215 sols on v9!
Good job clayyyyy
Stock BIOS? Overclocked?
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v7.4 (Windows/Linux)
I used to be able to edit config.txt before.
in new version it says default is "read-only"
How to change back this behavior to change it to "read-write" so I can control my rigs on lan?
Thank you
in new version it says default is "read-only"
How to change back this behavior to change it to "read-write" so I can control my rigs on lan?
Thank you
Which "new version" do you mean? It is in ZEC miner, not here, isn't it?
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v7.4 (Windows/Linux)
UPD 2 Mr.Claymore I can repeat this bug now. It happens only with "big" config files and happens only when killing the EthMan.exe process in the Task manager. I also see that EthMan is trying to save the config file, even if it is killed abnormally. And I suppose it just has not enough time to finish the save operation and flush the disk cash.
Why do you kill EthMan from TaskMan? EthMan saves data at exit and it can cause this issue. EthMan cannot detect that you kill it abnormally, TaskMan sends normal WM_CLOSE message firstly, in Win7 it waits then, don't know about Win10.
Why? Because, as I said, I couldn't close it normally. It came to a state, when all miners were red colored as they were not available. And EthMan didn't respond to a "Close" command. It happens earlier or later, but it happens, if EthMan runs for a long time. Can I provide you with any additional helping info? Mmmm, may be... As I said before, I have two EthMan windows opened. Next time I see one of them hangs, I will check if this one gets config wrecked, not the second one, that runs normally.
P.S.But you have at least 2 options:
1) Wait 0.5sec before writing the config at exit
2) Perform a crash safe writing. So, write the temp file first, then make a copy of the current file as "*.old" and finally rename the temp file to a normal name.