Re: The display.
Screw it, I don't really want to change the layout, or what's displayed, so I've spent the afternoon fighting with curses to try and get it working with any number of devices, provided your window is long enough. If it's not, you'll lose the log window output.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 597. (Read 5806103 times)
April 21, 2012, 01:35:43 AM
April 20, 2012, 11:58:11 PM
Both 2.3.2 and 2.3.3 windows versions stop working on user switching.
2.3.1 works well.
Win7 x64, SDK 2.6.
User switching?... What on earth has the cgminer version got to do with that? 2.3.1 works well.
Win7 x64, SDK 2.6.
April 20, 2012, 11:40:33 PM
Both 2.3.2 and 2.3.3 windows versions stop working on user switching.
2.3.1 works well.
Win7 x64, SDK 2.6.
2.3.1 works well.
Win7 x64, SDK 2.6.
April 20, 2012, 09:11:53 PM
2.3.1 did/does not exhibit this behavior with the same cgminer.conf file.
No, I'm not confusing it. The thermostat between the chips is what it's reading I believe, so 85C is the correct temperature for that particular reading. 72F is for ambient temperature, not die/near die temp.
No, I'm not confusing it. The thermostat between the chips is what it's reading I believe, so 85C is the correct temperature for that particular reading. 72F is for ambient temperature, not die/near die temp.
April 20, 2012, 08:44:17 PM
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.
Sure you (or Sonny) aren't confusing C and F? He told me BFL Singles need 72 F / 22 C) ambient temp to run at full speed. My on-FPGA temp for BFSingle is 149 F / 65 C even with an ambient temp of about 80 F. There shouldn't be a 30 C cutoff... Manually setting the cutoff gets around the issue, but 30C is even above idle temps for a powered on unit.
April 20, 2012, 08:23:24 PM
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.
The cutoff temp defaults to 95°CManually setting the cutoff gets around the issue, but 30C is even above idle temps for a powered on unit.
Please check that you do not have an autoloaded cgminer.conf that contains 30°C or you somehow accidentally put that on your command line.
If this has never worked, then maybe the code Luke-jr uses only detects the 2nd version of the Temperature message that BFL devices can send (BFL doesn't like people knowing that information it would appear from a discussion I've had with someone else on the same subject earlier today)
So ... is this something new with 2.3.3 (where the temp handling code hasn't changed recently) or something that never worked before?
Or do you have a specific version that does work and the current version no longer works?
(this could be related to the issue I mentioned about BFL changing the status reply)
Though I'd guess Luke-jr should know about which versions of his bitforce.c code that support which messages.
April 20, 2012, 08:01:01 PM
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.
Manually setting the cutoff gets around the issue, but 30C is even above idle temps for a powered on unit.
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.
Jump to: