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

[DeathAndTaxes]

FYI, Kano wrote and maintains the API...

Thanks for letting me know.  
https://bitcointalk.org/index.php?topic=52466.0

So ... password/encrypted traffic ... some time down the road ...

I was just hoping for something simple in next version rather than some financial services certified end to end encrypted system which may not be in the next 20 versions.  Just something that would prevent casual port sniffing attack like bitcoind uses.  simple password = quick & easy.

My guess is that getting some encryption scheme wrapped around JSON will take some time and then it will require implementing encryption on the other end which will slow down development of things like android app to control hashing farm because now developers will need to not only for wait for encrypted version of API but implement and test compatible encryption on the remote platform too.

[1713440641]

1713440641

[1713440641]

1713440641

[1713440641]

1713440641

[johnyj]

I'm getting this error in the log together with a restart, is it normal?

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"       after 31076 requests (31076 known processed) with 0 events remaining.

[jake262144]

Doesn't really matter about being stored in a config file.  If the attacker has access to the config file he has access to your machine (and possibly as admin/root) and can do anything he wants including force your GPU to overheat from the command line.

I have a strong dislike for cleat text passwords stored in config files.
Access rights need to be very cautiously set on all such files.

True, once the attacker gains shell access, you're in deep trouble.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)

Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.

[DeathAndTaxes]

True, once the attacker gains shell access, you're in deep trouble.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)

Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.

I agree for most applications there is no reason for anything less than per password salted SHA-256.  Passwords should be transmitted only encrypted and only after host has authenticated itself.

Still this is Bitcoin mining not a financial services database.

[P4man]

True, once the attacker gains shell access, you're in deep trouble.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)

Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.

But cgminer already stores passwords in clear text and transmits them as such. Of course they are not important passwords (workers), but the same goes for protecting the API. Only an idiot would set the same password as for his email/facebook whatever. But then that idiot might be using that password for his workers already, so nothing changes there.

[QuantumFoam]

I've been thinking about writing a small c program using the API to manage my pools more effectively when my main pool has issues, which has been a LOT lately. The problem when the main pool has issues is it is constantly going up and down multiple times a minute, and that really chokes my hashrate when that happens. As it stands, the failover does not handle this situation well and keeps trying to submit shares to the intermittently failing pool, and keeps switching back to that pool when it briefly comes back online.

What the program would do is try and detect this situation and switch/disable the offending pool for a set amount of time so my hashrate/shares per min don't plummet. As it stands now, reading through the API I would probably have to have the program read the active logfile to detect the situation as there does not seem to be a way to get notifications for the "Pool 0 communication failure, caching submissions" event. If this kind of logic is being added into cgminer sometime soon (perhaps as an optional flag), I'll not waste time developing my hack for it.

[P4man]

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.

[-ck]

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.

It's actually a longstanding bug I've been fighting for some time. The driver really shouldn't be reporting back speeds of the lower profile but it screws everything up when it does.

[jake262144]

Only an idiot would set the same password as for his email/facebook whatever. But then that idiot might be using that password for his workers already, so nothing changes there.

Ah, the old 1d10t error code

Did you per chance hear about protests against the ACTA treaty being signed in Europe?
Many government websites were brought down as an act of defiance.
Apparently, Polish Prime Minister needed admin-rights access to his official site... the password was revealed to have been admin1

[ancow]

Current git fails to build kernels. According to a bisect, the following commit is the problem:

Code:

commit 26c59fbf0f399950d843faba5a9a0fb5dc345df6
Author: Con Kolivas <kernel@kolivas.org>
Date:   Wed Feb 22 16:59:28 2012 +1100

    Allow the worksize to be set per-device.

The resulting failure:

<snip>

[-ck]

Current git fails to build kernels. According to a bisect, the following commit is the problem:

Code:

commit 26c59fbf0f399950d843faba5a9a0fb5dc345df6
Author: Con Kolivas <kernel@kolivas.org>
Date:   Wed Feb 22 16:59:28 2012 +1100

    Allow the worksize to be set per-device.

Heh you couldn't wait till I finished it Yeah I'm still working on the code, thanks.

edit: Yes I know I shouldn't leave the master branch in an unworkable state but I had to rush off and didn't want to lose my work to date.

[johnyj]

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.

Same here, I use AMDOverdriveCtrl to handle each graphic card, and when there is no load due to lag of pool, the card automatically drop clocks to 157Mhz, I think it is a feature of ATI powerplay on card, has nothing to do with cgminer/AMDoverdriveCtrl. But when load is re-applied to the card, AMDOverdriveCtrl immediately shows the clock returned to 900Mhz, but cgminer's hash rate will only slowly climb back to original hashrate in about 10 minutes

But I take it as a feature Smoothly increase the load on card will improve the stability when there is a sudden change in the clock frequency

[ancow]

Heh you couldn't wait till I finished it Yeah I'm still working on the code, thanks.

edit: Yes I know I shouldn't leave the master branch in an unworkable state but I had to rush off and didn't want to lose my work to date.

I figured as much, just wanted to make sure you knew about it. And you'd just left IRC when I was about to ask...

[-ck]

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.

Same here, I use AMDOverdriveCtrl to handle each graphic card, and when there is no load due to lag of pool, the card automatically drop clocks to 157Mhz, I think it is a feature of ATI powerplay on card, has nothing to do with cgminer/AMDoverdriveCtrl. But when load is re-applied to the card, AMDOverdriveCtrl immediately shows the clock returned to 900Mhz, but cgminer's hash rate will only slowly climb back to original hashrate in about 10 minutes

But I take it as a feature Smoothly increase the load on card will improve the stability when there is a sudden change in the clock frequency

A number of niggling issues cause drop in hashrate over longpolls and network outages in 2.2.7. Fixed in next version.  Hold on to your hats...

[P4man]

. But when load is re-applied to the card, AMDOverdriveCtrl immediately shows the clock returned to 900Mhz, but cgminer's hash rate will only slowly climb back to original hashrate in about 10 minutes

I take it you arent using auto-gpu with a clockspeed range then. If you are, it doesnt start at 900, it will start at whatever you configured as lowest in the range (say 700-1000 in my case) and then slowly increase back to 1GHz. Same behavior as when it overheats. So its not the average hashrate Im talking about, its the clock.

[leveer]

Any chance the pool settings could be stored in a separate configuration file? It would sure make changing those in bulk/on multiple rigs a lot easier, when my pool preference order changes... distribute one pools.conf to each rig.

It also would be nice to have an ability to re-order pools from within cgminer.

I've got 3 BTC in bounty for each.

[kano]

Any chance the pool settings could be stored in a separate configuration file? It would sure make changing those in bulk/on multiple rigs a lot easier, when my pool preference order changes... distribute one pools.conf to each rig.

It also would be nice to have an ability to re-order pools from within cgminer.

I've got 3 BTC in bounty for each.

Can I have the 2nd one
With the API, you simply move any pool of choice to position 0 (highest priority).
The number of moves to get the required order is at maximum, the number of pools.
How many pools do you have anyway?

[The00Dustin]

Does the API actually reorder the pools or just change the priority?  I don't see any need for the pools to be reordered, I'm just curious.  In fact, if I have pools 1,2,3,4 and they are at default priority but I want to make the priority order 3,2,4 with 1 disabled, I simply disable 1 from the UI and then set 3 to priority 0. A t this point, the priority order is technically 3,1,2,4, but 1 is disabled, so it's fine.  Once one is familiar with the priority changing it should never take more priority changes than you have pools in order to achieve the priority he wants.

[leveer]

Any chance the pool settings could be stored in a separate configuration file? It would sure make changing those in bulk/on multiple rigs a lot easier, when my pool preference order changes... distribute one pools.conf to each rig.

It also would be nice to have an ability to re-order pools from within cgminer.

I've got 3 BTC in bounty for each.

Can I have the 2nd one
With the API, you simply move any pool of choice to position 0 (highest priority).
The number of moves to get the required order is at maximum, the number of pools.
How many pools do you have anyway?

Frankly, I have no idea how to use the API. Have started cgminer with the --api-listen command, and can get 127.0.0.1:4028 to return a file called "download," but that's as much as I can get. Would prefer to use miner.php based on the description, but opening it in a browser just yields the text contents of the file...

EDIT: Notably, using Windows...

[kano]

Any chance the pool settings could be stored in a separate configuration file? It would sure make changing those in bulk/on multiple rigs a lot easier, when my pool preference order changes... distribute one pools.conf to each rig.

It also would be nice to have an ability to re-order pools from within cgminer.

I've got 3 BTC in bounty for each.

Can I have the 2nd one
With the API, you simply move any pool of choice to position 0 (highest priority).
The number of moves to get the required order is at maximum, the number of pools.
How many pools do you have anyway?

Frankly, I have no idea how to use the API. Have started cgminer with the --api-listen command, and can get 127.0.0.1:4028 to return a file called "download," but that's as much as I can get. Would prefer to use miner.php based on the description, but opening it in a browser just yields the text contents of the file...

EDIT: Notably, using Windows...

Well you can actually do it from within cgminer anyway:
Press "P" for Pool management
"S" for Switch pool
and then the number of the pool -> this will make it the top priority pool

So if you have pools 0, 1 & 2 but want the priority to be 2, 1, 0
You would first switch to 1 then switch to 2

As for the other half
I've just put up a pull request to ckolivas (after I asked him if he was interested in it - he said no)
to allow one "include":"filename" in the json file (which is allowed to be recursive - up to 10 times - to avoid infinite loops)
It's simple and will not be made more complex.

If you save the configuration from within cgminer, the output will contain ALL settings (except will not contain the "include" setting)
The reasoning behind this is that if you change anything within cgminer, there could be complex multiple definition issues and all settings loaded and changed would need attributes about where they came from and if they were changed - way too complex.
Also, if you set a setting within cgminer that was in an included file, the included file would always override it, your setting would never stick.

Separating just the pools and only having them in their own file would be a backward compatibility problem.

Hopefully the simple solution is enough, coz I can't see a more complex version ever being implemented (since it would require a major redesign of how configuration settings are handled within cgminer)

We'll see if he allows it in or not