-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 12, 2011, 01:44:53 PM |
|
Updated tree and first "Release" version. Source: http://ck.kolivas.org/apps/cgminer-1.2.3.tar.bz2Windows binary: http://ck.kolivas.org/apps/cgminer-1.2.3-win32.zipMajor change is a new improved phatk kernel based on http://forum.bitcoin.org/index.php?topic=25860.0It'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
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
RobertRibbeck
|
|
July 12, 2011, 03:55:38 PM |
|
Would be nice if the windows version actually worked It wont even connect to slushes pool error can't rewind ... say what !
|
Please "Clear your browser cookies" then use http://bitcoinpyramid.com/r/3360 to Join BitCoin Pyramid use my referral & I'll refund a % of your first deposit back to your account Deposit .5 BTC or more and I'll give back 50% of what I receive First Deposit of 1 BTC will get 75% of what I get back
|
|
|
twmz
|
|
July 12, 2011, 04:39:30 PM |
|
Does cgminer support X-Roll-NTime? Since my efficiency was below 100%, I'm guessing not.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
Diapolo
|
|
July 12, 2011, 05:53:16 PM |
|
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
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8702
|
|
July 12, 2011, 08:19:19 PM |
|
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.
|
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 12, 2011, 09:47:42 PM |
|
Does cgminer support X-Roll-NTime? Since my efficiency was below 100%, I'm guessing not.
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
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 12, 2011, 09:50:47 PM |
|
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.
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 12, 2011, 10:20:20 PM |
|
Would be nice if the windows version actually worked It wont even connect to slushes pool
error can't rewind ... say what !
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?
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
twmz
|
|
July 13, 2011, 12:08:54 AM |
|
Does cgminer support X-Roll-NTime? Since my efficiency was below 100%, I'm guessing not.
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 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.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
twmz
|
|
July 13, 2011, 12:12:28 AM |
|
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.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 13, 2011, 12:33:17 AM |
|
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 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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 13, 2011, 12:35:28 AM |
|
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'm really not sure how it would cope with that. I doubt it will handle it gracefully.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
twmz
|
|
July 13, 2011, 12:43:17 AM |
|
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.
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.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
twmz
|
|
July 13, 2011, 12:48:33 AM |
|
I'm really not sure how it would cope with that. I doubt it will handle it gracefully.
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!
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 13, 2011, 02:26:00 AM |
|
Updated source tree and new source version: http://ck.kolivas.org/apps/cgminer-1.2.4.tar.bz2Changes 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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 13, 2011, 03:04:42 AM |
|
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
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
|