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

It's not enabled...

Try reconfiguring Xorg
sudo aticonfig --adapter=all -f --initial

I'm trying to mine litecoins under linux with a 6950 and a 6990. The 6950 works fine but the 6990 isn't detected. I tried it with and without the crossfire cable but the result is the same:


Any ideas?

Thank you for the detailed explanation! It's not really a big concern, as I've really just been fooling around with it for the past day or two. It would be nice to have it even split to all 5 pools, but it's not a critical component.

Queued work and efficiency mean pretty much nothing now, especially with stratum. It's simply a function of how often the pool is sending you a new template and there is no "standard" for that, some do 30 seconds, some 60 etc. The more often they're sending you a template, then potentially the more transactions you're supporting if the pool is adding all the latest transactions every 30 seconds instead of 60, but even that equation isn't clear with bitcoind not necessarily simply taking all transactions. The work queueing in cgminer is a fairly complex machine designed for optimally keeping devices as busy as possible, and trying to balance things between pools for whatever reason is a distant second priority. Trying to improve the latter will come at the price of the former. This will become far more acute with ASIC hashrates than it is at the moment with GPUs, and it clearly works with avalon running ~66 or 88 GH off a very low power CPU with cgminer. I doubt the equivalent of the CPU hardware in the Avalon could handle a 1.5TH minirig when they come out but a regular desktop/laptop/tablet CPU will easily do so, and cgminer is heavily multithreaded so multicore/mulithread CPUs (which are everywhere in these devices) are advantageous.

Thanks, I'll give the miner.php a try.

I've also noticed the same thing as you: Ozcoin gets far less shares than the other 4 pools. Of the 5 pools I'm testing this on, 3 of them are right around the same amount of accepted shares, Ozcoin is about 15-20% lower, and then EMC is about 15-20% higher. Ozcoin has a high Queued work count with a low efficiency %, and EMC has a high Queued work count with a high efficiency %. So this means Ozcoin is sending new work more often, and EMC is sending work less often? Yet somehow that ends up with fewer/more shares? Someone smarter than me wanna explain this?

Now this is also a single 7970 split up between 5 pools, so they're each getting a tiny little chunk.

Not sure if you already know this but....

in cgminer-2.10.5 the config script requires libcurl-7.18.2 but libcurl-7.25+ is actually required It looks like you missed a message or test

Couldn't you cut down on rejects by having cgminer immediately start working on shares for the pool that sends out new work before the other ones?

When spreading shares out to multiple pools it is guaranteed your reject rate will be higher because every pool has a slightly different time they see the block change. How to best manage that is a point of contention. It was far more useful for shares to "leak" with the old getwork protocol because it would be common one pool could not keep up the work for all miners especially across longpoll. I do recall one lucky user in this thread had shares leak to his local bitcoind and actually found a block with one of those! Since stratum (and gbt) use completely local work generation, there is not much point to this any more.

If you use miner.php, you can see how many shares you've sent to each pool really easily.

I tried balancing 3 servers (us.ozco.in, stratum.ozco.in and MtRed's stratum server) and got decent results, but my reject rate was slightly higher across the board; about 0.2% rather than 0.1%. MtRed was also getting quite a bit more shares (hence why I added 2 Ozcoin servers), probably something to do with the server only sending out new work about once a minute. I wonder if there's really any benefits to balancing DGM and PPS...

So I'm testing it out by running my 7970 on 5 stratum pools using balance. At the top, its says "Connected to multiple pools without LP", which I take to be a good thing, as all the pools are using Stratum. My question is how to look at the number of accepted shares for each individual pool, without pressing "P -> I -> 0" and going on thru the line. Is there a pool summary page where I can compare the submitted shares too all pools?

I build cgminer 2.10.4 on my MK802, which is also an ARM CPU. It's exactly the same steps as building from source on almost any other version of Linux, and the steps are in the CGMiner readme if you need a refresher.

So i can start this as if i were on any linux machine? In Pshep's cgminer port the program runs as a service and thats why I'm asking ?

Ok, thanks. First time I'm going to compile something for an AllWinner A10 (ARMv7 apparently). Does it differ a lot from a 32bit x86 compile process?

There are no 32 bit linux binaries, so yes you do have to compile them.

./cgminer-2.10.5 --no-submit-stale --api-listen --api-allow W:127.0.0.1,R:192.168.0.0/24

Hello,
I have a Hackberry (ARMHF) Allwinner A10 dev board.
Where can I find the 32bit binaries of cgminer? Do I have to compile them for ubuntu 12.10, likely 32bit, if these don't exist?

Someone here that has cgminer on a ddwrt?

I'm unable how to start cgminer with the flags "--api-listen and --api-network".
Normal starting procedure looks like this "service cgminer start"....

Where do i put these flags?

+1 

That was great writing Con. I now understand some things I've been seeing from time to time.

Perfectly clear. Thanks one million.

Stratum always starts at diff 1, even if you have asked for a different diff. So cgminer starts sending diff 1 shares until it is told to change diffs, and even then, if there are any shares that it has already found, it still submits them. The stratum protocol specifies that these should be valid shares and accepted if submitted with the original work item. Now cgminer does NOT log shares submitted at the time they're submitted, unless you're in verbose mode. It only shows the response from pool when it accepts or rejects the share submitted. Otherwise it would have to show them twice. Instead it keeps a database of shares submitted and waits till it gets a response before saying accepted or rejected. If the share has been submitted, and the pool never responds to it, you will never see any record of it. If a connection is dropped, cgminer discards all recollection of old shares submitted and considers them lost, because most of those shares will be lost somewhere in networking, and the pool will not accept shares from old connections until stratum develops a robust resume mechanism (which I'm trying to push forward at the moment). If any shares come back from the old connection as accepted or rejected, cgminer will call them "untracked shares" because it will have discarded any record of them.