I talked to Sonny today at BFL, the default temp-cutoff for BFL units in cgminer is set way too low. He advised at the default should be around 85C... right now it seems to be set at 30C or so (I've not checked the code) - so trying to startup a BFL unit with a stock cgminer at rev 2.3.3 starts with an immediate temp cutoff warning and the unit goes into REST.
Manually setting the cutoff gets around the issue, but 30C is even above idle temps for a powered on unit.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 599. (Read 5805746 times)
April 20, 2012, 08:01:01 PM
April 20, 2012, 07:03:03 PM
Let's talk interface. What's needed, what's considered redundant, and what's missing?
For me, miner.php actually does most of what's needed quite well, aside from saving the configuration and some of the more advanced features in other projects (like email notifications). I don't even use the command line interface once it's started, unless troubleshooting - even then, dumping to a log is easier. So is the text interface even necessary anymore?
I don't really know of anyone who has computers and at least one doesn't have a web browser open ...
I did write the few commands necessary to get it working in linux on xubuntu and posted it here before ...
Hmm :
add "--api-listen" to cgminer startup
sudo apt-get install apache2
sudo apt-get install php5
sudo /etc/init.d/apache2 reload
copy miner.php into /var/www/
browser view http://yourcomputer/miner.php (of course where yourcomputer is the name or IP of your miner)
You wont need to edit miner.php if it is the same computer as cgminer
Once you try anything more complex - multiple rigs or a different computer running the web server:
You only need miner.php to run on one computer even if you have multiple rigs:
For multiple rigs (or where miner.php is on a different computer to the single rig)
Read the top of the code.
But basically, each cgminer will need to grant read access to the machine running miner.php
(if you don't care about read access security just use --api-listen --api-network)
To grant read access in cgminer to the web server IP: --api-listen --api-allow IP/32
To grant write/privileged access in cgminer to the web server IP: --api-listen --api-allow W:IP/32
Then you just edit the $rigs at the top of miner.php (it has 2 examples)
and you can read about the other options there also.
April 20, 2012, 06:17:07 PM
Well yeah, if you don't want to run a php interpreter, a web server, and a browser...
Fair enough. What about just displaying totals with max/min ranges for each device class? It'd be easier to see at a glance whether something is amiss. Status on individual devices could still be available from a menu. A notification area would be able to alert for any abnormal events.
Code:
--------------------------------------------------------------------------------
[P]ool management [U]nit management [S]ettings [D]isplay options [Q]uit
CPU: 78.0C 3265RPM | 718.6/716.7Kh/s | A:496 R: 3 HW:0 U: 0.12/m I: 6
77.5C 3265RPM | 712.2/704.3Kh/s
GPU: 72.5C 4346RPM | 430.5/428.7Mh/s | A:29367 R: 79 HW:0 U: 5.92/m I: 9
38.0C 1128RPM | 119.2/124.3Mh/s
FPGA: 67.0C 3641RPM | 449.5/446.7Mh/s | A:60990 R: 93 HW:0 U: 12.25/m I: 9
67.0C 3641RPM | 449.5/446.7Mh/s
--------------------------------------------------------------------------------
If you want to see all devices all the time, the API seems the best option.
Edit: changed to mock-up minimums; it's easy to see a problem with one of the GPUs while the others are good
April 20, 2012, 06:15:45 PM
Let's talk interface. What's needed, what's considered redundant, and what's missing?
For me, miner.php actually does most of what's needed quite well, aside from saving the configuration and some of the more advanced features in other projects (like email notifications). I don't even use the command line interface once it's started, unless troubleshooting - even then, dumping to a log is easier. So is the text interface even necessary anymore?
April 20, 2012, 05:56:38 PM
Let's talk interface. What's needed, what's considered redundant, and what's missing?
For me, miner.php actually does most of what's needed quite well, aside from saving the configuration and some of the more advanced features in other projects (like email notifications). I don't even use the command line interface once it's started, unless troubleshooting - even then, dumping to a log is easier. So is the text interface even necessary anymore?
April 20, 2012, 05:53:16 PM
Let's talk interface. What's needed, what's considered redundant, and what's missing?
For me, miner.php actually does most of what's needed quite well, aside from saving the configuration and some of the more advanced features in other projects (like email notifications). I don't even use the command line interface once it's started, unless troubleshooting - even then, dumping to a log is easier. So is the text interface even necessary anymore?
April 20, 2012, 05:52:51 PM
Kano doesn't speak for this project. I'm open to suggestions. To be honest I was hoping by now one of the API front ends that people had coded could have replaced this ageing text based interface, but they're all not quite as comprehensive, and tend to need other software to work and so on, so I'm not going to include any of them (yet).
Let's talk interface. What's needed, what's considered redundant, and what's missing?
A lot of these were added initially simply because no one had ever offered so much information or features before, and as I added things to cgminer, I added the information to the display. Largely, the way people mine and the issues have changed. However, I don't want cgminer to only be suitable to miners with heaps of hardware. I still want it accessible to the miner with only one GPU that is mining.
Yes, the above is more suited to a debug output, IMHO. If I were to put it on a diet, I would start by deleting the Block: display. Additionally, the block numbers at the bottom could be eliminated. Let's talk interface. What's needed, what's considered redundant, and what's missing?
Code:
cgminer version 2.3.3 - Started: [2012-04-17 22:02:28]
--------------------------------------------------------------------------------
(5s):1534.0 (avg):1592.1 Mh/s | Q:47325 A:110020 R:304 HW:0 E:232% U:22.20/m
TQ: 6 ST: 6 SS: 127 DW: 4379 NB: 501 LW: 135131 GF: 78 RF: 44
Connected to http://au.ozco.in:8332 with LP as user ckolivas.0
Block: 000007382fac2ce444d7d5b79a1553bd... Started: [08:31:39]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 72.0C 3265RPM | 718.6/716.7Mh/s | A:49665 R:132 HW:0 U: 10.02/m I:11
GPU 1: 72.5C 4346RPM | 430.5/428.7Mh/s | A:29367 R: 79 HW:0 U: 5.92/m I: 9
GPU 2: 72.5C 3641RPM | 449.5/446.7Mh/s | A:30990 R: 93 HW:0 U: 6.25/m I: 9
--------------------------------------------------------------------------------
[2012-04-21 08:35:21] Accepted 00000000.ec068da4.1ba7d1ab GPU 0 thread 0 pool 1
[2012-04-21 08:35:22] Accepted 00000000.ad98a857.5cd189b9 GPU 0 thread 0 pool 1
[2012-04-21 08:35:26] Accepted 00000000.cca935f3.4f36a99c GPU 0 thread 0 pool 1
[2012-04-21 08:35:29] Accepted 00000000.6e86a341.0f4d32b6 GPU 0 thread 1 pool 1
A lot of these were added initially simply because no one had ever offered so much information or features before, and as I added things to cgminer, I added the information to the display. Largely, the way people mine and the issues have changed. However, I don't want cgminer to only be suitable to miners with heaps of hardware. I still want it accessible to the miner with only one GPU that is mining.
April 20, 2012, 05:41:22 PM
You're right, I won't get very far. I'll refrain from posting suggestions in the future... I mean really, who wants suggestions on how to improve a program or solve a problem?
Kano doesn't speak for this project. I'm open to suggestions. To be honest I was hoping by now one of the API front ends that people had coded could have replaced this ageing text based interface, but they're all not quite as comprehensive, and tend to need other software to work and so on, so I'm not going to include any of them (yet).Let's talk interface. What's needed, what's considered redundant, and what's missing?
Code:
cgminer version 2.3.3 - Started: [2012-04-17 22:02:28]
--------------------------------------------------------------------------------
(5s):1534.0 (avg):1592.1 Mh/s | Q:47325 A:110020 R:304 HW:0 E:232% U:22.20/m
TQ: 6 ST: 6 SS: 127 DW: 4379 NB: 501 LW: 135131 GF: 78 RF: 44
Connected to http://au.ozco.in:8332 with LP as user ckolivas.0
Block: 000007382fac2ce444d7d5b79a1553bd... Started: [08:31:39]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 72.0C 3265RPM | 718.6/716.7Mh/s | A:49665 R:132 HW:0 U: 10.02/m I:11
GPU 1: 72.5C 4346RPM | 430.5/428.7Mh/s | A:29367 R: 79 HW:0 U: 5.92/m I: 9
GPU 2: 72.5C 3641RPM | 449.5/446.7Mh/s | A:30990 R: 93 HW:0 U: 6.25/m I: 9
--------------------------------------------------------------------------------
[2012-04-21 08:35:21] Accepted 00000000.ec068da4.1ba7d1ab GPU 0 thread 0 pool 1
[2012-04-21 08:35:22] Accepted 00000000.ad98a857.5cd189b9 GPU 0 thread 0 pool 1
[2012-04-21 08:35:26] Accepted 00000000.cca935f3.4f36a99c GPU 0 thread 0 pool 1
[2012-04-21 08:35:29] Accepted 00000000.6e86a341.0f4d32b6 GPU 0 thread 1 pool 1
A lot of these were added initially simply because no one had ever offered so much information or features before, and as I added things to cgminer, I added the information to the display. Largely, the way people mine and the issues have changed. However, I don't want cgminer to only be suitable to miners with heaps of hardware. I still want it accessible to the miner with only one GPU that is mining.
April 20, 2012, 02:58:55 PM
Not sure if this was covered but is there going to be support for the x6500 fpga.
If someone sends me one, I can code it.Will you be able to return it.
No such thing as a free lunch I think.
Why not just give him access to a rig running the board in that case, anyway ?
If you want a feature nobody else needs you have to donate
The joys of using FPGAs ...
Fair enough. Would a nice bounty help.
April 20, 2012, 02:40:13 PM
One would think the sellers of the x6500 would be willing to provide one for free or at cost in return for development support.
April 20, 2012, 02:35:59 PM
Not sure if this was covered but is there going to be support for the x6500 fpga.
If someone sends me one, I can code it.Will you be able to return it.
No such thing as a free lunch I think.
Why not just give him access to a rig running the board in that case, anyway ?
If you want a feature nobody else needs you have to donate
The joys of using FPGAs ...
April 20, 2012, 02:34:11 PM
Not sure if this was covered but is there going to be support for the x6500 fpga.
If someone sends me one, I can code it.Will you be able to return it.
April 20, 2012, 02:29:35 PM
Not sure if this was covered but is there going to be support for the x6500 fpga.
If someone sends me one, I can code it. April 20, 2012, 02:13:49 PM
Not sure if this was covered but is there going to be support for the x6500 fpga.
April 20, 2012, 12:33:12 PM
You're right, I won't get very far. I'll refrain from posting suggestions in the future... I mean really, who wants suggestions on how to improve a program or solve a problem?
Again ... sigh ... it's spaced out and displayed that way coz that's what it was changed to when it was requested to be that way.... also, why I suggested you request a 2nd display format, is coz the current is that way by request.
April 20, 2012, 12:28:15 PM
Code:
cgminer version 2.4.0 - Started: [2012-04-20 16:40:08] [1 hour ago]
[P]ool management [D]evice management [S]ettings [Q]uit
------------------------------------------------------------------------------
Block: …abdc040d7363549aecca1746 @ 17:00:26 Pool: Eligius
HW:0 1769/1777 R:0.17% E: 3.00 ST:1 GF: 0 RF: 0 NB: 3
5850: 82.0C 308/ 310 R:0.15% | 6870: 74.0C 275/ 276 R:0.17%
BF S: 66.0C 823/ 825 R:0.30% | Icar: 363/ 366 R:0.07%
------------------------------------------------------------------------------
[2012-04-20 16:51:02] Accepted 2e1b3382/…baeac1c4 Radeon 5850
[2012-04-20 16:51:35] Accepted 36edf606/…15b1f2b6 BitForce Single
[2012-04-20 16:52:06] Accepted 6984daff/…bc3431e0 BitForce Single
[2012-04-20 16:53:51] Accepted 6aeb97ad/…788b5831 Icarus
[2012-04-20 16:54:39] Accepted 5863cba3/…8ca693d8 BitForce Single
[2012-04-20 16:54:41] Accepted e12c4c4f/…ceb3c76b BitForce Single
[2012-04-20 16:55:11] Accepted 9bda7e9c/…b9814a91 BitForce Single
[2012-04-20 16:55:55] Accepted d0adf8db/…d2423c69 Radeon 5850
[2012-04-20 16:55:56] Accepted 0a8978ab/…78f8dabd Radeon 6870
[2012-04-20 16:58:49] Accepted dae4c9ff/…e7e3e12d BitForce Single
[2012-04-20 16:59:27] Accepted 5a95e666/…51f6e5ec BitForce Single
[2012-04-20 16:59:58] Accepted 640dd886/…2f5edcd9 Icarus
[2012-04-20 17:00:26] LONGPOLL detected new block on network
[2012-04-20 16:59:58] Accepted 3549dffa/…786fd89d Icarus
[2012-04-20 16:59:59] Accepted f8fa89ac/…86f8dfaa Radeon 6870
April 20, 2012, 12:25:36 PM
...
Pull request is up for this.
https://github.com/ckolivas/cgminer/pulls
Convince me otherwise why you think this is good or needed.
No I'm not asking for more BTC - I don't want more BTC - just a reason why it's not bad to throw away the pool stats for the pool you delete - and thus why you ever use more than 32 pools
OK, I read your PM.Pull request is up for this.
https://github.com/ckolivas/cgminer/pulls
Quote
2) ability to delete pools over the API.
This has been discussed before, but its possible to do it in the CLI, it would be great if this were enabled over the API too; its one of the last things an alternate GUI using the API cant do.
Ill pledge 2.5 BTC for each feature if they make it into the mainline.[/i]
I don't like the idea of throwing away information ... when you delete a pool you lose all it's info.This has been discussed before, but its possible to do it in the CLI, it would be great if this were enabled over the API too; its one of the last things an alternate GUI using the API cant do.
Ill pledge 2.5 BTC for each feature if they make it into the mainline.[/i]
Convince me otherwise why you think this is good or needed.
No I'm not asking for more BTC - I don't want more BTC - just a reason why it's not bad to throw away the pool stats for the pool you delete - and thus why you ever use more than 32 pools
It's in the pull request now also.
April 20, 2012, 11:29:37 AM
You're right, I won't get very far. I'll refrain from posting suggestions in the future... I mean really, who wants suggestions on how to improve a program or solve a problem?
April 20, 2012, 11:11:07 AM
Are we somehow stuck in the current display format?
It's that way by request of paying customers.Quote
Why not compact the display. Do away with the share submission lines, or compact it to one line or something. Who cares what the hash of the share being submitted is?
Many people do actually.Quote
It's useful under limited circumstances, but it's really just fluff and not relevant.
In a standard 24 line terminal of cgminer, 5 of those lines are static lines that can be removed. Each line for GPU/BFL/ICA has lots of whitespace that can be compacted, possibly giving the ability to display 2 units per line instead of 1.
Line beginning with TQ completely irrelevant to immediate status information - can be moved to another screen. "Connected to..." line can be combined with the next Block line and/or moved to another screen for expanded display information.
That gives ~ 19 lines of display for unit status information, possibly combined into two lines, for a total of 38 units per miner... While that limit still sucks (A full rig box will get close to that limit), it's far more reasonable than 8.
Also - remove fractional Mh/s display ... just use whole numbers. You can definitely combine relevant information to two units per line with a little creative compacting.
Firstly, you wont get very far by saying how you want it different and your idea is better than how it has been for a long time as others have wanted it to be ...In a standard 24 line terminal of cgminer, 5 of those lines are static lines that can be removed. Each line for GPU/BFL/ICA has lots of whitespace that can be compacted, possibly giving the ability to display 2 units per line instead of 1.
Line beginning with TQ completely irrelevant to immediate status information - can be moved to another screen. "Connected to..." line can be combined with the next Block line and/or moved to another screen for expanded display information.
That gives ~ 19 lines of display for unit status information, possibly combined into two lines, for a total of 38 units per miner... While that limit still sucks (A full rig box will get close to that limit), it's far more reasonable than 8.
Also - remove fractional Mh/s display ... just use whole numbers. You can definitely combine relevant information to two units per line with a little creative compacting.
Ask ckolivas how much BTC he wants to add a 2nd optional display format and you may get your wish ... unless he doesn't want to do it
April 20, 2012, 09:43:14 AM
As a workaround, you could run several instances of cgminer, each managing 8 or whatever # devices works. You can define which devices each instance manages by using --device.
In the long run, I think its clear the GUI has to be separated from the miner, so ckolivas can concentrate doing what he does best, and any half competent dev can make a gui using the API. Of course then the API should work and not crash, its something I havent heard before, I hope someone looks in to that.
In that context, Id also like to bump my earlier feature request:
Got another feature request for the API. 2 in fact:
1) be able to read the worker name of a pool over the API
When using multiple workers for things like GPUmax, its currently impossible to distinguish between them. I can understand password being hidden, but the username is even visible on the screen, so why not expose at least the worker name over the API when calling the "pools" command ?
Pull request is up for this.In the long run, I think its clear the GUI has to be separated from the miner, so ckolivas can concentrate doing what he does best, and any half competent dev can make a gui using the API. Of course then the API should work and not crash, its something I havent heard before, I hope someone looks in to that.
In that context, Id also like to bump my earlier feature request:
Got another feature request for the API. 2 in fact:
1) be able to read the worker name of a pool over the API
When using multiple workers for things like GPUmax, its currently impossible to distinguish between them. I can understand password being hidden, but the username is even visible on the screen, so why not expose at least the worker name over the API when calling the "pools" command ?
https://github.com/ckolivas/cgminer/pulls
Quote
2) ability to delete pools over the API.
This has been discussed before, but its possible to do it in the CLI, it would be great if this were enabled over the API too; its one of the last things an alternate GUI using the API cant do.
Ill pledge 2.5 BTC for each feature if they make it into the mainline.[/i]
I don't like the idea of throwing away information ... when you delete a pool you lose all it's info.This has been discussed before, but its possible to do it in the CLI, it would be great if this were enabled over the API too; its one of the last things an alternate GUI using the API cant do.
Ill pledge 2.5 BTC for each feature if they make it into the mainline.[/i]
Convince me otherwise why you think this is good or needed.
No I'm not asking for more BTC - I don't want more BTC - just a reason why it's not bad to throw away the pool stats for the pool you delete - and thus why you ever use more than 32 pools
Jump to: