dstm (OP)
|
|
October 25, 2017, 09:37:24 AM |
|
Hi dstm's developer,
I found a "bug", if telemetry fails at boot, for example when a power lose / power restore situation occurs, the miner won't start. System reboots on power fails, and miner start on boot, but for the router is not started yet...
Could you fix this? Thank you.
I'm not sure I understand it correctly - could you pls explain this a bit more.
|
|
|
|
balkeep
Newbie
Offline
Activity: 9
Merit: 0
|
|
October 25, 2017, 09: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.
|
|
|
|
dstm (OP)
|
|
October 25, 2017, 10: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.
|
|
|
|
usernameisalreadyinuse
Newbie
Offline
Activity: 9
Merit: 0
|
|
October 25, 2017, 01:16:42 PM |
|
What proxies do you guys use (if any)? Not really fan of connection per card architecture, forgive me dstm.
|
|
|
|
restless
Legendary
Offline
Activity: 1151
Merit: 1001
|
|
October 25, 2017, 01:26:42 PM |
|
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
|
|
|
|
dstm (OP)
|
|
October 25, 2017, 02:01:25 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.
|
|
|
|
raven1322
|
|
October 25, 2017, 02:38:47 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?
|
|
|
|
cristipuc
Newbie
Offline
Activity: 40
Merit: 0
|
|
October 25, 2017, 02:46:34 PM Last edit: October 25, 2017, 03:18:42 PM by cristipuc |
|
I don't see much improvement, i already get this speed with EWBF 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
|
|
|
|
Mursu
Newbie
Offline
Activity: 35
Merit: 0
|
|
October 25, 2017, 05: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!
|
|
|
|
igorsantos
Member
Offline
Activity: 179
Merit: 10
|
|
October 25, 2017, 05:30:08 PM |
|
DLL is missing? why?
|
|
|
|
bude
Newbie
Offline
Activity: 4
Merit: 0
|
|
October 25, 2017, 05: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?
|
|
|
|
miningspeed
Newbie
Offline
Activity: 43
Merit: 0
|
|
October 25, 2017, 07: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..
|
|
|
|
TheHiman
Newbie
Offline
Activity: 17
Merit: 0
|
|
October 25, 2017, 07: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 ?
|
|
|
|
usernameisalreadyinuse
Newbie
Offline
Activity: 9
Merit: 0
|
|
October 25, 2017, 07: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
|
|
|
|
evilcrypto
Member
Offline
Activity: 131
Merit: 20
|
|
October 25, 2017, 07:40:34 PM |
|
DLL is missing? why? Wich dll is missing ?
|
|
|
|
Freelancer76
Member
Offline
Activity: 386
Merit: 10
Hello fellow miners
|
|
October 25, 2017, 08:05:18 PM |
|
Works fine, few % increase in hashing power
|
|
|
|
dstm (OP)
|
|
October 25, 2017, 08: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?
Right, you're cpu bound. I've reduced the cpu load slightly (about 8-10 %), it's under testing currently.
|
|
|
|
dstm (OP)
|
|
October 25, 2017, 08:17:11 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 ?
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?
|
|
|
|
QuintLeo
Legendary
Offline
Activity: 1498
Merit: 1030
|
|
October 25, 2017, 08: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.
|
I'm no longer legendary just in my own mind! Like something I said? Donations gratefully accepted. LYLnTKvLefz9izJFUvEGQEZzSkz34b3N6U (Litecoin) 1GYbjMTPdCuV7dci3iCUiaRrcNuaiQrVYY (Bitcoin)
|
|
|
dstm (OP)
|
|
October 25, 2017, 08: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.
|
|
|
|
|