 Show Posts
|
|
Pages: [1] 2 3 4 5 6 »
|
thx for the kill process update. Does anyone here actually use this with NVidia miners? I'm getting crashes and hard resets all over the place. My list of excluded miners is growing (every time a miner crashes the system I remove it): ExcludeMiners_NVIDIA = N-hsrminer_hsr*,N-NsCudaMiner*,N-CryptoDredge*,N-CcminerSTS*,N-CcminerDumax*,N-Prospector*,N-CcminerEnemy*,N-SuprMinerSP*
|
|
|
|
hi, with latest code the endless error loop still occurs: Stop-Process : Cannot stop process "Idle (0)" because of the following error: Access is denied
At C:\miner\Forager\Include.ps1:128 char:17
+ Stop-Process -InputObject $Process -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (System.Diagnostics.Process (Idle):Process) [Stop-Process], ProcessCommandException
+ FullyQualifiedErrorId : CouldNotStopProcess,Microsoft.PowerShell.Commands.StopProcessCommand
Stop-Process : Cannot stop process "Idle (0)" because of the following error: Access is denied
last useful entries in logfile are 11:03:20.88 Info N-CcminerEnemy-1.12/X17/X17 with Power Limit 0 (id 34-0) for group NVIDIA is the best combination for device group, last was N-SuprMinerSP-4.0a/X16r/X16r with Power Limit 0 (id 84-0) for group NVIDIA
11:03:20.88 Info Killing in 0 sec. N-SuprMinerSP-4.0a/X16r/X16r with Power Limit 0 (id 84-0) for group NVIDIA with system process id 0
this happens after some time during the benchmarking which really takes forever and repeats on each restart since there are so many miners that fail -- most fail right at startup (close immedately after being started), and the script usually catches the failing miner -- but before the endless error loop happens it apparently doesn't detect that the miner process is not running, just sits there with 0% load until the interval ends and then goes into the loop described above. |
|
|
|
hi, Just tried the latest Forager code (cloned from github), as MegaMiner seems abandoned.. there are, however, some issues. There are a couple error messages repeated before every new interval: Cannot index into a null array.
At C:\miner\Forager\Include.ps1:425 char:17
+ ... $PnpDeviceProperties = ($PnpDevices | Where-Object {$Vend ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : NullArray
Doesn't seem to cause any problems, though. However on two out of three systems I tested, one hard crashes, and one goes into an endless error loop, something like "cannot kill process "IDLE". Unfortunately the error is not written into the log, have to catch and copy it again. This is all on Nvidia rigs where MegaMiner has been running fine and stable for many months. |
|
|
|
|
is there a way to run MM as a farm monitor only? on a PC without mining?
|
|
|
|
I see a problem with the recently added always updating "benchmark" results: when you add or remove GPUs after you've done the benchmarks the results get messed up, as the currently running algos will change in values, whereas others will not. especially when adding GPUs this will move the current top algo(s) up ahead above the others so they never run again and therefore also don't update their results.
maybe an option to disable the updating after benchmarks could be added?
I think a better solution would be to delete your current benchmarks and re-bench everything when you make a hardware change.. That way you would have the most up to date accurate info out there... in principle yes -- but since accurate benchmarking takes like 6 hours this is not a practical solution. I'm not talking about major architecture changes (like adding new/different GPU types), but simply adding or removing a card of the same type -- so hashing speed simply scales over all algos. since obtaining GPUs for reasonable prices is extremely difficult now I'm simply adding them when I get them. so a rig running (and benchmarked) with three 1070ti might get another 1070ti added once a week until the rig is full. re-running the benchmarks every time is just not practical and also a loss of profits. |
|
|
|
|
I see a problem with the recently added always updating "benchmark" results: when you add or remove GPUs after you've done the benchmarks the results get messed up, as the currently running algos will change in values, whereas others will not. especially when adding GPUs this will move the current top algo(s) up ahead above the others so they never run again and therefore also don't update their results.
maybe an option to disable the updating after benchmarks could be added?
|
|
|
|
I would like to use ZPool as a backup pool only when the main pool is offline. I guess the easiest way to implement would be to divide all the profits by 10, so the main pool would always appear more profitable.
Any drawback to that solution by just adding a zero to the end of the divisor? Only one I can think of right now is forgetting about it when updating the scripts -- so a custom multiplier per pool in the config would be nice...
At this moment divide the profits is good solution. $Request | Get-Member -MemberType properties| ForEach-Object {
$coin=$Request | Select-Object -ExpandProperty $_.name
$Zpool_Algo = get_algo_unified_name ($_.name)
$Divisor = (Get_Algo_Divisor $Zpool_Algo) / 1000
Is this the correct place? I'll change it to divide by 10000, so it should always be less than other pool... |
|
|
|
|
I would like to use ZPool as a backup pool only when the main pool is offline. I guess the easiest way to implement would be to divide all the profits by 10, so the main pool would always appear more profitable.
Any drawback to that solution by just adding a zero to the end of the divisor? Only one I can think of right now is forgetting about it when updating the scripts -- so a custom multiplier per pool in the config would be nice...
|
|
|
|
|
some miners/algos take a long time to ramp up hashing to full speed. depending on which algos you're hashing it might take longer than the 200 seconds to perform fully.
|
|
|
|
Got an increase after clean install of drivers. At 65% 1080ti thats my stats:  Check the dates can anyone share some hints on how to update NVidia drivers via RDP on Win10? Don't have any screens attached to my rigs.. even with a local display updating the drivers for 8 GPU systems takes forever -- only tried it once via RDP and seems to be stuck somewhere in the middle.. turned off the system after 1 hour... |
|
|
|
|
Monitoring MegaMiner machines:
While an API endpoint that could be requested from remote machines would be nice, I'm guessing this is a lot to implement and will come after other, more important features, issues and updates.
In the meantime I'd still like to monitor the miners, so I'm suggesting a simple push monitoring method: every time the "Current" screen gets refreshed (or every X minutes -- whatever is easier to implement), MegaMiner would post the current stats (as shown on the Current screen) to a remote server with a simple REST HTTP POST with the data JSON formatted. While I actually haven't done any PowerShell scripting ever, I do know .NET, so I should be able to implement this and post the data to my own (local) server.
Where do you suggest to insert a method call for that?
|
|
|
|
i ordered two of Dell Vostro 260 .... it has 4 pci express ports and it.s 100€
where in the EU can you find something like that? |
|
|
|
|
yeah.. some kind of dashboard would be great.
I tried to use EthMonitoring today, but could not get it to connect to the miner APIs. Also the api port is random (see my post above with the idea of being able to set a fixed port).
|
|
|
|
|
Is there a way to set a fixed port for miners so that external monitoring sw can access the current stats? right now it chooses a different random port number every time a miner starts.
|
|
|
|
|
I have a strange issue with 8 GPUs on Windows 10 (1709, x64). Using 8x 1070Ti when starting up ccminer it only hashes on 1-3 GPUs. It then takes several minutes until all GPUs start working.. sometimes an additional one starts every minute, sometimes suddenly after 5 minutes all of the rest start hashing. First noticed it on mining PHI, but the same behavior also occurs with other algorithms.
something I noticed is that it sometimes prints one last "Intensity set to ...." message before all GPUs start mining, but not always. maybe that is related to the delay?
is there something that can be tweaked or done to make all GPUs start up quicker?
happy new year!
|
|
|
|
|
Is there a possibility to include some kind of watchdog to the scripts?
Like use the Gpu% value, and if the average over all GPUs is less than 50% for 5 minutes kill the miner process and restart it?
Last night I had two systems mining Phi on ahashpool, and both miner processes where stuck at "Stratum connection interrupted" messages they kept printing every minute or so. MegaMiner still displayed the last hashrate and happily kept the miners open all night (as it was the most profitable 24h all the time). as soon as I manually closed the miner process everything started up just fine again.
Maybe something like that could be added, since it is parsing and displaying the GPU usage anyway..?
thanks...
|
|
|
|
|
I have problems on two systems that run fine with 5.0 release. different errors during benchmarking, and benchmarking never turns up any numbers in the profits screen. on one of them the "current" screen shows errors on one GPU, while the actual miner window shows all GPUs working just fine. never had those probs with 5.0, reverting back to 5.0 now
|
|
|
|
Lyra2v2 is problematic for nvidia, the miner itself reports 30% higher hashrate than actual. Perhaps you should add a penalty for the algorithm on nvidia or check what miner gives a real hashrate.
just checked, and I seem to have the same problem.. both ccMinerAlexisHSR and ccminerPolytmos seem to report 30-50% more LYRA2V2 hashrate than the pool reports. this is on a clean 5.0 release install. I'm sure there is a better real fix for this, but in the meantime if reduced all the numbers in the stats folder for the 4 lyra2v2 miners by half -- it was always stuck on that algo before. |
|
|
|
Lyra2v2 is problematic for nvidia, the miner itself reports 30% higher hashrate than actual. Perhaps you should add a penalty for the algorithm on nvidia or check what miner gives a real hashrate.
just checked, and I seem to have the same problem.. both ccMinerAlexisHSR and ccminerPolytmos seem to report 30-50% more LYRA2V2 hashrate than the pool reports. this is on a clean 5.0 release install. |
|
|
|
For using 24h profits, just change MiningMode from automatic to automatic24h in the bat file.
for which pools does automatic24h work (or does it work for all of them)? |
|
|
|
|
