Topic: cgminer - CPU/GPU miner in C for linux/windows (Read 81916 times)

Generated a new thread making it the official CGMINER thread since it is the primary development now (and not cpuminer) and long since has become a project in its own right.

http://forum.bitcoin.org/index.php?topic=28402.0

Updated source tree and new source version:
http://ck.kolivas.org/apps/cgminer-1.2.4.tar.bz2

Changes in this version:
I've updated the jansson library to be in line with the current version (make sure to do ./autogen.sh again if you're building from git)
Fixed a bug where pools that return empty body http requests (such as bitcoinpool.com on longpoll requests) would crash.
Updated the display to make sure all the threads' progress is updated regularly.
Made the default display on the status line wider to not cut off last characters on high hash counts.

and most importantly:

Implemented a watchdog thread that keeps an eye on all the worker threads. If they are idle for more than a minute it restarts them completely. Hopefully this should address the GPU going idle issue since it re-initialises the card. I suspect that since both threads on the same GPU go idle at the same time that it's actually within the opencl code that there is an issue and I hope that it will respond to re-init.

Bummer.  I'll stick with poclbm for now.  It appears to handle it by toggling RollNTime support on and off based on the response to every getwork.  And it uses the most recently indicated LP URL each time a LP request is started instead of caching the URL once at startup and using it over and over.  I don't think it does anything to abort an in progress LP and start a new one when a more recent getwork http header indicates that it should be different, but it could do that as well, I guess.

Anyway, cgminer looks well done and I'm sure I'll keep playing with it on and off just because it is cool.  Thanks for making it!

Ya, certainly doesn't make sense to do it by default.  But if a pool (Eligius, for example, which also has a very high CPU cost to return a getwork response) announces to the miner that it supports it via the X-Roll-NTime: Y http header in the response to the getwork, you could increment the ntime when you exhausted all possible nonces instead of switching to another getwork.

I'm really not sure how it would cope with that. I doubt it will handle it gracefully.

I never said cgminer was a low efficiency miner! It usually is >90% even without rolling the time. It asks for work whenever it needs work, and that depends on how fast your GPU is as to how often it requests more work. I could certainly make it roll time by default at intermittent work intervals, but -not all pools support it- so that will bring unexpected results with rejected shares rising even though the efficiency rises.

Another question for you.  Does cgminer adapt to changing pool behavior on the fly?  For example, a long poll URL changing to a new URL.  Or X-Roll-NTime support appearing and disappearing from getwork to getwork.  In other words, does cgminer work well when pointed at a proxy where any given getwork request may be handled by one of several real pools with different capabilities.

I had some problems with DiabloMiner with that and so I currently stick with a bunch of individually started poclbm miners, but I am very interested in the idea of one miner per rig instead of multiple miners per GPU.

I care about my efficiency because I want to be a good pool citizen.   Doing getworks only once a minute reduces load on the pool.  Less load on the pool means higher pool reliability and more scalability with less hardware (which may translate to lower fees).  I can think of no reason to waste CPU and bandwidth with getwork requests every 5-10 seconds instead of once a minute for pools that support it.  There is benefit to the pool and no downside to the miner.

I registered with slush just to try it and it works fine for me?

cgminer doesn't give meaningful enough errors or fail if you give the wrong login credentials and I need to do something about that. Perhaps that was the issue here?

As far as I can see, Diablominer supports two pools at once, not really load balancing. If you run two instances of cgminer, one connecting to each pool, you get exactly the same effect so I see no advantage of doing this in the one process? Failover I have certainly considered adding.

Yes it does, but it only needs to resort to using it when network connectivity is down. Since cgminer preemptively asynchronously gathers work before its needed it copes with poor network connectivity very well so it doesn't often need to even use it. Also note that super high efficiency benefits the pool server by decreasing the number of getworks it asks for, but it does not benefit the person mining if they are already at 100% utilisation since you get paid according to how much work you do. Since cgminer basically uses rolltime only when it *might* have dropped utilisation, but it keeps utilisation high at all times, there is no advantage to using it more. You can tell when cgminer has started doing it with this message:

Server not providing work fast enough, generating work locally

and when it stops doing it the message follows:

Resumed retrieving work from server

Wow. Cgminer has been coming along nicely!

Any plans for pool load balancing / redundancy?   Diablominer has load balancing, poclbm has failover. Both are nice for different reasons.

Load balancing is good because mining against multiple pools concurrently lowers your variance, reduces the concentration of hashing power to large pools, better tolerance to TCP head of line blocking (e.g. when a connection loses some packets and ends up stalled for a long time), and loses less time during a failure (because you already have current work for multiple pools).  The additional pool load is justified by the fact that the miner is pooling multiple cards (where older cards were one card one connection), and efficiency enhancements like ntime rolling.

Failover is good because all options are not always equal:  I might strictly prefer to mine for a medium sized cheating resistant pool, assuming its up and working correctly, and failing that mine for some large proportional pool,  and failing that mine solo, because solo is better than sitting idle or generating many minute stale work which is likely to be rejected by any current pool even if it isn't for an already orphaned block.

The obvious way to configure for both of these would bet to have lists of lists of RPC URLs:

{
  {"http://pool1/","http://pool2", ...},
  { "http://localhost..."}
}

and some timeout setting to consider a group failed when there hasn't been an updated prev or merkle root in N seconds or if all the TCP connections are closed, beyond with it fails to the next group.

Cool, thanks for using my modified kernel as the basic kernel for your miner . Remember guys, if you like it donate a few Bitcents .

Dia

Does cgminer support X-Roll-NTime?  Since my efficiency was below 100%, I'm guessing not.

Would be nice if the windows version actually worked
It wont even connect to slushes pool

error can't rewind ... say what !

Updated tree and first "Release" version.

Source:
http://ck.kolivas.org/apps/cgminer-1.2.3.tar.bz2

Windows binary:
http://ck.kolivas.org/apps/cgminer-1.2.3-win32.zip

Major change is a new improved phatk kernel based on
http://forum.bitcoin.org/index.php?topic=25860.0

It's worth a tiny improvement in throughput, but as I understand it if you underclock your memory a lot (for heat reasons) you not see much improvement. It varies from card to card but don't expect magic increases in Mhash.

Other changes include finally supporting make install and make distdir should work from the git tree. Two other potential crashing bugs were also fixed.

Thanks to those who have donated

Good point.

Updated tree: Fixed the debug output by using locking around any screen updates. Made quiet mode not enable curses at all. Changed longpoll calls to not use POST.

That would be nice and probably save some watts.

Though shouldnt -q do that? It doesnt update anything on the screen at all..

Would you like a no-curses version as an option? It's using hardly any CPU here but clearly it will use more CPU with curses than a basic printf.

Verbosity has no impact on CPU usage and is IMO, quite high.

CPU: G620

My AMD x4 640 has <1% usage.