Just be sure to never save the config ...
speaking of saving the config.. i finally got around to trying this thru the api. when I did the voltages were all 0.00
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 599. (Read 5806103 times)
April 19, 2012, 01:27:36 PM
speaking of saving the config.. i finally got around to trying this thru the api. when I did the voltages were all 0.00
April 19, 2012, 01:22:51 PM
While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.
I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.
I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
Valid concern, yes. I haven't tried this, but if you had 16 devices (as an example) could you run 2 instances of cgminer on the same machine, each servicing 8 devices?I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.
I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
That is kind of what i am thinking. Not nearly as slick but doable. I'll be testing that later today.
(that can run anywhere on your network you like - however you'd need the latest miner.php version from my git until it's committed)
Just add an auto refresh to the page and it can even act just like the cgminer screen ...
And of course there are much more expansive monitoring tools for cgminer.
As for the limit - well, crashing cgminer or messing up the display completely sounds like a good idea to have a limit ...
... and yes you can run 10 copies of cgminer if you really want to and don't have a very small memory limit - one for each GPU/PGA if you really want to.
April 19, 2012, 01:14:48 PM
Does cgminer config file have a "comment" symbol?
If not could it be added to next version? #?
The simplest/easiest method would simply to only support leading charecter comment symbol.
More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.
If not could it be added to next version? #?
The simplest/easiest method would simply to only support leading charecter comment symbol.
Code:
#This line is a comment
# "auto-gpu" : true
#The command above has been commented out.
"auto-gpu" : true #This is invalid because the format only support leading char comment symbols
More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.
this works:
Code:
"__auto-gpu" : true
precede any attribute with underscores will prevent that attribute from loading.
Thus the answer to the first question is no.
Of course jjiimm_64's solution works to comment out an option.
Just be sure to never save the config ...
April 19, 2012, 12:41:08 PM
While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.
I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.
I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
Valid concern, yes. I haven't tried this, but if you had 16 devices (as an example) could you run 2 instances of cgminer on the same machine, each servicing 8 devices?I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.
I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
That is kind of what i am thinking. Not nearly as slick but doable. I'll be testing that later today.
April 19, 2012, 12:21:57 PM
While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.
I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.
I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
Valid concern, yes. I haven't tried this, but if you had 16 devices (as an example) could you run 2 instances of cgminer on the same machine, each servicing 8 devices? I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.
I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
April 19, 2012, 12:01:26 PM
I want the best possible code, putting a purity test of code (which is pure logic) is just asinine. Luke has found bugs (and fixes) in cgminer and bitcoind. Would the community be better served by running buggier software because you dislike him. As long as merges are vetted and not done without Due Diligence I honestly don't care if the unibomber wants to make a pull request.
Either the code changes have value or they doesn't. THAT (and only that) should be the metric.
To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority. The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward. Nobody will ever agree on perfect interface. There is no such thing. The API allows multiple front ends to be developed independently of cgminer.
It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc
cgminer just needs enough of a native interface to allow low level troubleshooting. So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).
Either the code changes have value or they doesn't. THAT (and only that) should be the metric.
To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority. The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward. Nobody will ever agree on perfect interface. There is no such thing. The API allows multiple front ends to be developed independently of cgminer.
It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc
cgminer just needs enough of a native interface to allow low level troubleshooting. So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).
+1 for maintaining sanity. Also agree with keeping UI development on cgminer minimal. There is great value and benefit keeping the UI decoupled from the 'work' code. It is a good design/implementation practice which manages complexity while adding flexibility. I once wondered why cgminer didn't have a Windows front-end, but it didn't take long to realize that the existing curses-based text UI is more than adequate.
While it may be true that a minimal interface is adequate, those of us that happen to have more than 8 devices on one cgminer and can no longer monitor them individually, are not receiving the same output that others see with less than 9 devices.
I can no longer monitor the temps or fan speeds or individual hash rates, rejects and hardware errors. No way of knowing IF one of the devises has a problem and, even if you knew, no way of figuring out which one has a problem either.
I have a mix of GPU and PGA's. That output is important to me. Why limit it to 8 devices?
April 19, 2012, 11:54:16 AM
Does cgminer config file have a "comment" symbol?
If not could it be added to next version? #?
The simplest/easiest method would simply to only support leading charecter comment symbol.
More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.
If not could it be added to next version? #?
The simplest/easiest method would simply to only support leading charecter comment symbol.
Code:
#This line is a comment
# "auto-gpu" : true
#The command above has been commented out.
"auto-gpu" : true #This is invalid because the format only support leading char comment symbols
More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.
this works:
Code:
"__auto-gpu" : true
precede any attribute with underscores will prevent that attribute from loading.
April 19, 2012, 10:22:54 AM
Does cgminer config file have a "comment" symbol?
If not could it be added to next version? #?
The simplest/easiest method would simply to only support leading charecter comment symbol.
More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.
If not could it be added to next version? #?
The simplest/easiest method would simply to only support leading charecter comment symbol.
Code:
#This line is a comment
# "auto-gpu" : true
#The command above has been commented out.
"auto-gpu" : true #This is invalid because the format only support leading char comment symbols
More comprehensive would be to allow parse right comments (like the last line in code above) but I would be happy for a leading comment check.
April 19, 2012, 09:47:11 AM
I want the best possible code, putting a purity test of code (which is pure logic) is just asinine. Luke has found bugs (and fixes) in cgminer and bitcoind. Would the community be better served by running buggier software because you dislike him. As long as merges are vetted and not done without Due Diligence I honestly don't care if the unibomber wants to make a pull request.
Either the code changes have value or they doesn't. THAT (and only that) should be the metric.
To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority. The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward. Nobody will ever agree on perfect interface. There is no such thing. The API allows multiple front ends to be developed independently of cgminer.
It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc
cgminer just needs enough of a native interface to allow low level troubleshooting. So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).
Either the code changes have value or they doesn't. THAT (and only that) should be the metric.
To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority. The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward. Nobody will ever agree on perfect interface. There is no such thing. The API allows multiple front ends to be developed independently of cgminer.
It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc
cgminer just needs enough of a native interface to allow low level troubleshooting. So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).
+1 for maintaining sanity. Also agree with keeping UI development on cgminer minimal. There is great value and benefit keeping the UI decoupled from the 'work' code. It is a good design/implementation practice which manages complexity while adding flexibility. I once wondered why cgminer didn't have a Windows front-end, but it didn't take long to realize that the existing curses-based text UI is more than adequate.
April 19, 2012, 09:39:18 AM
The problematic things he seems to like to do are related to changing the way things look because he wants it to look different - and they have been rejected in the past.
Otherwise, I think most of his code changes have gone in.
No, generally I haven't touched (nor have any particular interest in touching) display/output. The only times I've affected it were accidental/secondary from the real code change; the first, refactoring the code to support different drivers (this initially moved the driver-specific information - temperature and fan speed for GPUs - to the end of the device info line), and the second, fixing a bug I introduced with that first change when I used "BFL" to represent "FPGA" in the internal driver API (this was fixed by correcting it to "PGA" which kanoi suggested). Otherwise, I think most of his code changes have gone in.
April 19, 2012, 09:34:13 AM
...
Luke-jr's name is in the code and the AUTHORS file - he added his name after I did, but 'above' mine coz I guess he felt he was more important
I've left it in that order but in the hope that one day I could make this comment ... which I just did
Anyway, on the subject of accepting code - yep even Luke-jr's code gets accepted.
However, like my code, it gets vetted by ckolivas before it goes in.
The problematic things he seems to like to do are related to changing the way things look because he wants it to look different - and they have been rejected in the past.
Otherwise, I think most of his code changes have gone in.
Anyone who uses a BFL (or even an Icarus) is using the code that Luke-jr wrote.
Icarus code was based on the BFL code, a lot was rewritten due to the different way they work and then other changes have happened to the Icarus code since then (hmm I should add my latest LP Icarus change to the BFL code whenever I get around to sending a pull request ...)
Luke-jr's name is in the code and the AUTHORS file - he added his name after I did, but 'above' mine coz I guess he felt he was more important
I've left it in that order but in the hope that one day I could make this comment ... which I just did
Anyway, on the subject of accepting code - yep even Luke-jr's code gets accepted.
However, like my code, it gets vetted by ckolivas before it goes in.
The problematic things he seems to like to do are related to changing the way things look because he wants it to look different - and they have been rejected in the past.
Otherwise, I think most of his code changes have gone in.
Anyone who uses a BFL (or even an Icarus) is using the code that Luke-jr wrote.
Icarus code was based on the BFL code, a lot was rewritten due to the different way they work and then other changes have happened to the Icarus code since then (hmm I should add my latest LP Icarus change to the BFL code whenever I get around to sending a pull request ...)
April 19, 2012, 09:24:34 AM
I just downloaded cgminer 2.3.3 and I thought I'd give it a try. My initial impressions of it is that it's rather buggy and general usage is complicated by the long list of options displayed from cgminer --help.
Using this system setup:
Win7
Intel Q6600 Quad Core
Nvidia GTS250 w/ Driver 285.62
Latest cgminer win32-binary available: version 2.3.3 at time of this posting
Here are the list of problems I'm running into:
Causes my video driver to crash and restart. I also get the following cgminer output from the console window:
When this happens, memory usage spikes up to 1.951+ gb and it stays there, like a memory leak has just occurred. Here's a screenshot of it:
I get the same results for all 4 kernels:
In the case of using cgminer -k poclbm, I can't even get cgminer to quit by pressing 'q' or Ctrl-C. The only way to terminal the process was to kill it from task manager using 'end process'; yuck!
Here's an example output when I try to connect and test mine on a pool. The follow command was used:
produces the follow output:
Other miners I've used like phoenix and ufa-soft miner do not exhibit such problems and they work as expected. On the other hand, I can't even get a proper benchmark read out from cgminer. A search on this thread shows someone else with nvidia hardware encountering similar problems and difficulty though they were using an earlier version 2.2.3. Apparently the latest cgminer build hasn't address these problems yet.
Using this system setup:
Win7
Intel Q6600 Quad Core
Nvidia GTS250 w/ Driver 285.62
Latest cgminer win32-binary available: version 2.3.3 at time of this posting
Here are the list of problems I'm running into:
Code:
cgminer --benchmark
Causes my video driver to crash and restart. I also get the following cgminer output from the console window:
Code:
cgminer version 2.3.3 - Started: [2012-04-19 06:56:33]
--------------------------------------------------------------------------------
(5s):0.2 (avg):64.5 Mh/s | Q:0 A:0 R:0 HW:0 E:0% U:0.00/m
TQ: 2 ST: 0 SS: 0 DW: 0 NB: 0 LW: 0 GF: 0 RF: 0
Connected to Benchmark without LP as user Benchmark
Block: (null)... Started:
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 169.3/ 64.5Mh/s | A:0 R:0 HW:0 U:0.00/m I:14
--------------------------------------------------------------------------------
[2012-04-19 06:56:33] Started cgminer 2.3.3
[2012-04-19 06:56:35] Disabling extra threads due to dynamic mode.
[2012-04-19 06:56:35] Tune dynamic intensity with --gpu-dyninterval
[2012-04-19 06:56:41] Thread 1 being disabled
[2012-04-19 06:56:56] Error: clEnqueueReadBuffer failed. (clEnqueueReadBuffer)
[2012-04-19 06:56:56] Thread 0 failure, exiting
When this happens, memory usage spikes up to 1.951+ gb and it stays there, like a memory leak has just occurred. Here's a screenshot of it:
I get the same results for all 4 kernels:
Code:
-k diablo
-k diakgcn
-k poclbm
-k phatk
In the case of using cgminer -k poclbm, I can't even get cgminer to quit by pressing 'q' or Ctrl-C. The only way to terminal the process was to kill it from task manager using 'end process'; yuck!
Here's an example output when I try to connect and test mine on a pool. The follow command was used:
Code:
C:\cgminer-2.3.3-win32> cgminer -o http://us.eclipsemc.com:8337 -u username -p password
produces the follow output:
Code:
cgminer version 2.3.3 - Started: [2012-04-19 07:18:53]
--------------------------------------------------------------------------------
(5s):5.4 (avg):12.3 Mh/s | Q:103 A:0 R:0 HW:0 E:0% U:0.00/m
TQ: 2 ST: 0 SS: 0 DW: 0 NB: 1 LW: 1562 GF: 133 RF: 0
Connected to http://us.eclipsemc.com:8337 with LP as user username
Block: 000006f95499ba1ca3844065a373e62a... Started: [07:18:53]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 0.0/ 12.3Mh/s | A:0 R:0 HW:0 U:0.00/m I:14
--------------------------------------------------------------------------------
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:10] Pool 0 not providing work fast enough
[2012-04-19 07:19:11] Pool 0 not providing work fast enough
[2012-04-19 07:19:11] Pool 0 not providing work fast enough
Other miners I've used like phoenix and ufa-soft miner do not exhibit such problems and they work as expected. On the other hand, I can't even get a proper benchmark read out from cgminer. A search on this thread shows someone else with nvidia hardware encountering similar problems and difficulty though they were using an earlier version 2.2.3. Apparently the latest cgminer build hasn't address these problems yet.
April 19, 2012, 07:55:44 AM
OH GOD.
I can honestly say that I feel comfortable enough to speak for a good chunk of the community when I say that I am certain that many users would feel alot better if you had NOTHING to do with CGMiner, it's upkeep or it's forward/further development.
I can honestly say that I feel comfortable enough to speak for a good chunk of the community when I say that I am certain that many users would feel alot better if you had NOTHING to do with CGMiner, it's upkeep or it's forward/further development.
You don't speak for me, and I am not sure you even speak for a good chunk.
Here you go "detective":
http://rusty.ozlabs.org/?p=196
I want the best possible code, putting a purity test of code (which is pure logic) is just asinine. Luke has found bugs (and fixes) in cgminer and bitcoind. Would the community be better served by running buggier software because you dislike him. As long as merges are vetted and not done without Due Diligence I honestly don't care if the unibomber wants to make a pull request.
Either the code changes have value or they doesn't. THAT (and only that) should be the metric.
To try and get this somewhat back on topic my opininon is that changes to the interface on cgminer should be a low priority. The API paid for by many of us, coded by Kano, and integrated and tested by conman provide the perfect path forward. Nobody will ever agree on perfect interface. There is no such thing. The API allows multiple front ends to be developed independently of cgminer.
It allows separation of responsibilities:
kernel = hashing engine
cgminer = control & management
GUI = user interface, reporting, charting, etc
cgminer just needs enough of a native interface to allow low level troubleshooting. So many people cling to the obsolete GUIminer that I am surprised nobody has made a Windows GUI interface for cgminer (maybe I should).
April 19, 2012, 07:42:04 AM
...Though I did still offer to debug and write the fix for Gigavps, at a reasonable per-hour cost; I can't blame him for declining, considering it wouldn't get merged
OH GOD.
I can honestly say that I feel comfortable enough to speak for a good chunk of the community when I say that I am certain that many users would feel alot better if you had NOTHING to do with CGMiner, it's upkeep or it's forward/further development.
Con and Kano are doing an awesome job and every time you post, I can't help but feel you are doing nothing but trying to push them around and bend to YOUR will.....
Adding your name to the program's credits would serve as nothing more than to add a stain on the integrity and future public opinion of CGMiner in general.
Please stay away. For this, I can honestly say that I will pray to help ensure it.
April 18, 2012, 07:07:18 PM
that will be fine, and do you want to insert the quad support too?
"Are you talkin' to me?"
Yes, I've already asked for details on what changes in the API, and will have a look at BTCMiner sources as soon as I can get my hands on them. While I don't plan to own these quads soon, I do want cgminer to have the best possible ztex hardware support.
but it will be fine if it could be because of using cgminer with dd-wrt. Thank you for your work.
April 18, 2012, 06:51:27 PM
Meanwhile, posting about something that might be of use to a rare few people ...
I've updated the sample miner.php script to support multiple rigs.
(I split my rig so of course I needed to change miner.php
...
The new version of miner.php:
https://github.com/kanoi/cgminer/blob/master/miner.php
And just to be a little more useful I updated it to identify with colour some of the obvious warnings/errors:I've updated the sample miner.php script to support multiple rigs.
(I split my rig so of course I needed to change miner.php
...
The new version of miner.php:
https://github.com/kanoi/cgminer/blob/master/miner.php
Any Pool, GPU, PGA with 'Status' not 'Alive' will get a red background in it's 'Status' box.
Any GPU reporting zero for any of the ADL values - those values will get an orange (warning) background.
Any GPU, PGA that isn't enabled will get an orange (warning) background on the 'Enabled' field.
April 18, 2012, 04:24:58 AM
One of my gpu's stopped working and causes system crashes if I use it. Someone know a way to have it disabled in the config?
Use the -d option to specify which GPU's to use ...Edit: So ... in the config file that would be "device" (i.e. from --device)
April 18, 2012, 03:41:01 AM
One of my gpu's stopped working and causes system crashes if I use it. Someone know a way to have it disabled in the config?
April 17, 2012, 11:38:43 PM
Meanwhile, posting about something that might be of use to a rare few people ...
I've updated the sample miner.php script to support multiple rigs.
(I split my rig so of course I needed to change miner.php
It's of course not a replacement for those big systems like BAMT - but in my case I prefer something simple that only requires the one single php file to be able to see both my rigs summary and details.
If you run it as before with a single rig, it looks and works the same.
If you run it with multiple rigs, it displays a summary page first with buttons to display the same detail page as before for each rig.
The miner.php script explains the options at the top, but just to repeat one new part of that here:
Pull request:
https://github.com/ckolivas/cgminer/pull/164
My git commit:
https://github.com/kanoi/cgminer/commit/3a3912070e6cec353a71ea38da4c832a9db182b2
The new version of miner.php:
https://github.com/kanoi/cgminer/blob/master/miner.php
I've updated the sample miner.php script to support multiple rigs.
(I split my rig so of course I needed to change miner.php
It's of course not a replacement for those big systems like BAMT - but in my case I prefer something simple that only requires the one single php file to be able to see both my rigs summary and details.
If you run it as before with a single rig, it looks and works the same.
If you run it with multiple rigs, it displays a summary page first with buttons to display the same detail page as before for each rig.
The miner.php script explains the options at the top, but just to repeat one new part of that here:
Code:
# Set $rigs to an array of your cgminer rigs that are running
# format: 'IP:Port' or 'Host:Port'
# If you only have one rig, it will just show the detail of that rig
# If you have more than one rig it will show a summary of all the rigs
# with buttons to show the details of each rig
# e.g. $rigs = array('127.0.0.1:4028','myrig.com:4028');
$rigs = array('127.0.0.1:4028');
Pull request:
https://github.com/ckolivas/cgminer/pull/164
My git commit:
https://github.com/kanoi/cgminer/commit/3a3912070e6cec353a71ea38da4c832a9db182b2
The new version of miner.php:
https://github.com/kanoi/cgminer/blob/master/miner.php
April 17, 2012, 11:19:04 PM
Regarding CPU mining, there are valid pros and cons (no pun intended):
https://bitcointalksearch.org/topic/wonder-who-this-solominer-is-8862169-67634
https://bitcointalksearch.org/topic/forgetting-the-forgetful-68396
https://bitcointalksearch.org/topic/miners-that-refuse-to-include-transactions-are-becoming-a-problem-69423
https://bitcointalksearch.org/topic/wonder-who-this-solominer-is-8862169-67634
https://bitcointalksearch.org/topic/forgetting-the-forgetful-68396
https://bitcointalksearch.org/topic/miners-that-refuse-to-include-transactions-are-becoming-a-problem-69423
You said Regarding CPU mining there are valid pros and cons
and give us three links about a solominer who isnt accepting transactions
cp is kinda confused here (I understand the botnet reference) but it still does not relate at all to your comment
Looking at it again, I even confused myself a bit
I probably should've said there are pros & cons to CPU mining botnets. There was a lot of discussion on that issue in those threads.
Jump to: