6 x GTX1070
https://imgur.com/a/fvL9c
Topic: [ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows) - page 132. (Read 224961 times)
October 25, 2017, 04:46:17 PM
I start test your miner 24 hours, so we will see, first impression good
6 x GTX1070
https://imgur.com/a/fvL9c
6 x GTX1070
https://imgur.com/a/fvL9c
October 25, 2017, 03:38:09 PM
What proxies do you guys use (if any)? Not really fan of connection per card architecture, forgive me dstm.
That's the purpose of this thread, if there is anything that needs improvement or is more usable for you this is the right place to ask.
I’m not quite familiar with the technicalities of mining algorithms, but what is advantage/disadvantage of connection per card architecture vs otherwise? Could this be the reason for increased cpu usage?
Let me try to educate
Say you have 20 rigs with 5 cards each. 100 cards. With ewbf or other miners, it would use 20 connections since there is one per rig. Now, with dstm miner 100 cards = 100 connections. Only 5 times more, right? Now imagine 10 guys with 100 cards = 1000 cards = 1000 connections to pool server. Pool servers could detect this as attack and start dropping or throttling connections... Also, there is only 64k ports and server can take around 60k connections per second (in theory).Thats why I am not fan of this approach (not meaning to be mean or discourage dstm, again sorry man), because it stresses network more, and pool servers too. That is one of the reason some big miners use proxy, to decrease network infrastructure and pool server load.
Someone correct me if this is BS, but with years in sysadmin and networking, it should be legit
The argument about ports is valid, it might be an issues for people with several 10000GPUs on nat-networks. However I guess they would use a proxy anyway.
It doesn't put more stress on the network, since there is roughly the same amount of data (depending on how the pool adjusts difficulty) going through the network, zm's bandwidth requirements are very low. It also doesn't put more stress on nat-routers, since they have to rewrite the same amount of data.
Pool side: right it puts more stress on pools since they have to manage more clients.
In general, if there are good arguments for an improvement/change, I'll think about them ofc, so this kind of discussions are welcome.
October 25, 2017, 03:24:00 PM
Tried it on my gaming box today - single 1080ti.
725ish sol/s vs EWBF at 760ish with the same settings.
Might try it on one of my boxes with 1070 and 1080 cards later today, but so far I'm not seeing any reason to switch.
I do prefer the "don't use dark colors on a black background" aspect of the interface - I HATE the default color choices Claymore and EWBF use on their miner programs that make them hard to read on a lot of my monitors.
725ish sol/s vs EWBF at 760ish with the same settings.
Might try it on one of my boxes with 1070 and 1080 cards later today, but so far I'm not seeing any reason to switch.
I do prefer the "don't use dark colors on a black background" aspect of the interface - I HATE the default color choices Claymore and EWBF use on their miner programs that make them hard to read on a lot of my monitors.
October 25, 2017, 03:17:11 PM
In last version the NAT changes are not really works.
i got all few minutes lost connections in and endless loop.
i got all few minutes lost connections in and endless loop.
Quote
my regulary NAT timeout ist 360 or 600 seconds - that is enough for
a router.
Can you please check your keepalive (tcp based!) coding,
and verify that the miner is working with general settings on natted router ?
a router.
Can you please check your keepalive (tcp based!) coding,
and verify that the miner is working with general settings on natted router ?
Most people are using zm on a natted network I guess, so there should be no general issue.
TCP keepalive is set to 50s in zm so a timeout of 360s isn't an issue.
What OS are you on?
What pool are you using?
October 25, 2017, 03:07:50 PM
Hi dstm,
first of all, nice miner. It works quite good but I have some troubles with my setup.
It seems like the CPU is bottlenecking the miner.
I've just upgraded from 6 1080 ti to 6 1080 ti + 3 1070 single board setup, so a total of 9 cards on one board.
With 6 I've noticed a 2-5% + over EWBF.
With 9 cards on the other hand, the sols drop way behind EWBF ( -900-1000 sols ).
I've noticed, that my little Intel Celeron G3900 is always maxed out, so I'm sure that this is the cause of this issue.
Is there an improvement planned?
first of all, nice miner. It works quite good but I have some troubles with my setup.
It seems like the CPU is bottlenecking the miner.
I've just upgraded from 6 1080 ti to 6 1080 ti + 3 1070 single board setup, so a total of 9 cards on one board.
With 6 I've noticed a 2-5% + over EWBF.
With 9 cards on the other hand, the sols drop way behind EWBF ( -900-1000 sols ).
I've noticed, that my little Intel Celeron G3900 is always maxed out, so I'm sure that this is the cause of this issue.
Is there an improvement planned?
Right, you're cpu bound.
I've reduced the cpu load slightly (about 8-10 %), it's under testing currently.
October 25, 2017, 03:05:18 PM
Works fine, few % increase in hashing power
October 25, 2017, 02:40:34 PM
October 25, 2017, 02:30:23 PM
What proxies do you guys use (if any)? Not really fan of connection per card architecture, forgive me dstm.
That's the purpose of this thread, if there is anything that needs improvement or is more usable for you this is the right place to ask.
I’m not quite familiar with the technicalities of mining algorithms, but what is advantage/disadvantage of connection per card architecture vs otherwise? Could this be the reason for increased cpu usage?
Let me try to educate
Say you have 20 rigs with 5 cards each. 100 cards. With ewbf or other miners, it would use 20 connections since there is one per rig. Now, with dstm miner 100 cards = 100 connections. Only 5 times more, right? Now imagine 10 guys with 100 cards = 1000 cards = 1000 connections to pool server. Pool servers could detect this as attack and start dropping or throttling connections... Also, there is only 64k ports and server can take around 60k connections per second (in theory).Thats why I am not fan of this approach (not meaning to be mean or discourage dstm, again sorry man), because it stresses network more, and pool servers too. That is one of the reason some big miners use proxy, to decrease network infrastructure and pool server load.
Someone correct me if this is BS, but with years in sysadmin and networking, it should be legit
October 25, 2017, 02:25:45 PM
In last version the NAT changes are not really works.
i got all few minutes lost connections in and endless loop.
my regulary NAT timeout ist 360 or 600 seconds - that is enough for
a router.
Can you please check your keepalive (tcp based!) coding,
and verify that the miner is working with general settings on natted router ?
i got all few minutes lost connections in and endless loop.
my regulary NAT timeout ist 360 or 600 seconds - that is enough for
a router.
Can you please check your keepalive (tcp based!) coding,
and verify that the miner is working with general settings on natted router ?
October 25, 2017, 02:17:21 PM
Just wanted to let you know that dstm will work from now on on Miningspeed ;-)
Issue is fixed, had to do with a miner i blocked..
Issue is fixed, had to do with a miner i blocked..
October 25, 2017, 12:37:57 PM
Hi dstm,
first of all, nice miner. It works quite good but I have some troubles with my setup.
It seems like the CPU is bottlenecking the miner.
I've just upgraded from 6 1080 ti to 6 1080 ti + 3 1070 single board setup, so a total of 9 cards on one board.
With 6 I've noticed a 2-5% + over EWBF.
With 9 cards on the other hand, the sols drop way behind EWBF ( -900-1000 sols ).
I've noticed, that my little Intel Celeron G3900 is always maxed out, so I'm sure that this is the cause of this issue.
Is there an improvement planned?
first of all, nice miner. It works quite good but I have some troubles with my setup.
It seems like the CPU is bottlenecking the miner.
I've just upgraded from 6 1080 ti to 6 1080 ti + 3 1070 single board setup, so a total of 9 cards on one board.
With 6 I've noticed a 2-5% + over EWBF.
With 9 cards on the other hand, the sols drop way behind EWBF ( -900-1000 sols ).
I've noticed, that my little Intel Celeron G3900 is always maxed out, so I'm sure that this is the cause of this issue.
Is there an improvement planned?
October 25, 2017, 12:30:08 PM
DLL is missing? why? 
October 25, 2017, 12:11:51 PM
Nice miner, switched over from EWBF on my 7 x 1080 Ti rig and 1 x 1080 Ti desktop. Went from 5275 sol/s to 5375 sol/s with less power consumption (2.75 sol/W to 2.85 sol/W). I also like the web view with averages rather than just snapshot of current status. More helpful to see longer term results for comparison on browser, I can always look at current speeds at miner window.
Curiously my overclocked cards draw less power now on same power target. I don't really mind since they now output more sols on less wattage, but I'd rather push them even harder with more power if possible. Is there a specific reason to limit power consumption or is it just due to software architecture?
Anyway well done dstm and looking forward to further improvements!
Curiously my overclocked cards draw less power now on same power target. I don't really mind since they now output more sols on less wattage, but I'd rather push them even harder with more power if possible. Is there a specific reason to limit power consumption or is it just due to software architecture?
Anyway well done dstm and looking forward to further improvements!
October 25, 2017, 09:46:34 AM
Update, I see improvement, hope to be stable also.
Suggestions :
- telemetry, i would like to see the uptime, info about pool ( connected/disconnected )
- I think you can get more power from 1080 TI
Thanks
October 25, 2017, 09:38:47 AM
What proxies do you guys use (if any)? Not really fan of connection per card architecture, forgive me dstm.
That's the purpose of this thread, if there is anything that needs improvement or is more usable for you this is the right place to ask.
I’m not quite familiar with the technicalities of mining algorithms, but what is advantage/disadvantage of connection per card architecture vs otherwise? Could this be the reason for increased cpu usage?
October 25, 2017, 09:01:25 AM
What proxies do you guys use (if any)? Not really fan of connection per card architecture, forgive me dstm.
That's the purpose of this thread, if there is anything that needs improvement or is more usable for you this is the right place to ask.
October 25, 2017, 08:26:42 AM
Just tried it on 4x1060
The rig is running 24/7 ethereum with +500mem, but pretty quickly dies with dstm...
The problem is it doesn't die gracefully...
A switch to kill if GPU goes bad is a must
The rig is running 24/7 ethereum with +500mem, but pretty quickly dies with dstm...
The problem is it doesn't die gracefully...
A switch to kill if GPU goes bad is a must
October 25, 2017, 08:16:42 AM
What proxies do you guys use (if any)? Not really fan of connection per card architecture, forgive me dstm.
October 25, 2017, 05:09:11 AM
I'm not sure I understand it correctly - could you pls explain this a bit more.
I think what he means is that when telemetry fails to start due to whatever reason, miner won't start either. I noticed that as well, for me though it wasn't a problem.
Right, zm exits if it can't bind the telemetry server to a socket. I designed it this way to make sure your telemetry settings are correct before it starts mining.
October 25, 2017, 04:48:24 AM
I'm not sure I understand it correctly - could you pls explain this a bit more.
I think what he means is that when telemetry fails to start due to whatever reason, miner won't start either. I noticed that as well, for me though it wasn't a problem.
Jump to: