Bitcoin Forum
March 19, 2024, 02:08:38 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 [249] 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5805147 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (3 posts by 1+ user deleted.)
kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
April 20, 2012, 04:50:21 AM
 #4961

Who was the moron who thought up 8? Me. 14 was the tipping point. Beyond 14 the display became corrupt. It is impossible to create "windows" off-screen with a curses display meaning that when I tried to make the window larger, it generated all sorts of annoying problems to do with trying to "resuscitate" the display when it's resized to a reasonable size. Now I'm quite sure you really could not care less about the reasons behind the annoying code problems that affect me. The reason I chose 8 was that I figured anyone with more than 8 devices is likely to at some stage get to 16, 20, whatever, and NOT be using GPUs, since most drivers are limited to 8 devices. Bad choice? Maybe, but there is another limit at 14 which will affect you at some stage even if you're okay at 12. So I can easily change it to 14 on the next release, but then you'll be burnt beyond that. When I created the curses interface for cgminer I never anticipated device numbers would be a limit. I CAN rewrite it entirely to make no upper limit but that would involve doing some annoying code rewrites.
I was thinking (well I've actually already done the change on my machine) to make it 8 by default (though 14 now since you said there is some issue above 14) and a parameter --max-status-lines that people can use and be damned of the consequences of their own choice if they resize the screen?

No idea if that is problematic or not - but if resizing the screen before starting cgminer works OK for more than 14 (and not changing it smaller later) then those with many FPGA's who still want to see all that info in a single terminal window can cause their own problems if they wish by using the --max-status-lines option?

(and adding the option is of course a simple code change)

Though, I guess, I can see that coming back in the future to bite you coz people will then say it doesn't work when they use that option and resize the screen to mess it up ...

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710814118
Hero Member
*
Offline Offline

Posts: 1710814118

View Profile Personal Message (Offline)

Ignore
1710814118
Reply with quote  #2

1710814118
Report to moderator
1710814118
Hero Member
*
Offline Offline

Posts: 1710814118

View Profile Personal Message (Offline)

Ignore
1710814118
Reply with quote  #2

1710814118
Report to moderator
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
April 20, 2012, 05:25:20 AM
 #4962

Reluctant to add another line for something so flaky, variable, unreliable, and just plain broken. Doesn't make sense. Alas curses just isn't flexible enough to cope with this sort of usage where it has some idea of being used on fixed terminals where resizing is a big deal. curses...

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
P4man
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
April 20, 2012, 06:07:19 AM
 #4963

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 ?

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.

johnyj
Legendary
*
Offline Offline

Activity: 1988
Merit: 1007


Beyond Imagination


View Profile
April 20, 2012, 06:44:33 AM
 #4964

For my 5xxx cards, I found out that 2.2.6 works best. Although 2.3.3 also works fine, the cursor jumps everywhere on the screen randomly

I did see performance drop when I switch to diablo kernel, don't know why

-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
April 20, 2012, 10:04:10 AM
 #4965

For my 5xxx cards, I found out that 2.2.6 works best. Although 2.3.3 also works fine, the cursor jumps everywhere on the screen randomly

I did see performance drop when I switch to diablo kernel, don't know why
The diablo kernel is only for 2.6 SDK based installations. That said, the custom modified poclbm kernel I include is probably equally good, if not better, for 2.6 SDK based installations. However, 2.1/2.4/2.5 SDK installations will usually work best with the phatk kernel (which is chosen automatically anyway). As for why your cursor jumps all over the screen randomly, NFI.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
April 20, 2012, 02:08:32 PM
 #4966

Are we somehow stuck in the current display format?  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?  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.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
April 20, 2012, 02:43:14 PM
 #4967

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.
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.
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

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
April 20, 2012, 04:11:07 PM
 #4968

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 ...

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 Tongue

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
April 20, 2012, 04:29:37 PM
 #4969

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?

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
April 20, 2012, 05:25:36 PM
 #4970

...
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.
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.
It's in the pull request now also.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
April 20, 2012, 05:28:15 PM
 #4971

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

kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
April 20, 2012, 05:33:12 PM
 #4972

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.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
hashking
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
April 20, 2012, 07:13:49 PM
 #4973

Not sure if this was covered but is there going to be support for the x6500 fpga.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
April 20, 2012, 07:29:35 PM
 #4974

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.

hashking
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
April 20, 2012, 07:34:11 PM
 #4975

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.
bulanula
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
April 20, 2012, 07:35:59 PM
 #4976

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 Wink

The joys of using FPGAs ...
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1063


Gerald Davis


View Profile
April 20, 2012, 07:40:13 PM
 #4977

One would think the sellers of the x6500 would be willing to provide one for free or at cost in return for development support.
hashking
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
April 20, 2012, 07:58:55 PM
 #4978

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 Wink

The joys of using FPGAs ...

Fair enough.  Would a nice bounty help.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
April 20, 2012, 10:41:22 PM
 #4979

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
rjk
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


1ngldh


View Profile
April 20, 2012, 10:52:51 PM
 #4980

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.
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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Pages: « 1 ... 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 [249] 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!