Can someone post results for 1080ti with dual core cpu?Would be nice to know how cpu heavy it is
It's impossible to run a rig with multiple 1080ti's using an old dual core cpu. You might be able to do it with a modern one though.
EDIT: ***ON WINDOWS
Topic: [ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows) - page 139. (Read 224961 times)
October 21, 2017, 05:42:18 PM
It's impossible to run a rig with multiple 1080ti's using an old dual core cpu. You might be able to do it with a modern one though.
EDIT: ***ON WINDOWS
October 21, 2017, 03:26:58 PM
I have problems when i try miner with HUSH on pool.miningspeed.com with my 1070 rigs.
When i start the miner it says [20, "invalid solution XX"] as XX is number between 28-32.
Funny thing is that it works great on suprnova when i try it there.
Maybe its something with the pool config or its the miner, but i want to report it anyway.
When i start the miner it says [20, "invalid solution XX"] as XX is number between 28-32.
Funny thing is that it works great on suprnova when i try it there.
Maybe its something with the pool config or its the miner, but i want to report it anyway.
October 21, 2017, 02:56:22 PM
Can someone post results for 1080ti with dual core cpu?Would be nice to know how cpu heavy it is
October 21, 2017, 02:00:11 PM
Plate with inscription about error is bad idea. Need write error to log file end close program. In my *.bat file next command is reboot, and if program close after error, rig is not stop, but will reboot and continue work.
I'll add logfile support.
Rebooting on error is bad idea you might end up in a reboot loop which can damage your hardware.
After my rig start I get e-mail about this. I understand, if I get e-mail, may be my rig have problem. But I don't want immediately find out, it's just not required, and usually I is busy with other matters. So, for rig in 99% of cases, a reboot is enough to continue the work. But if a rig is stop, it's bad. Makes me nervous and interrupt current affairs. Also, I constantly started to go to the pool to see a lazy rig in advance and restart it, what I did not do before and it's tiresome. And to understand the reasons for the error, I will still later, in my spare time and in a comfortable environment.
I see, I think there is some confusion.
I'm not responsible for the error window on crash, I have not coded it into zm.
It's something that windows does if a program crashes.
As sublimus suggested: YOU need to disable Error Reporting in windows settings.
https://bitcointalksearch.org/topic/m.23316368
October 21, 2017, 01:51:07 PM
ZM.EXE has stopped working. Please fix this, I get this problem once a day and miner can't reset itself. I need to click "OK" on this error and only then it starts again. Can you update it, so even when there is this error it can start again
If it is a window error report YOU need to disable Error Reporting in windows settings.
October 21, 2017, 01:38:48 PM
Plate with inscription about error is bad idea. Need write error to log file end close program. In my *.bat file next command is reboot, and if program close after error, rig is not stop, but will reboot and continue work.
I'll add logfile support.
Rebooting on error is bad idea you might end up in a reboot loop which can damage your hardware.
After my rig start I get e-mail about this. I understand, if I get e-mail, may be my rig have problem. But I don't want immediately find out, it's just not required, and usually I is busy with other matters. So, for rig in 99% of cases, a reboot is enough to continue the work. But if a rig is stop, it's bad. Makes me nervous and interrupt current affairs. Also, I constantly started to go to the pool to see a lazy rig in advance and restart it, what I did not do before and it's tiresome. And to understand the reasons for the error, I will still later, in my spare time and in a comfortable environment.
I see, I think there is some confusion.
I'm not responsible for the error window on crash, I have not coded it into zm.
It's something that windows does if a program crashes.
As sublimus suggested: YOU need to disable Error Reporting in windows settings.
https://bitcointalksearch.org/topic/m.23316368
October 21, 2017, 01:27:53 PM
induktor,
card: 1 x1080 Ti
...
Hash rate at top efficiency: 600 Sols average (15 Sols more than EWBF miner)
...
Is it a joke or a mistake? 1080Ti should give u from 750 to 790 sol (in OC mode) and from 695 to 750 (in non-OC mode) on EWFB. What 600 Sol/s are u talking about, man? ...
Hash rate at top efficiency: 600 Sols average (15 Sols more than EWBF miner)
...
October 21, 2017, 01:25:15 PM
Plate with inscription about error is bad idea. Need write error to log file end close program. In my *.bat file next command is reboot, and if program close after error, rig is not stop, but will reboot and continue work.
I'll add logfile support.
Rebooting on error is bad idea you might end up in a reboot loop which can damage your hardware.
After my rig start I get e-mail about this. I understand, if I get e-mail, may be my rig have problem. But I don't want immediately find out, it's just not required, and usually I is busy with other matters. So, for rig in 99% of cases, a reboot is enough to continue the work. But if a rig is stop, it's bad. Makes me nervous and interrupt current affairs. Also, I constantly started to go to the pool to see a lazy rig in advance and restart it, what I did not do before and it's tiresome. And to understand the reasons for the error, I will still later, in my spare time and in a comfortable environment.
October 21, 2017, 12:44:54 PM
Miner is working flawless again, I deleted EWBF and running dstm on all machines now. --telemetry is working flawless.
October 21, 2017, 12:21:42 PM
@dstm i think what @sp_ meant was if one of the GPUs hang/crashes, if the miner could exit.
Most of us including me have a bit more advanced batch scripts that get executed when miner crashes/reboots.
In my case, i apply overclocking every time before the miner process starts, since the OC settings sometimes get lost when gpu crashes.
For example what happened to me last night was, that the miner possibly got into some trouble (i don't know what happened) was down for 2 hours, when i woke up and did a routine check my batch script did restart the miner process.
But instead of one miner i had two miners running at the same time.
I guess your miner has some process restart functionality built in (which is nice) but some of us would like to handle such case manually if possible.
An option to simply exit the miner when gpu hangs/crashes would be greatly appreciated.
Most of us including me have a bit more advanced batch scripts that get executed when miner crashes/reboots.
In my case, i apply overclocking every time before the miner process starts, since the OC settings sometimes get lost when gpu crashes.
For example what happened to me last night was, that the miner possibly got into some trouble (i don't know what happened) was down for 2 hours, when i woke up and did a routine check my batch script did restart the miner process.
But instead of one miner i had two miners running at the same time.
I guess your miner has some process restart functionality built in (which is nice) but some of us would like to handle such case manually if possible.
An option to simply exit the miner when gpu hangs/crashes would be greatly appreciated.
I see, could you post an example script pls.
Something like this for example
Code:
@echo off
:: Configuration variables
SET POOL=eu1-zcash.flypool.org
SET POOL_PORT=3333
SET WALLET=xxxxxxxxxxxxxxxxxxxxxxxx
SET WORKER_NAME=1080
SET PASSWORD=x
:: Logging
SET LOGGING_LEVEL=1
SET AUTORESTART_LOGFILE=autorestart.log
:: Infinite work loop
:start
@cd /d "%~dp0"
:: Log that miner is about to start
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-3 delims=/:" %%a in ("%TIME%") do (set mytime=%%a:%%b:%%c)
echo %mydate% %mytime% - %WORKER_NAME% starting... >> %AUTORESTART_LOGFILE%
:: Apply Overclock through nvidia inspector [gpuIndex, pstateId, offset], [gpuIndex, percent]
cd NvidiaInspector
nvidiaInspector -setBaseClockOffset:0,0,140 -setMemoryClockOffset:0,0,340 -setPowerTarget:0,90
cd ..
:: Start miner
zm --server %POOL% --port %POOL_PORT% --user %WALLET%.%WORKER_NAME% --pass %PASSWORD%
:: Log that miner crashed
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-3 delims=/:" %%a in ("%TIME%") do (set mytime=%%a:%%b:%%c)
echo %mydate% %mytime% - %WORKER_NAME% crashed... >> %AUTORESTART_LOGFILE%
:: Print to console that miner has crashed and wait 5 seconds
echo Miner has crashed... restarting in 5 seconds...
ping 127.0.0.1 -n 5 > nul
:: Resume normal operation
goto start
:: Configuration variables
SET POOL=eu1-zcash.flypool.org
SET POOL_PORT=3333
SET WALLET=xxxxxxxxxxxxxxxxxxxxxxxx
SET WORKER_NAME=1080
SET PASSWORD=x
:: Logging
SET LOGGING_LEVEL=1
SET AUTORESTART_LOGFILE=autorestart.log
:: Infinite work loop
:start
@cd /d "%~dp0"
:: Log that miner is about to start
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-3 delims=/:" %%a in ("%TIME%") do (set mytime=%%a:%%b:%%c)
echo %mydate% %mytime% - %WORKER_NAME% starting... >> %AUTORESTART_LOGFILE%
:: Apply Overclock through nvidia inspector [gpuIndex, pstateId, offset], [gpuIndex, percent]
cd NvidiaInspector
nvidiaInspector -setBaseClockOffset:0,0,140 -setMemoryClockOffset:0,0,340 -setPowerTarget:0,90
cd ..
:: Start miner
zm --server %POOL% --port %POOL_PORT% --user %WALLET%.%WORKER_NAME% --pass %PASSWORD%
:: Log that miner crashed
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-3 delims=/:" %%a in ("%TIME%") do (set mytime=%%a:%%b:%%c)
echo %mydate% %mytime% - %WORKER_NAME% crashed... >> %AUTORESTART_LOGFILE%
:: Print to console that miner has crashed and wait 5 seconds
echo Miner has crashed... restarting in 5 seconds...
ping 127.0.0.1 -n 5 > nul
:: Resume normal operation
goto start
October 21, 2017, 12:09:43 PM
Could you add a --api option like EWBF so that information can be monitored from an external application? I use Awesome Miner to manage all my rigs and having this option is pretty much crucial.
Jim
see below:Jim
Hey guys , first review and problems:
First of all miner is better and more effective by 2-3 % than EWBF. I've been running it on several machines , got improved hashrate (GTX 1060 3gb from 280 ~ to 300 ~ , GTX 1070 from 470 to 490 , GTX 1080 from 540 to 550 , gtx 1080 ti from 720 - 740 , all vary bettwen + - 1-5 sol/s)
Machines are working fine with ETHcontrol , or anykind that has some watchdog that either restarts miner or knows what to do. But so far they are running stable.
Problem :
I got one rig with 7 cards and it seems that it cannot work good with dstm miner. It has 5x 1070 , 2x 1060 3g
First of all , to run it properly I had to lower power limit ALOT on all cards
Standart settings at afterburner: 80 pl / +150 core / +540 memory -----------> at this point miner and Ethcontrol comes in some loop that whenever miner is started it's always killed and restarted , because it hangs out too much time or shows 0 sol/s for cards (e.g. miner takes a lot of time to start and doesnt start at all)
Settings to start: 65 pl / +150 core / + 540 memory -----------> miner starts but this is what happens , after "1round of hashing good" it starts hashing super pooorly. I dont know what should be the case , all my rigs are identical , just this is the only one with more than 6 cards. All have same windows / drivers etc etc etc . CPU seems to be stuck at 100% at rig 1 though when I run ZM miner , probably some problems with more than 6 cards rig on win 10 ?
edit: I've tried a lot of different settings but in vain. Problems seems to be that POWER for cards makes crazy jumps (35-80 % PL for example) . Only time it worked fine for arround 5 mins , was because power limit somehow settled down at exactly 80 % (what was set) and it was running okey. Making any changes to OC settings results in various jumps in power and thus cards start to hashing super poorly. This is the only thing i've discovered.
First of all miner is better and more effective by 2-3 % than EWBF. I've been running it on several machines , got improved hashrate (GTX 1060 3gb from 280 ~ to 300 ~ , GTX 1070 from 470 to 490 , GTX 1080 from 540 to 550 , gtx 1080 ti from 720 - 740 , all vary bettwen + - 1-5 sol/s)
Machines are working fine with ETHcontrol , or anykind that has some watchdog that either restarts miner or knows what to do. But so far they are running stable.
Problem :
I got one rig with 7 cards and it seems that it cannot work good with dstm miner. It has 5x 1070 , 2x 1060 3g
First of all , to run it properly I had to lower power limit ALOT on all cards
Standart settings at afterburner: 80 pl / +150 core / +540 memory -----------> at this point miner and Ethcontrol comes in some loop that whenever miner is started it's always killed and restarted , because it hangs out too much time or shows 0 sol/s for cards (e.g. miner takes a lot of time to start and doesnt start at all)
Settings to start: 65 pl / +150 core / + 540 memory -----------> miner starts but this is what happens , after "1round of hashing good" it starts hashing super pooorly. I dont know what should be the case , all my rigs are identical , just this is the only one with more than 6 cards. All have same windows / drivers etc etc etc . CPU seems to be stuck at 100% at rig 1 though when I run ZM miner , probably some problems with more than 6 cards rig on win 10 ?
edit: I've tried a lot of different settings but in vain. Problems seems to be that POWER for cards makes crazy jumps (35-80 % PL for example) . Only time it worked fine for arround 5 mins , was because power limit somehow settled down at exactly 80 % (what was set) and it was running okey. Making any changes to OC settings results in various jumps in power and thus cards start to hashing super poorly. This is the only thing i've discovered.
Thx for the report, this is very helpful.
I'm currently heavier on CPU load.
It looks like your CPU is to slow to provide enough work for the GPUs. CPU load increases with the total solution rate of your system - so this is most likely why your 7card rig is having troubles since it requires more cpu time. What CPU are you on?
It's intel 1151 , G3930 , it's not impressive but it's not on the downside of any processors.
edit. I got such processor on all my machines , and also planning to add up to total of 8 cards on each of them soon , so this might be huge problem to run ur miner @ them
Try using older versions of drivers, in Linux that had a huge impact on CPU usage.
--api needed
API is present, see my older conversation with dstm on how to read it.Edit: wrong quote
October 21, 2017, 12:05:06 PM
I will prefer that it also output the shares being delivered, like the EWBF miner does, so we can see what is going on, specially the latency, we have a pretty crappy ISP and monitor the latency is pretty important for us.
The amount of found shares during the last round is indicated by the '++++' signs.
Could you pls describe in more detail this. How do you monitor the latency?
If this is important I'll add latency monitoring into the miner.
Hi dstm, thanks for answering.
this is what i mean, check the EWBF output for instance:
---
Oct 21 18:48:29 room1 logger: #033[36mGPU0: 457 Sol/s GPU1: 470 Sol/s GPU2: 484 Sol/s GPU3: 468 Sol/s GPU4: 471 Sol/s GPU5: 477 Sol/s #033[0m
Oct 21 18:48:29 room1 logger: #033[36mTotal speed: 2827 Sol/s#033[0m
Oct 21 18:48:31 room1 logger: #033[32mINFO 18:48:31: GPU2 Accepted share 292ms [A:1466, R:3]#033[0m
Oct 21 18:48:34 room1 logger: #033[32mINFO 18:48:34: GPU4 Accepted share 308ms [A:1310, R:6]#033[0m
---
see?, I can see the distribution of work between GPUs (sometimes when one gpu is picky, you can see that it's delivering lots of less results than the rest.
the milliseconds of the accept share, tells me whats the connection quality with the pool is, when I have ISP problems that number frequently goes up to 1000 milliseconds!!!! or more!.
also the accepted/rejected between [] is helpful, not really important since that info is also at the pool, so... we can use the pool for checking that.
also EWBF shows when he is mining the devfee, saying Accepted devfee xxxms, which is nice to know.
thanks!
indkt.
Thx, I see.
Yes, that seems to be useful. I'll think about a way to integrate this into the ui.
Maybe I'll provide an option to switch to an event based view instead of a summary based view.
Submitted devfee shares are indicated by a '*'.
Accepted/Rejected shares are accessible via the web-ui or json-rpc.
October 21, 2017, 11:54:23 AM
I will prefer that it also output the shares being delivered, like the EWBF miner does, so we can see what is going on, specially the latency, we have a pretty crappy ISP and monitor the latency is pretty important for us.
The amount of found shares during the last round is indicated by the '++++' signs.
Could you pls describe in more detail this. How do you monitor the latency?
If this is important I'll add latency monitoring into the miner.
Hi dstm, thanks for answering.
this is what i mean, check the EWBF output for instance:
---
Oct 21 18:48:29 room1 logger: #033[36mGPU0: 457 Sol/s GPU1: 470 Sol/s GPU2: 484 Sol/s GPU3: 468 Sol/s GPU4: 471 Sol/s GPU5: 477 Sol/s #033[0m
Oct 21 18:48:29 room1 logger: #033[36mTotal speed: 2827 Sol/s#033[0m
Oct 21 18:48:31 room1 logger: #033[32mINFO 18:48:31: GPU2 Accepted share 292ms [A:1466, R:3]#033[0m
Oct 21 18:48:34 room1 logger: #033[32mINFO 18:48:34: GPU4 Accepted share 308ms [A:1310, R:6]#033[0m
---
see?, I can see the distribution of work between GPUs (sometimes when one gpu is picky, you can see that it's delivering lots of less results than the rest.
the milliseconds of the accept share, tells me whats the connection quality with the pool is, when I have ISP problems that number frequently goes up to 1000 milliseconds!!!! or more!.
also the accepted/rejected between [] is helpful, not really important since that info is also at the pool, so... we can use the pool for checking that.
also EWBF shows when he is mining the devfee, saying Accepted devfee xxxms, which is nice to know.
thanks!
indkt.
October 21, 2017, 11:43:49 AM
@dstm i think what @sp_ meant was if one of the GPUs hang/crashes, if the miner could exit.
Most of us including me have a bit more advanced batch scripts that get executed when miner crashes/reboots.
In my case, i apply overclocking every time before the miner process starts, since the OC settings sometimes get lost when gpu crashes.
For example what happened to me last night was, that the miner possibly got into some trouble (i don't know what happened) was down for 2 hours, when i woke up and did a routine check my batch script did restart the miner process.
But instead of one miner i had two miners running at the same time.
I guess your miner has some process restart functionality built in (which is nice) but some of us would like to handle such case manually if possible.
An option to simply exit the miner when gpu hangs/crashes would be greatly appreciated.
Most of us including me have a bit more advanced batch scripts that get executed when miner crashes/reboots.
In my case, i apply overclocking every time before the miner process starts, since the OC settings sometimes get lost when gpu crashes.
For example what happened to me last night was, that the miner possibly got into some trouble (i don't know what happened) was down for 2 hours, when i woke up and did a routine check my batch script did restart the miner process.
But instead of one miner i had two miners running at the same time.
I guess your miner has some process restart functionality built in (which is nice) but some of us would like to handle such case manually if possible.
An option to simply exit the miner when gpu hangs/crashes would be greatly appreciated.
I see, could you post an example script pls.
October 21, 2017, 11:38:49 AM
@dstm i think what @sp_ meant was if one of the GPUs hang/crashes, if the miner could exit.
Most of us including me have a bit more advanced batch scripts that get executed when miner crashes/reboots.
In my case, i apply overclocking every time before the miner process starts, since the OC settings sometimes get lost when gpu crashes.
For example what happened to me last night was, that the miner possibly got into some trouble (i don't know what happened) was down for 2 hours, when i woke up and did a routine check my batch script did restart the miner process.
But instead of one miner i had two miners running at the same time.
I guess your miner has some process restart functionality built in (which is nice) but some of us would like to handle such case manually if possible.
An option to simply exit the miner when gpu hangs/crashes would be greatly appreciated.
Most of us including me have a bit more advanced batch scripts that get executed when miner crashes/reboots.
In my case, i apply overclocking every time before the miner process starts, since the OC settings sometimes get lost when gpu crashes.
For example what happened to me last night was, that the miner possibly got into some trouble (i don't know what happened) was down for 2 hours, when i woke up and did a routine check my batch script did restart the miner process.
But instead of one miner i had two miners running at the same time.
I guess your miner has some process restart functionality built in (which is nice) but some of us would like to handle such case manually if possible.
An option to simply exit the miner when gpu hangs/crashes would be greatly appreciated.
October 21, 2017, 11:28:12 AM
Segmentation fault gpu_id 1 3 0x10830010600 unspecified launch failure
gpu 1 unresponsive - check overclocking
cudaMemcpy 1 failed
./zm-zec.sh: line 1: 32357 Segmentation fault
((((
ps: in ewbf all ok
gpu 1 unresponsive - check overclocking
cudaMemcpy 1 failed
./zm-zec.sh: line 1: 32357 Segmentation fault
((((
ps: in ewbf all ok
Stable overclocking on a particular miner doesn't imply it's stable on all miners, it might simply crash because I'm using different instructions or because of a higher level of parallelism in zm.
October 21, 2017, 11:23:35 AM
I will prefer that it also output the shares being delivered, like the EWBF miner does, so we can see what is going on, specially the latency, we have a pretty crappy ISP and monitor the latency is pretty important for us.
The amount of found shares during the last round is indicated by the '++++' signs.
Could you pls describe in more detail this. How do you monitor the latency?
If this is important I'll add latency monitoring into the miner.
October 21, 2017, 11:13:16 AM
Sorry if this has been asked before.
Is there any way to select which graphic card you want to use?
Thanks
Is there any way to select which graphic card you want to use?
Thanks
You can use the '--list-devices' option to get a list of available devices, use the '--dev' option to select devices i.e 'zm --dev 0 1 2 --server ....'
October 21, 2017, 11:10:03 AM
Just tested on gtx 1070 g1 gaming. (micron memory)
core +150
mem +700
tdp 100%
505 sol/s average rate. Pretty good.But haven't verified the results on the pool yet. The Pool results are looking good
ewfb is doing 480 at the same clock so thats a 5.2% improvement.
I would like the miner to exit up on a crash instead of restarting. Is this possible?
core +150
mem +700
tdp 100%
505 sol/s average rate. Pretty good.
ewfb is doing 480 at the same clock so thats a 5.2% improvement.
I would like the miner to exit up on a crash instead of restarting. Is this possible?
I'm not trying to restart the GPUs if they get unresponsive currently, I'm not sure what you mean by 'crash'. ZM reconnects on socket failures, if this is what you're talking about - so yes I'll add an option to make this configurable.
October 21, 2017, 11:01:16 AM
Could you add a --api option like EWBF so that information can be monitored from an external application? I use Awesome Miner to manage all my rigs and having this option is pretty much crucial.
Jim
Jim
You already have that. Use "--telemetry=" insted of "--api"
Jump to: