OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[DeathAndTaxes]

I would prefer that you NEVER go back to CPU mining being enabled.  Any individual cannot make a profit on CPU mining alone unless they are not paying for electricity.  Even then, the profit for any one person would be minimal.  The only way it makes logical sense to use CPU mining is if you have access to hundreds or thousands of CPUs that you don't pay power for, and don't care if they burn up.  This whole thing screams of someone asking for it back for the sole purpose of operating a botnet, or something similar.

This, this, and this.

Keep cgminer on task.  GPU & FPGA mining (plus auto-gpu, overclocking, undervolting, pool management, stale detection, etc) is complex enough.  Legit CPU mining is dead and buried.  Please never resurrect it.  Hopefully in a year or so it is removed even from the source code.

[1715240155]

1715240155

[1715240155]

1715240155

[1715240155]

1715240155

[1715240155]

1715240155

[Luke-Jr]

Any individual cannot make a profit on CPU mining alone unless they are not paying for electricity.

Problem with this logic is that you're assuming all mining is done for profit. I find CPU mining very handy for testing without messing with my FPGAs.

For testing what?

Bitcoin code changes. Pool software code changes. I'm sure other developers can think of more.

[kano]

Any individual cannot make a profit on CPU mining alone unless they are not paying for electricity.

Problem with this logic is that you're assuming all mining is done for profit. I find CPU mining very handy for testing without messing with my FPGAs.

For testing what?

Bitcoin code changes. Pool software code changes. I'm sure other developers can think of more.

Luke-Jr, as you already know, there are known bugs in the CPU code (and some unknown ones)
Thus using the CPU code to test has been somewhat of a pointless exercise for a while now ...
(I can even get it to crash on startup every time with specific compile options including CPU mining)

[Luke-Jr]

Luke-Jr, as you already know, there are known bugs in the CPU code (and some unknown ones)

As I know, there are known bugs in both CPUmining code and non-CPUmining code that ckolivas simply refuses to allow anyone to fix. If it wasn't for that, they wouldn't be bugs anymore.

In any case, those bugs don't interfere with using cgminer for testing other software, yet.

[DeathAndTaxes]

In any case, those bugs don't interfere with using cgminer for testing other software, yet.

CPU support for cgminer is deprecated.  There should be no future bug fixes or enhancements.  Eventually the entire code base should be removed.

As far as needing a test platform wouldn't just using I don't know ... any GPU be a better test platform?  It would be immune to any CPU code bugs and would potentially detect any GPU code bugs.  Given the near universal nature of GPU and their low cost (especially used low end cards) seems silly to test using a code base that 99.9% of your users aren't using.

Then again I guess if it works for you it works for you and that is all that matters. 

[kano]

Luke-Jr, as you already know, there are known bugs in the CPU code (and some unknown ones)

As I know, there are known bugs in both CPUmining code and non-CPUmining code that ckolivas simply refuses to allow anyone to fix. If it wasn't for that, they wouldn't be bugs anymore.

In any case, those bugs don't interfere with using cgminer for testing other software, yet.

I presume you aren't referring to the 'bug' regarding device naming?

The one that we both agreed to abide by the response of the poll I created, but you not only ignored the poll results, but also went ahead and added more code changes to the git pull against the results of the poll ...

Seriously if you want to post vague misleading comments about non-CPUmining like that in this thread I will of course rebut them.

[Luke-Jr]

As far as needing a test platform wouldn't just using I don't know ... any GPU be a better test platform?

Except then you have to stop mining for real on that GPU.

Given the near universal nature of GPU and their low cost (especially used low end cards) seems silly to test using a code base that 99.9% of your users aren't using.

CPU mining and GPU mining use 99% of the same code, ever since I refactored cgminer to add FPGA support.

I presume you aren't referring to the 'bug' regarding device naming?

No, I was referring to other bugs, like the scantime bug.

The one that we both agreed to abide by the response of the poll I created, but you not only ignored the poll results, but also went ahead and added more code changes to the git pull against the results of the poll ...

No, you agreed to abide by the poll, not me. That was why I let you make it, as biased and misinformative as it was. The results express nothing, since the poll had nothing to do with the actual bugfix we were talking about.

[miscreanity]

Yeah, Gigabyte boards don't like to boot from USB with BAMT on them.  It's a known problem.

Strangely the behavior of giga boards seems to vary from model to model and even bios version to bios version so you can get "lucky".  That being said it is one reason I steer clear of gigabyte (I liked them pre-Bitcoin).  I mean bootstrapping is one of those core BIOS functions.  If a BIOS can't handle all supported methods of booting it shouldn't be sold.   Period.

True but I can't really RMA the board since NCIX specify that I can only exchange it for the same model...

I actually had some success last year booting some Gigabyte boards from USB with Plop. Most of the time, I was able to chainload by booting from a FAT16 Plop USB stick to another that held the OS.

The primary issue with Gigabyte (if I recall properly) is that a USB boot drive cannot have more than one partition and must be formatted with FAT16 - no FAT32. Quite aggravating.

I picked up the cheapest SATA drive I could get and it's been a much nicer experience since. It now acts as a multi-purpose server in addition to mining.

Regarding CPU mining, there are valid pros and cons (no pun intended):
https://bitcointalk.org/index.php?topic=67634.0
https://bitcointalk.org/index.php?topic=68396.0
https://bitcointalk.org/index.php?topic=69423.0

[cablepair]

Yeah, Gigabyte boards don't like to boot from USB with BAMT on them.  It's a known problem.

Strangely the behavior of giga boards seems to vary from model to model and even bios version to bios version so you can get "lucky".  That being said it is one reason I steer clear of gigabyte (I liked them pre-Bitcoin).  I mean bootstrapping is one of those core BIOS functions.  If a BIOS can't handle all supported methods of booting it shouldn't be sold.   Period.

True but I can't really RMA the board since NCIX specify that I can only exchange it for the same model...

I actually had some success last year booting some Gigabyte boards from USB with Plop. Most of the time, I was able to chainload by booting from a FAT16 Plop USB stick to another that held the OS.

The primary issue with Gigabyte (if I recall properly) is that a USB boot drive cannot have more than one partition and must be formatted with FAT16 - no FAT32. Quite aggravating.

I picked up the cheapest SATA drive I could get and it's been a much nicer experience since. It now acts as a multi-purpose server in addition to mining.

Regarding CPU mining, there are valid pros and cons (no pun intended):
https://bitcointalk.org/index.php?topic=67634.0
https://bitcointalk.org/index.php?topic=68396.0
https://bitcointalk.org/index.php?topic=69423.0

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


also Kano I love and respect you brother but I have to comment on this, In my humble opinion public forum polls are not a good method of making decisions and if I was luke-Jr I probably would not respect it either.

[kano]

...

The one that we both agreed to abide by the response of the poll I created, but you not only ignored the poll results, but also went ahead and added more code changes to the git pull against the results of the poll ...

No, you agreed to abide by the poll, not me. That was why I let you make it, as biased and misinformative as it was. The results express nothing, since the poll had nothing to do with the actual bugfix we were talking about.

Thu Mar 29 2012 GMT+11

Code:

11:14 < luke-jr> kanoi: hurry up and agree explicitly :P
11:14 < kanoi> I want all the code to say ICA/BFL :)
11:15 < kanoi> (and I'd bet the users do too :)
11:16 < luke-jr> kanoi: stop demanding a bug -.-
11:17 < luke-jr> con_: you pulled kanoi's feature without agreement, why not a bugfix? :p
11:18 < con_> his code has been in use a month, there is a precedent
11:18 < luke-jr> and the only person using it says the bugfix is fine.
11:18 < kanoi> it's also been on the sgminer screen even longer :)
11:18 < luke-jr> also, the bugfix has been in use a month too :P
11:18 < kanoi> cgminer
11:20 < kanoi> again it's simple to just do as my first comment said on the pull request so that extra info is known if there is some use for it (maybe even the API can be simplified a bit with the 'extra' info)
11:21 < luke-jr> I can add the driver name to the API, sure.
11:23 < kanoi> you know I wont respond to anything you say directly coz you try to make silly comments about the meaning of replying to your comments
11:23 < kanoi> I want all the code to say ICA/BFL :)
11:24 < kanoi> (as it does now has in the API for a month and in cgminer for even longer)
11:25 < luke-jr> kanoi: you admit it's broken right now, stop being a stubborn jerk and holding cgminer back
11:25 < kanoi> what's broken - who reported a bug? (other than you)
11:26 < luke-jr> kanoi: the API name is reported inconsistently among FPGAs. You reported the bug, and suggested the solution.
11:27 < luke-jr> shall I dig out the log?
11:27 < kanoi> It's reported in a different way to GPU's - however, seeing that extra information is way better
11:27 < kanoi> yep dig it out - I have it also :)
11:28 < luke-jr> if you want extra information, use the extra info for GPUs too
11:28 < kanoi> it aint there yet :)
11:28 < luke-jr> yes it is
11:29 < luke-jr> has been for a month, you're just holding it back by refusing to let con merge it
11:29 < kanoi> 15 days
11:29 < kanoi> but it doesn't identify the GPU
11:29 < luke-jr> yes it does
11:29 < kanoi> with 3 characters
11:29 < luke-jr> ohnoes
11:29 < kanoi> the API should match the screen
11:30 < kanoi> as it does now
11:30 < luke-jr> and it does with the fix
11:30 < kanoi> the so called fix - removes useful information
11:30 < kanoi> I dont call that a fix
11:31 < luke-jr> it doesn't.
11:31 < kanoi> cows fly (when you throw them out of planes! :)
11:32 < luke-jr> it adds more information.
11:32 < luke-jr> and puts it where it belongs
11:32 < kanoi> ti hides it from the screen user
11:32 < luke-jr> not really.
11:33 < kanoi> OK how about a poll on bitcointalk to see if people want it to say "PGA" or "ICA" and "BFL" and whatever other FPGA's come along :)
11:33 < luke-jr> will you abide by its conclusion?
11:33 < kanoi> yep :) If I write the poll
11:34 < kanoi> and enough people respond
11:34 < luke-jr> so you'll make it biased? -.-
11:34 < kanoi> no I wont make it biased like you always do with everything you say
11:34 < luke-jr> let me know when it's ready so I can vote.
11:34 < kanoi> ...
11:36 < luke-jr> …

My first comment in the pull request

This changes the name that people will look for the devices in the API
e.g. Icarus instead of ICA (thus it also doesn't match the current cgminer screen)
Better to create new fields if you want to add extra information IMO

The pull request:
https://github.com/ckolivas/cgminer/pull/157

The poll (that was linked in this thread also)
https://bitcointalk.org/index.php?topic=74532.0

[Luke-Jr]

By the way, another example to demonstrate multiple points that have come up tonight...

Gigavps recently came in the #CGMiner channel to report a bug about the "semi-graphical" command line display malfunctioning with more than 16 devices - he had just turned on a total of 17+ FPGAs.

How did I confirm this bug? Not with 17 FPGAs - can't expect every developer to have that kind of equipment handy for testing - but by using CPUmining to generate 17 CPU threads. So yet another thing CPUmining helps test is CGMiner's basic frameworks themselves.

Unfortunately, ckolivas expressed that he would refuse to merge a fix for this issue even if I wrote it. Pretty much defeats the point. (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)

P.S. Kanoi, thanks for digging out the logs which show you alone agreed to abide by your poll, but #CGMiner is a private channel and posting logs publicly is technically forbidden.

[kano]

By the way, another example to demonstrate multiple points that have come up tonight...

Gigavps recently came in the #CGMiner channel to report a bug about the "semi-graphical" command line display malfunctioning with more than 16 devices - he had just turned on a total of 17+ FPGAs.

How did I confirm this bug? Not with 17 FPGAs - can't expect every developer to have that kind of equipment handy for testing - but by using CPUmining to generate 17 CPU threads. So yet another thing CPUmining helps test is CGMiner's basic frameworks themselves.

Unfortunately, ckolivas expressed that he would refuse to merge a fix for this issue even if I wrote it. Pretty much defeats the point. (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)
...

Regarding gigavps's issue with too many devices ...

ckolivas' commit to resolve that 4 days ago that gigavps is using ...

Disable per-device status lines when there are more than 8 devices since screen output will be corrupted, enumerating them to the log output instead at startup
https://github.com/ckolivas/cgminer/commit/f3e4305620825dbaa61eb26b2a0b6d9f5c924338

...

How about 17 GPU threads ...

LOL I tried 10 threads per GPU on my 2x6950 rig and rather oddly the MH/s went up by 10MH/s each GPU for the first few minutes and then settled back down to the same value after that as with 2 threads per GPU

[miscreanity]

Regarding CPU mining, there are valid pros and cons (no pun intended):
https://bitcointalk.org/index.php?topic=67634.0
https://bitcointalk.org/index.php?topic=68396.0
https://bitcointalk.org/index.php?topic=69423.0

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.

[kano]

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:

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

[cuz0882]

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?

[kano]

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)

[kano]

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

[Chefnet]

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.

[bitlane]

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

[DeathAndTaxes]

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.

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