Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 640. (Read 5805546 times)

While hopefully the next version works better,  why would you mine at a pool that goes offline once a day much less multiple times per minute?

I mean even if cgminer handles the drop perfectly you are still looking at a massive drop in aggregate output.

Awesome. I'll wait to see how the next version reacts to the main pool going offline and back online multiple times per minute.

Straight from my script:

14) An OC option:
 This is no longer needed since cgminer 2.* includes OC, however:

AMdOverdriveCtrl can't change anything that cgminer can't.  
cgminer already gives you remote access to clock/voltage/fan/inensity/etc.

This to answer the question while AMDOverdriveCtrl has a GUI component it can also be used from the command line (like bitcoin vs bitcoind) so you could control it remotely via scripts, web applications, etc.

However given cgminer does everything and already has an API ...

I'm interested in AMDOverdriveCtrl  you talked about,
I downloaded the package and find out that it is a GUI software,
I wonder if it can be used remotely to control clock/voltage?

The API currently just changes the priority of a single chosen pool to '0' and enables it.
(Just like the switch command in the keyboard interface)

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

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

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.

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?

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.

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.

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

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

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

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.

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


The resulting failure:

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

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.

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.