Show Posts
|
Pages: [1] 2 3 4 5 »
|
So, i disconnected the risers for 7 out of 8 cards which allowed windows to update it self without the need of fresh reinstall, after it came back online i had to plug in the extra cards in one by one (add one, let it install the drivers, shut down, add another and so on). Everything is working now  The "Meltdown" security patch did lower the mining performance by 1.23% on Intel G4400 so not too bad.
|
|
|
For people that are wondering about the "Meltdown" security patch performance decrease on their mining rigs on Windows 10 From the one miner that i have which is running Intel G4400 and 8 GPUs (1x 980ti, 7x 1060 3GB).
The performance on 0.5.8 before the patch = 2597 h/s Performance after Meltdown security patch = 2565 h/s
So about 1.23% decrease in hashrate.
|
|
|
Thanks guys, i am going to try to update the rig today in a way that @Vann described, as i usually also run other stuff on the rig, so a simple firewall wouldn't do it for me (but nice idea though)!
I am guessing this would have to be done on every major update, since the windows 10 updater/installer doesn't want to work correctly with this many GPUs, i should probably start looking into some linux alternatives, as this will become a huge PITA really quickly.
Ill report back when the upgrade is done, thanks again guys!
|
|
|
Hi, i was wondering how you guys update your windows mining rig when it comes to the "big" updates (in this case the falls creator update). While my machine is rock stable and has been for months, since the falls creator update became available, i wasn't able to upgrade to it, every time windows wants to install it, after rebooting it fails. I thought i would install a fresh copy of windows then when i have some time, only to find out i am not even able to properly boot the windows installer from an usb stick (Windows starts loading from there and after while gets stuck in a black screen).
Is there some preferred method that you guys use to update your rig? I am pretty sure i could get this going by disconnecting 7 out of 8 gpus and disabling the 4g decoding in bios, but as you can imagine this is quite of an PITA to do and i would like to avoid that if possible.
Any insights/recommendations are welcome.
|
|
|
after returning to v5.6 after 3 hours of work, the average profit increased to 0.59 ZEC ... how to explain it?
Difficulty changed, for example i now earn good 15-20% less than i earned 20 hours ago. While still using the same miner, looking at my flypool graph, there is no significant different between 0.5.6 and 0.5.7 when it comes to submitted shares or their difficulty.
|
|
|
Anyone know how to access the JSON-RPC server? Not the website but the raw JSON data behind the API
Unfortunately there doesn't seem to be a raw JSON data available (from what i can see) Maybe @dstm could add that in the future? The first post does seem to mention JSON api being available? It might be useful to provide a bit more info on that i guess. You have a documentation inside the zipfile of the miner called json-rpc, everything needed in here.  Sorry to bother but, i'm with mlotis and cTnko on this one, what am I doing wrong? I think this could help you a bit (this utilizes jquery for the $.ajax method $.ajax({ url: 'http://192.168.1.6:42000/', method: 'POST', dataType: 'json', data: {'id': 1, 'method': 'getstat'} }).done(function (data) { console.log(data); });
|
|
|
Anyone know how to access the JSON-RPC server? Not the website but the raw JSON data behind the API
Unfortunately there doesn't seem to be a raw JSON data available (from what i can see) Maybe @dstm could add that in the future? The first post does seem to mention JSON api being available? It might be useful to provide a bit more info on that i guess.
|
|
|
For the people that see different share rate on 0.5.7 vs 0.5.6, since the amount of shares submitted depends on the difficulty, i don't think that is the right metric to look at. I use flypool and the estimated hashrate reported by the pool is pretty much the same for both versions on my 8 gpu rig.
|
|
|
New Version 0.5.7
reduce cpu load minor performance improvements con: use single pool connection con: ssl: clear session data before reconnect nvml: handle invalid values
This release contains quite some technical work/optimizations, which results most notably in a lower cpu load - about 40% - 30%. It also contains minor solver performance improvements - most notable on an 1060 - about 0.5%, pretty small - however it's still there. ZM uses now a single connection to the pool, since some pools/routers seemed to have difficulties with multiple connections - this might help people who had regular disconnects. Pools which adjust the difficulty based on the share rate won't be able to distinguish between the GPUs because zm uses a single connections now - so the difficulty and thus the share rate might change.
People who requested failover pool support: I'm planning to support it in the next release, I'm releasing this iteration first to make sure the transition to a single connection works as expected.
Thank you for an awesome update, the overall cpu usage on my 8 GPU rig dropped from 45-50% to 25-30% which is quite significant improvement. I can also see the 0.5% improvement on the 1060 cards, great job!
|
|
|
@dstm Is there any reason why the process wouldn't exit on its own under such condition?
Thx for reporting. 0.5.6 has some changes how it handles GPU crashes - it contains some initial recover infrastructure. Previous versions exited immediately in this case - I'll look into it. Thanks for acknowledging this, ill keep an eye on the next version in the future, keep up the good work 
|
|
|
@dstm Is there any reason why the process wouldn't exit on its own under such condition?  Too much OC made your GPU hang, either reboot or reset drivers with nvidia inspector, it should unlock the GPU's and u'll be able to kill the ZM process. Dtsm work very differently of other Zcash miners, you need to take another approach of your PL/OC otherwise u'll never find your sweetspot or completly miss the mark. Good luck. Thank you, but i know pretty much all of that, i have been mining for quite some time now. What i wanted to know was why the miner process didn't exit, pretty much all other miners i tried force closed them selves after a critical error like this one. While i can write my self a script that can monitor the reported hashrate from json data and force close the process or reboot the machine when desired, if the miner could close it self like all the others it would make things much simpler for most miners out there, since most people use infinite while loop scripts that simply restarts the process after it exits.
|
|
|
@dstm Is there any reason why the process wouldn't exit on its own under such condition? 
|
|
|
Since updating to 0.5.5, on Windows 10 (clean install), when the miner encounters various errors, the error will sometimes appear in a Windows message box and blocks the miner from continuing to mine until I hit "Ok." Was this version accidentally built as Debug instead of Release (i.e. in Visual Studio)?!?!!
I am wondering about the same thing (also ran into this issue recently)
|
|
|
@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.
I see, could you post an example script pls. Something like this for example @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
|
|
|
@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.
|
|
|
cTnko
i am starting to use your GUI, but the OC feature is not working for me on my 1080`s evga dt. it change the TDP and fan speeds but the memori clocks or gpu clocks arent working i am using the lastes driver for nvidia
That's interesting and definitely shouldn't be happening, which driver version are you currently running ? Have you also tried setting the overclock through the config file (with just regular excavator, without the GUI)? That should tell us more (if the issue is on the GUI side or excavator side).
|
|
|
Anyone else having trouble with latest nvidia drivers and 1070 (385.28) ? Installed the new drivers after EWBF's miner had crashed overnight (been running like a month straight) and got Error 31 on one of my cards ? Went back to previous version and it works fine.
Which driver works best for you? I am also experiencing some odd crashes on my 1060 3GB with the latest drivers.
|
|
|
hey guys, what is the hash rate for 1080? not ti. Anybody tried?
I get 35MH on 1080 You should be closer to 40, really. I am also getting about 35MH on my 1080, which miner are you using?
|
|
|
|