Bitcoin Forum
May 27, 2019, 04:53:22 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 [1179] 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 ... 1311 »
  Print  
Author Topic: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v14.5 (Windows/Linux)  (Read 6326166 times)
knohult
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
May 01, 2018, 06:59:55 PM
 #23561


Interesting, why the timeout 15?
Note, the exe string needs to be single line, no c returns, or line breaks etc.
Also, 2 things you could try on the problem rig.
-mode 1
-dbg 1

I'd try stripping that to the minimum, (also make sure you set your virtual memory to at least 16GB!!!)

setx GPU_FORCE_64BIT_PTR 1
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
EthDcrMiner64.exe -epool eu1.nanopool.org:9999 -ewal wallet.rig/email -epsw x -mode 1


BUT.....I just checked, and it looks like nonopool servers are different to what you have above.

Should be

eth-eu1.nanopool.org

Are you 100% sure, the server you are using is correct?

Cheers

The timeout is just so msi afterburner will spin up the fans before the mining starts. I have the rig on wifi sometimes and it need some more seconds to reconnect to Smiley
It was in a single line, just automatic line break in notepad when i copied it. Same on both machines too. Virtual memory was 16gb but after a while it finally said that dag creation failed. I need 29 GB virtual memory to fill DAG on 6x gtx 1070 and 1x gtx 1060 card. I have put 32-40GB virtual memory now instead. The machine was reinstalled to with 10 pro instead of 10 pro n. Shouldn´t do anything i guess.
You are right, the server is wrong but eu1-nanopool.org actually works too Smiley
It seems that the problem was solved with virtual memory, i used 5x 1070 before and added two cards today.
1558932802
Hero Member
*
Offline Offline

Posts: 1558932802

View Profile Personal Message (Offline)

Ignore
1558932802
Reply with quote  #2

1558932802
Report to moderator
PLAY OVER 3000 GAMES
LIGHTNING FAST WITHDRAWALS
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558932802
Hero Member
*
Offline Offline

Posts: 1558932802

View Profile Personal Message (Offline)

Ignore
1558932802
Reply with quote  #2

1558932802
Report to moderator
GRABNGO57
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
May 01, 2018, 07:22:02 PM
 #23562

Hello, need some advice. Using V11.7 with AMD Blockchain drivers and getting 29.6 from my RX580 8Gb but when tried to use latest Adrenalin driver hash rate goes down to 19.9
This rig has 2 cards both RX 580s 8 Gb the one that gets to 32.2 has Hynix memory the one I have a problem with - Samsung.  Overclocking is the same with both drivers, I did not even touch it. Computing mode was turned on in new drivers. All patches installed in both cases.
Switched back to blockchain driver - the second card went back to 29.6 any advice what am I doing wrong?


OK, here's the deal with blockchain drivers.
Beta release, driver specific for mining, but now kind of dated, and only support 8 GPU max.
Later drivers, (general release), include a new feature to switch between graphics and compute in the Radeon Settings gui.
(Check out the Radeon  release notes!)

Radeon Settings / gaming /Global settings, (select each GPU in turn, LAME AMD, utterly LAME!), select compute, confirm OK for restart.
After setting all GPU to compute, shutdown PC, reboot etc.
(I've seen on every redeon release, failures to mode change, and reboot will fix that).

Suggest you use 18.3.4

Been running that for some weeks, it's stable so far, and supports up to 13 GPU per rig.

Good luck.


You are correct, first time I turned on computing only for the first card. thanks a lot. all works fine now.
kgminer
Jr. Member
*
Offline Offline

Activity: 100
Merit: 6


View Profile
May 01, 2018, 10:26:32 PM
 #23563

Hello,

How do I set script auto change mining server when server is down.

Example...

Now mining US sever then US sever is down,Try Asia Sever.......,Aisia server is down....Try Europe server.

Can I do that?

Thank you








Read this

FAILOVER

Use "epools.txt" and "dpools.txt" files to specify additional pools (you can use "-epoolsfile" and "-dpoolsfile" options to use different filenames).
These files have text format, one pool per line. Every pool has 3 connection attempts.
Miner disconnects automatically if pool does not send new jobs for a long time or if pool rejects too many shares.
If the first character of a line is ";" or "#", this line will be ignored.
Do not change spacing, spaces between parameters and values are required for parsing.
If you need to specify "," character in parameter value, use two commas - ,, will be treated as one comma.
You can reload "epools.txt" and "dpools.txt" files in runtime by pressing "r" key.
Pool specified in the command line is "main" pool, miner will try to return to it every 30 minutes if it has to use some different pool from the list.
If no pool was specified in the command line then first pool in the failover pools list is main pool.
You can change 30 minutes time period to some different value with "-ftime" option, or use "-ftime 0" to disable switching to main pool.
You can also use environment variables in "epools.txt", "dpools.txt" and "config.txt" files. For example, define "WORKER" environment variable and use it as "%WORKER%" in config.txt or in epools.txt.
You can also select current pool in runtime by pressing "e" or "d" key.
iSuX
Jr. Member
*
Offline Offline

Activity: 42
Merit: 8


View Profile
May 02, 2018, 07:44:44 AM
 #23564


Interesting, why the timeout 15?
Note, the exe string needs to be single line, no c returns, or line breaks etc.
Also, 2 things you could try on the problem rig.
-mode 1
-dbg 1

I'd try stripping that to the minimum, (also make sure you set your virtual memory to at least 16GB!!!)

setx GPU_FORCE_64BIT_PTR 1
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
EthDcrMiner64.exe -epool eu1.nanopool.org:9999 -ewal wallet.rig/email -epsw x -mode 1


BUT.....I just checked, and it looks like nonopool servers are different to what you have above.

Should be

eth-eu1.nanopool.org

Are you 100% sure, the server you are using is correct?

Cheers

The timeout is just so msi afterburner will spin up the fans before the mining starts. I have the rig on wifi sometimes and it need some more seconds to reconnect to Smiley
It was in a single line, just automatic line break in notepad when i copied it. Same on both machines too. Virtual memory was 16gb but after a while it finally said that dag creation failed. I need 29 GB virtual memory to fill DAG on 6x gtx 1070 and 1x gtx 1060 card. I have put 32-40GB virtual memory now instead. The machine was reinstalled to with 10 pro instead of 10 pro n. Shouldn´t do anything i guess.
You are right, the server is wrong but eu1-nanopool.org actually works too Smiley
It seems that the problem was solved with virtual memory, i used 5x 1070 before and added two cards today.

Nice going, and thanks for taking the time to feedback results.
I was wondering about that nanopool address, it's possible they used eu1.nanopool.org:9999 previously, but have changed the servers/names and have various aliases. The problem with that can be, the routers in between, DNS cache and arp tables will have duplicates. This stuff is self healing, but can actually take days to settle down, and in the mean time, things, (like name resolution, routing etc) can take longer than expected, (expected as in, longer than the time out limits your end, or along the path etc), and as you're essentially on the far end of a long chain, all those "little" delays can add up, and the application will appear to hang your end, while in reality, it's just waiting.

Hopefully, setting the log to debug, you will see a bunch of additional entries, like "waiting... etc etc" if you don't see anything logging, then probably claymore is hung. (Don't forget, if you're using notepad to view the live log, you need to refresh/reopen it, to see new entries.
Hitting f5 in explorer, should show you the log file size increasing, is another method to determine if anything is logging.

(don't forget to disable debug log when you're stable)

Virtual memory. It's far from clear what claymore is doing with that, and although 16GB is the minimum, I'd suggest it's never a good plan to aim for the bottom!!
It's only VM anyway, set it as high as you like, (although to be safe, less than free space on disc, plus some headroom).
Suppose you have 100GB free, setting VM to 60GB should be pretty safe, assuming your rig is dedicated for only mining.

Ok, afterburner.
Less than ideal to use that imho, any application can crash, what damage can happen if afterburner crashes? I'd rather not find that out the hard way.

Did you spot in 11.7, Nvidia temperature control is now supported?
 added temperature management and overclock support for recent Nvidia cards in Windows: "-tt", "-powlim", "-cclock", "-mclock", "-tt", "-fanmax", "-fanmin" options are supported for Nvidia too.

I'd suggest using it. That way, if claymore crashes, (no more work is pushed to GPUs), and at least your GPUs revert to bios control, cool down etc.
Right now, if your afterburner crashes, and claymore carries on, you're going to potentially cook those cards, or force them to their hardware trip point, (probably something scary like 100C plus).

NOT GOOD.

Remember, mining is a bit extreme for GPUs.
Like anything engineered, they are designed for a purpose, and have a duty cycle to match.
It's not expected under typical use, that GPUs are running, flat out, 24/7, this means they will probably have a shorter lifespan than if they were used for gaming.

Render farms, (not so dissimilar from mining), are constantly swapping out/in cards, and usually have failovers and backup nodes to pick up the slack.

So the key here is stability, steady temperature control, depending on the fan type, probably constant rotation, speed regulation, rather than on/off/on is going to be preferable. Think of it like trying to avoid the extremes, and flatten out the peaks and troughs.

Mechanically, we have to consider these GPUs are getting hot! Parts are MUCH hotter than 100C, very reliant on cooling, and different materials expand/contract at different rates. Copper is one of the more extreme examples, but any such mechanical expansion is also going to reduce life, contribute to increase failure. It's the CHANGE, (expansion), that causes mechanical stress. Avoiding that as much as possible, will extend life.

If you're in this for the long run, ROI etc, then it's a good idea to consider these angles, and imho, get cards with a well engineered cooling scheme, active and passive, reduce voltages/current etc, set the upper cut limits lower, (e.g 98C to 88C), set a reasonably LOW target temp, (60C), if it means you work the fans harder, so be it, those are cheap to replace compared to a GPU.

(Find some stable settings, and customise your BIOS to reflect that). That way, if all else fails, the hardware will self protect.

Last advice, wifi.
I was amazed at how many instabilities evaporated when I switched that off.
Part of the problem is, these days, wifi routers are doing all kinds of (for open rigs, nasty stuff), like beam forming, and essentially flooding the space with microwaves, as are of course all the devices trying to connect, like phones etc.
In your typical PC, it's in a metal box, microwaves don't travel well through flat/sheet metal, and wifi antennas are OUTSIDE the PC case, (even in laptops, antennas are as far away from the motherboard  as possible.

Now we have open mining rigs, no casing, (shielding) and worse still, we have a LOAD of wire stands running all over the place. Cables from PCIe cards to risers, (should be shielded, but who knows), but also we have a lot of single strands, power lines to the GPUs, and normally ALL this stuff is further shielded inside a metal computer case. Furthermore, all components in there will share a common shield ground.

While microwaves, (and any "radio" band waves for that matter), well those LOVE single strands of wire, those being brilliant antennas, being it receiving or transmitting.

So, what all this adds up to is TROUBLE, when exposing open rig, no common ground, worse still, multiple floating grounds, multiple power supplies lots and lots of microwave sucking antennas.

As recently as 2 weeks ago, (after months of mining), I finally got around to hard-wiring LAN to all my rigs.
This comes after months of chasing down gremlins, timeouts, dropped sockets at pool, (while still having local internet access), random lockups, crashes, you name it, it's a long list, and a LOT of time.

I'd say, I'd fought hard to tune out 50~60% of events, reduced frequency for sure, but once every 7~10 days, I'd have a succession of dropped connections, resulting in stale shares down the line.

Since eliminating wifi, (and 1 rig on powerline LAN), I'm amazed at the difference, (and kicking myself, as I know better), I guess it had become a bit of a campaign, which with hindsight, was a lost cause :-)

What one needs to consider is, steady, steady, steady is the key to mining.
Eliminate as many of the potential risks to that, and you're set up to go steady :-)

Good  luck.
 





KISS. Did you read the Readme.txt?
Summarise/Itemise your hardware/versions/expectations/batchfile & results. The more specific, detailed, the better
iSuX
Jr. Member
*
Offline Offline

Activity: 42
Merit: 8


View Profile
May 02, 2018, 08:14:39 AM
 #23565

Hello, need some advice. Using V11.7 with AMD Blockchain drivers and getting 29.6 from my RX580 8Gb but when tried to use latest Adrenalin driver hash rate goes down to 19.9
This rig has 2 cards both RX 580s 8 Gb the one that gets to 32.2 has Hynix memory the one I have a problem with - Samsung.  Overclocking is the same with both drivers, I did not even touch it. Computing mode was turned on in new drivers. All patches installed in both cases.
Switched back to blockchain driver - the second card went back to 29.6 any advice what am I doing wrong?


OK, here's the deal with blockchain drivers.
Beta release, driver specific for mining, but now kind of dated, and only support 8 GPU max.
Later drivers, (general release), include a new feature to switch between graphics and compute in the Radeon Settings gui.
(Check out the Radeon  release notes!)

Radeon Settings / gaming /Global settings, (select each GPU in turn, LAME AMD, utterly LAME!), select compute, confirm OK for restart.
After setting all GPU to compute, shutdown PC, reboot etc.
(I've seen on every redeon release, failures to mode change, and reboot will fix that).

Suggest you use 18.3.4

Been running that for some weeks, it's stable so far, and supports up to 13 GPU per rig.

Good luck.


You are correct, first time I turned on computing only for the first card. thanks a lot. all works fine now.

Nice going, thanks for posting a followup.
Happy mining.

BTW: I have also see Radeon settings revert some GPU to graphics after a hard crash.
It's a good plan to map your rig, (physically identify each GPU, and it's logical number in claymore), note what hash rate you expect from each gpu.
Monitoring in Eth manager is a good way to spot check if each GPU is performing.

One of the nastier things about the AMD drivers, is the hit your hash rate takes, if it reverts to graphics, (usually more than 30%), and if that wasn't enough, while you burn the same power!

If you swap a card to another slot, it will get a new pci bus address, (and this means, radeon setting will be back to graphics), but claymore is only counting from 0.

Suppose you have 3 GPU. (GPU numbers below, as per claymore)

GPU0 is on pci node2
GPU1 is on pci node6
GPU2 is on pci node7

You set all 3 to compute in radeon settings, and away you go.

Later, for whatever reason, (new card, bios change, swap out riser, cable etc), you move GPU2

GPU2 is now moved to pci node1, in claymore you will still see 3x GPU, but the addressing will be.

GPU0 is on pci node1
GPU1 is on pci node2
GPU2 is on pci node6

You only changed/moved one GPU, but this reorders the addressing, and while this won't impact claymore, (other than to confuse you perhaps), Radeon settings are ONLY using addressing on the pci bus, so for sure you will have to set compute mode for GPU0, (it will be graphics by default, as radeon detects it as a new gpu found, as it's on a newly used bus address).

This gets SUPER painful as you expand your rig.

I've been toying with the idea on my next build to, only add 1 single GPU, let radeon detect it, I can set to compute, shutdown, and move that single gpu to the next slot. Repeat, move, repeat.
That way, assuming the GPU make/model is the same, all bus nodes will have a "remembered" gpu/bus address, which is set to compute.

BUT all this takes a LOT of time, and with radeon settings as they are, this time increases exponentially with each GPU added.

What is SO LAME, is AMD do not, have not, added a SIMPLE install switch, to clean install drivers in compute mode, (graphics disabled), Hell, even Mr Claymore has managed that, what's AMDs excuse?
 
What bugs me, is how often this lame method to set compute mode is actually needed.

I really hope AMD make some improvements here, and my suggestion would be a installer switch

setup.exe /compute

Which tells the installer to install in only compute mode, rendering radeon settings, and graphics to compute mode redundant, and save LOADS of time and hassle for their customers.

I should add, that all the rendering farm customers would certainly appreciate that as well.

Good luck

KISS. Did you read the Readme.txt?
Summarise/Itemise your hardware/versions/expectations/batchfile & results. The more specific, detailed, the better
antanaskkk
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
May 02, 2018, 08:26:23 AM
 #23566

@claymore
can you maybe fix miner for gpu temp monitor
when i use MS remote desktop, and run miner .. only 1 gpu show temp
when i run minier via teamviver, show all gpu temp and fan %, or i run local .. via keyboard and monitor

but, teamviver is not free, and from time to time block conncection and you must wait for another.
And MS remote desktop is builed in, free and working great

It is not related to the miner, the reason is in Windows and AMD drivers.

Phoenix miner fixed this issue, so even it is Windows/driver problems it is possible to fix it.
wharmus
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile
May 02, 2018, 08:29:24 AM
 #23567

does anyone still dual mine? or is it dead?
jackbox
Legendary
*
Offline Offline

Activity: 1106
Merit: 1024



View Profile
May 02, 2018, 08:39:26 AM
 #23568

does anyone still dual mine? or is it dead?

In my past experience was not worth it. More power used. More heat generated. Small extra profit. Shortens life of the video cards.

Buy a Trezor and Protect your BTC, BCH, BTG, DASH, LTC, DGB, ZEC, ETH and ETC from hackers.
If I was helpful please buy me a coffee BTC: 1DWK7vBaxcTC5Wd2nQwLGEoy8xdFVzGKLK  BTG: AWvN1iBqCUqG2tEh3XoVvRbdcGrAzfBBpW
If I was helpful please buy me a burger XVG: DGYWTLtcGh4mvoG6B2yifakeP2W24P4cco  DGB: DLASV6CUQpGtGSyaVz5FYuu5YxZ17MoGQz
antanaskkk
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
May 02, 2018, 08:54:01 AM
 #23569

does anyone still dual mine? or is it dead?

In my past experience was not worth it. More power used. More heat generated. Small extra profit. Shortens life of the video cards.

No, no one mines anymore Sad
wharmus
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile
May 02, 2018, 10:16:13 AM
 #23570

that's bad news. i figured now that you can get 50 mh for 1080ti , would be nice to add a secondary coin.
i tried with maxcoin but i get $1.5 / 10x1080ti , not very good i would say.
also i ve done some calculations and mining eth is more proffitable than zec or equihash atm.
ganzocrypt
Newbie
*
Offline Offline

Activity: 145
Merit: 0


View Profile
May 02, 2018, 10:38:25 AM
 #23571

time to add new algo to dual mine other coins.
iSuX
Jr. Member
*
Offline Offline

Activity: 42
Merit: 8


View Profile
May 02, 2018, 11:27:39 AM
 #23572

does anyone still dual mine? or is it dead?

In my past experience was not worth it. More power used. More heat generated. Small extra profit. Shortens life of the video cards.


For what's it worth, I totally agree.

It might have been profitable to dual mine in the past, and possibly still so if you happen to have free power, but I calculated I used about 35% more power.
Worse still, stability dropped, and you pull more power out of your PSUs, which probably pushes them away from optimum efficiency.

Furthermore, solo ETH, I can run 6x RX580 off a single 1000W PSU, and have it sitting at 91% efficiency, (down from 93%). (Costs me 2% loss over time, verses cost of another PSU. Long term, that 2% is going to add up, and 2% would surpass cost of another PSU, so it matters).

Dual mining, I could only run 4x RX580 stable. (I could start claymore with gser 2, with 5x RX580, but had a LOT of interruptions, crashes, freezes etc).

Conclusion: Factoring in 35% additional power consumption costs, plus a 33% increase in the number of PSUs I needed, (plus their losses, (7%) plus further drop in efficiency), it's very hard to see where you'd expect the payback to offset these added costs.

Then, as Jackbox astutely pointed out, you have to factor in the added stress, and reduction in MTBF.

Assuming you're located at higher/lower latitudes, through the winter, assuming you can swap out air, you save costs on cooling. Come summer, you're paying more for cooling. Dual mining was astounding how much hotter the GPUs ran, (last winter), come summer, your fans are working harder to cool.

More costs.

Cool and steady = stable = consistent revenue.

The added down time I hit dual mining, (a considerable loss in itself), was the knife in the back afaic  

It was worth the experimentation, conclusion was clear.
Far more good reasons NOT TO dual mine, and no good reasons for it.
At least in my experience.

Footnote: I made NO extra profit dual mining, even if I ignore the cost instability cost my ETH mining, comparing ONLY the additional power cost, I was loosing 3:1.
(Extra power cost $4, I earned about $1.2 from the other coin).

Revenue is not profit.


KISS. Did you read the Readme.txt?
Summarise/Itemise your hardware/versions/expectations/batchfile & results. The more specific, detailed, the better
iSuX
Jr. Member
*
Offline Offline

Activity: 42
Merit: 8


View Profile
May 02, 2018, 12:03:05 PM
 #23573

Ethermine performance with Claymore.

Hello fellow miners.
I'm currently running some 10 day comparative testing, two identical rigs, identical hardware, same number of GPUs etc, (more on that later), but as it happened yesterday another GPU arrived, and it happened to bring the overall gpu count to an odd number.

So as I didn't want to upset the comparative test by having 1 more GPU running on one rig than the other, I decided to start a second instance of claymore, (using only this single GPU), and so as not to mess up the graphs at ethermine, I targeting this single GPU at ETC.

What is interesting is, after 24 hours, and allowing for the 6h average to normalise, this single instance, one GPU, is averaging above my local hash rate, while ETH is consistently lower.


Now, by no means can any conclusions be drawn at this stage, but it got me wondering....

So, for the next test, I'm going to configure 8 claymore instances, single GPU each, and go head to head with the other rig, running one claymore instance with 8 gpu.

I'm wondering if/how/what ethermine is doing differently, that single gpu instance is local hashing at 32.15, rock solid, but the @pool average in the last 12 hours, 35.25~33.6MH/s. (plus 7%!)

While the other rig, is running at -4%

Have any of you guys experienced something like this, or can point me to previous comparison tests?

Cheers



KISS. Did you read the Readme.txt?
Summarise/Itemise your hardware/versions/expectations/batchfile & results. The more specific, detailed, the better
mattyforcrypto
Jr. Member
*
Offline Offline

Activity: 164
Merit: 2


View Profile WWW
May 02, 2018, 01:01:56 PM
 #23574

Miner has been running for almost 40hours without problems now.

But there is a terrible thing happening now, my hashrates are horrible..
Before I would get around 38+MH/s but in those last 40 hours my 6hour average hasn't been above 36MH according to the pool while Claymore keeps reporting ~38.3MH like usual, my 30minute average will also often times go below 30 and take a long time to even reach 35+ again.

Should I try switching back to an older version or is there another way to fix this? Losing almost 10% of my hashrate is quite huge.
I don't know about other miners, didn't try them yet, but will probably do it today.
wharmus
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile
May 02, 2018, 01:56:47 PM
 #23575

does anyone still dual mine? or is it dead?

In my past experience was not worth it. More power used. More heat generated. Small extra profit. Shortens life of the video cards.


For what's it worth, I totally agree.

It might have been profitable to dual mine in the past, and possibly still so if you happen to have free power, but I calculated I used about 35% more power.
Worse still, stability dropped, and you pull more power out of your PSUs, which probably pushes them away from optimum efficiency.

Furthermore, solo ETH, I can run 6x RX580 off a single 1000W PSU, and have it sitting at 91% efficiency, (down from 93%). (Costs me 2% loss over time, verses cost of another PSU. Long term, that 2% is going to add up, and 2% would surpass cost of another PSU, so it matters).

Dual mining, I could only run 4x RX580 stable. (I could start claymore with gser 2, with 5x RX580, but had a LOT of interruptions, crashes, freezes etc).

Conclusion: Factoring in 35% additional power consumption costs, plus a 33% increase in the number of PSUs I needed, (plus their losses, (7%) plus further drop in efficiency), it's very hard to see where you'd expect the payback to offset these added costs.

Then, as Jackbox astutely pointed out, you have to factor in the added stress, and reduction in MTBF.

Assuming you're located at higher/lower latitudes, through the winter, assuming you can swap out air, you save costs on cooling. Come summer, you're paying more for cooling. Dual mining was astounding how much hotter the GPUs ran, (last winter), come summer, your fans are working harder to cool.

More costs.

Cool and steady = stable = consistent revenue.

The added down time I hit dual mining, (a considerable loss in itself), was the knife in the back afaic  

It was worth the experimentation, conclusion was clear.
Far more good reasons NOT TO dual mine, and no good reasons for it.
At least in my experience.

Footnote: I made NO extra profit dual mining, even if I ignore the cost instability cost my ETH mining, comparing ONLY the additional power cost, I was loosing 3:1.
(Extra power cost $4, I earned about $1.2 from the other coin).

Revenue is not profit.



Well for the maxcoin if you add it as second coin with 1080ti , you can make extra $1.5 per 10 cards , without any power increase.
At least thats my case.
leonix007
Sr. Member
****
Offline Offline

Activity: 826
Merit: 282


Grow with community


View Profile
May 02, 2018, 02:36:29 PM
 #23576

setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
EthDcrMiner64.exe -epool us-east.ethash-hub.miningpoolhub.com:20535 -ewal walladdress.backroom -esm 2 -epsw x -dwal -dpsw x -nofee 1 -mode 1


Trying this pool as I'm getting a decent ping from it.  Would not work with the SSL option before the address.  Took that out and am getting:


ETH: Authorization failed
: {"id":2,"result":false,"error":null}
ETH: Connection lost, retry in 20 sec...

Try this

EthDcrMiner64.exe -epool us-east.ethash-hub.miningpoolhub.com:20535 -ewal username.workername -eworker username.workername -esm 2 -epsw x

you must create an account on miningpoolhub in order to use their pool and have the username and worker name to be configured

https://ethereum.miningpoolhub.com/
babbage.charl
Newbie
*
Offline Offline

Activity: 80
Merit: 0


View Profile
May 02, 2018, 03:50:51 PM
 #23577

On miningpoolhub today I have no connection on eth. Yesterday everything was literally good. Does anyone have the same problems?
Dark Oopa
Newbie
*
Offline Offline

Activity: 66
Merit: 0


View Profile
May 02, 2018, 04:19:13 PM
Last edit: May 02, 2018, 05:47:33 PM by Dark Oopa
 #23578

Ethermine performance with Claymore.

Hello fellow miners.
I'm currently running some 10 day comparative testing, two identical rigs, identical hardware, same number of GPUs etc, (more on that later), but as it happened yesterday another GPU arrived, and it happened to bring the overall gpu count to an odd number.

So as I didn't want to upset the comparative test by having 1 more GPU running on one rig than the other, I decided to start a second instance of claymore, (using only this single GPU), and so as not to mess up the graphs at ethermine, I targeting this single GPU at ETC.

What is interesting is, after 24 hours, and allowing for the 6h average to normalise, this single instance, one GPU, is averaging above my local hash rate, while ETH is consistently lower.


Now, by no means can any conclusions be drawn at this stage, but it got me wondering....

So, for the next test, I'm going to configure 8 claymore instances, single GPU each, and go head to head with the other rig, running one claymore instance with 8 gpu.

I'm wondering if/how/what ethermine is doing differently, that single gpu instance is local hashing at 32.15, rock solid, but the @pool average in the last 12 hours, 35.25~33.6MH/s. (plus 7%!)

While the other rig, is running at -4%

Have any of you guys experienced something like this, or can point me to previous comparison tests?

Cheers




well, I already had my farm with more hashrate on 24 hours than supposed to. Wait another 24/48 hours to be sure it is not just randomness.

What are ou testing? pool or miner?
janding
Newbie
*
Offline Offline

Activity: 137
Merit: 0


View Profile
May 02, 2018, 05:56:01 PM
 #23579

does anyone still dual mine? or is it dead?

In my past experience was not worth it. More power used. More heat generated. Small extra profit. Shortens life of the video cards.


God how I hate people who BEG for donations.
Get a job.
iSuX
Jr. Member
*
Offline Offline

Activity: 42
Merit: 8


View Profile
May 02, 2018, 06:26:06 PM
 #23580

Ethermine performance with Claymore.

Hello fellow miners.
I'm currently running some 10 day comparative testing, two identical rigs, identical hardware, same number of GPUs etc, (more on that later), but as it happened yesterday another GPU arrived, and it happened to bring the overall gpu count to an odd number.

So as I didn't want to upset the comparative test by having 1 more GPU running on one rig than the other, I decided to start a second instance of claymore, (using only this single GPU), and so as not to mess up the graphs at ethermine, I targeting this single GPU at ETC.

What is interesting is, after 24 hours, and allowing for the 6h average to normalise, this single instance, one GPU, is averaging above my local hash rate, while ETH is consistently lower.


Now, by no means can any conclusions be drawn at this stage, but it got me wondering....

So, for the next test, I'm going to configure 8 claymore instances, single GPU each, and go head to head with the other rig, running one claymore instance with 8 gpu.

I'm wondering if/how/what ethermine is doing differently, that single gpu instance is local hashing at 32.15, rock solid, but the @pool average in the last 12 hours, 35.25~33.6MH/s. (plus 7%!)

While the other rig, is running at -4%

Have any of you guys experienced something like this, or can point me to previous comparison tests?

Cheers




well, I already had my farm with more hashrate on 24 hours than supposed to. Wait another 24/48 hours to be sure it is not just randomness.

What are ou testing? pool or miner?

Yeah, I spotted that also. Actually I was testing against 2 different pools, that test will wrap next Monday evening, (7 days).
This whole ETC thing just happened to popup in the last 24hrs, and right now, I don't have any spare rigs to run a proper comparative test, (but I am starting to sketch out that test).

Clearly pools have a bunch of algorithms to divide up the work, load balance, and match reported hashing power to jobs, I wonder how well that scales.
Obviously not all pools do that the same way, and in fact, doing that well SHOULD be a selling point for them, secret as it may be.

I'm assuming ethermine use more or less the same mechanism on their ETH and ETC pools, (another test :-)

But I'm going to try a 1:1 and 8:1 side by side next week on the ETC pool.
Will share the findings for discussion.


Side note: ETC has indeed dropped 6hr average below local hash rate, 14:30-ish UTC.
Happy mining everyone.

KISS. Did you read the Readme.txt?
Summarise/Itemise your hardware/versions/expectations/batchfile & results. The more specific, detailed, the better
Pages: « 1 ... 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 [1179] 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 ... 1311 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!