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

[kano]

Since the miner in now doing all the work except counting shares, if I were to implement such a protocol I would include a miner option to specify a fee in the coinbase to be paid directly to the miner - and probably also a donation option to the miner devs too - since the miner is now doing all the work of the pool other than counting shares.

This moves the miner into being a partial bitcoind that must fully process transactions, block changes, orphan blocks, orphan transactions, generate merkle trees and decide about transaction worthyness to be included in blocks and the risks involved with that also.

I don't think you understand the protocol entirely.  The pool is still doing ALL of the bitcoind work.  It is creating the merkle branch list (picking the transactions and building the block essentially).  All it's doing is allowing the miner to adjust a piece of the coinbase transaction, which creates a new merkleroot, thus allowing it to continue hashing without interacting with the pool server once it runs out of nonce space or ntime rolling.

Ah OK, so you are dramatically increasing the amount of data sent - whenever there is a need to send it - the diagonal line of the merkle tree?

As I mentioned - wouldn't the amount of getworks still not be insignificant?
You want miners to change their work whenever a txn change is appropriate (new transactions or high fee transactions)
Otherwise the result of this will be to slow down transaction confirm times - transactions will increase their chance of missing going into the current block?

So it's either increase transaction times, or dramatically increase the amount of data sent in fewer getworks?

[1714006505]

1714006505

[1714006505]

1714006505

[1714006505]

1714006505

[eleuthria]

Ah OK, so you are dramatically increasing the amount of data sent - whenever there is a need to send it - the diagonal line of the merkle tree?

As I mentioned - wouldn't the amount of getworks still not be insignificant?
You want miners to change their work whenever a txn change is appropriate (new transactions or high fee transactions)
Otherwise the result of this will be to slow down transaction confirm times - transactions will increase their chance of missing going into the current block?

So it's either increase transaction times, or dramatically increase the amount of data sent in fewer gerworks?

By default, my pool sends new work once every 60 seconds.  That is not significantly different than how often many miners get new work (especially when nTime rolling is involved).

They payload of new work is ~1 KB.  It's sent over an always-open asynchronous TCP connection.  No HTTP overhead, no opening new connections either.  This is roughly equivalent to a single getwork today.  That 1 KB is enough to include ~1,000 transactions (which only requires 10 merklebranches to be sent), and provides enough work 18 Exahash/s.  Add an extra 65 bytes to the work push to double that to 1,025-2,047 transactions.  Another 65 for 2,048-4,096.  As you can see, this means that even at astronomical network size where a block would contain hundreds of thousands of transactions, the payload for the mining protocol will never exceed 2 KB.

Work submissions take only a few bytes.  The new protocol drastically reduces bandwith to the point that a 56k modem provides enough bandwidth to run a mining farm more than 1 billion times the size of the current network.

Additionally, the 18 Exahash uses a local ExtraNonce adjustment size of 4 bytes.  That can be increased to 8 bytes quite easily (the protocol defines the ExtraNonce size as variable, and provided by the pool server).  If the ExtraNonce size was increased to 8 bytes, you can run 4.2 billion times more work per push, and the only increase in bandwidth is it will require 8 more bytes to submit a share to the server.

[slush]

You still don't fully understand it. Actually pool send much less amount of data than with getwork. You should really read "real world example" from the Stratum documentation page. If you're miner developer, you'll be surely familiar with the howto.

The new protocol really don't change any transaction confirmation times. Nothing changes in this area. Protocol just optimize the overhead on every level and give the miner great oportunity to iterate not only over ntime and nonce, but also over extranonce. And with cost of only one double-sha256 hash per new coinbase. Isn't that great? :-)

Ah OK, so you are dramatically increasing the amount of data sent - whenever there is a need to send it - the diagonal line of the merkle tree?

As I mentioned - wouldn't the amount of getworks still not be insignificant?
You want miners to change their work whenever a txn change is appropriate (new transactions or high fee transactions)
Otherwise the result of this will be to slow down transaction confirm times - transactions will increase their chance of missing going into the current block?

So it's either increase transaction times, or dramatically increase the amount of data sent in fewer getworks?

[TCPC]

I'm having a problem trying out scrypt on cgminer.  I seem to have got my settings OK for the most part other than a little performance tweaking, but the main problem I ran into was this. 
CGMiner is reporting that my 5830 card is currently hashing at 150 Kh/s but on litecoinpool.org it was only reporting about 10 Kh/s.  It doesn't seem to be an issue with rejects or HW errors as I am getting very few rejects and no HW errors. 
So I thought maybe it was something with litecoin pool.  So I setup a local P2Pool server and pointed the rig to that, but I am still getting a very similar issue.  P2Pool is only reporting me hashing at 25509H/s.  I read through a lot of the posts in this thread and the CGMiner Scrypt thread, but could not find anyone having a similar issue.  Anyone have any ideas what my problem might be?

[ydenys]

blabla

I can think of 3 "solutions" to your cannot be managed/must be managed card combo. So here goes in increasing order of difficulty.

1. Get rid the faulty card. Maybe replace it with something that still works.
2. run 2 instances of CGMiner; one with "-d 1" and the other with "-d 0 -d 2 --auto-fan --auto-gpu  --your-other-options"
3. Adjust the bios defaults on your cards so they default to what you want them to run at. Don't specify any GPU or fan speeds when you start CGMiner so they all run at their modified defaults and let the driver control the fans.

Good luck.

Just to say 'thank you'.

Running 2 instances of cgminer (the one with healthy cards is a step higher priority and amended core/memory/fan, the faulty one on default on its own, low aggression). Restart-safe, even no pause needed in autoexe and no fiddling with cards’ bioses to oc healthy cards. Pretty sure the ‘faulty’ card will be chugging till armageddon/appearance of dreaded ASICs

[Jack1Rip1BurnIt]

The "download all files here" link is not working on the first page. Ready to give CGMiner a try but no download

[kano]

The "download all files here" link is not working on the first page. Ready to give CGMiner a try but no download

ckolivas is absent as per his post back here:
https://bitcointalk.org/index.php?topic=28402.msg1156587#msg1156587

Yes it seems his web site is dead at the moment.
I've put his release files in my git downloads:
https://github.com/kanoi/cgminer/downloads

The release files are:
cgminer-2.7.5-win32.7z — cgminer2.7.5 ckolivas release file: windows 32bit (mingw)
cgminer-2.7.5-x86_64-built.tar.bz2 — cgminer2.7.5 ckolivas release file: linux x86_64 binary release
ckolivas web site is working again

I haven't put the source file since his git is working.

ALSO

I've added more changes to my git master and added them to the pull to ckolivas git:
https://github.com/ckolivas/cgminer/pull/310

22 commits (plus a version number commit so anyone running it will see 2.7.5g if they compile the current code that is there right now)

I fixed the (minor) issue that the HW: code was still submitting the bad shares - if anyone noticed that (I know a few did)

I've also modified the pool URL syntax (at someone's request) - to allow each pool to individually specify it's own proxy of any of the proxy types supported by CURL (http, http1.0, socks4, socks5, socks4a, socks5h)

... and a bunch of other changes.

Of course these are just a pull request to ckolivas, so they may or may not end up in cgminer ... but hopefully they all will.

[kano]

It there a Plan to implemet queue and Threats in the API?

At the moment the socket queue is 100 but a single thread.
What are you doing with the API that needs more than that?

Ok i miswrote it.
I dont wont Threat and queue for the API. I want to Set These options over the API like Intensity.

If i Mine with a normal Pool the Standard Setting for these Parameters are ok.

If i Switch to p2pool over the API in an Script, i want to change the Queue And threats too.

Ah OK - Queue, ScanTime and Expiry are certainly no issue to add.
(It currently shows ScanTime, but doesn't let you change it - easy enough to do that)
I'll add them to my list of stuff to be done some time in the future ... or you can prompt me to do it sooner ...
...

OK, my current git source has these 3 now also ... if you compile it, it will now say 2.7.5h
The change: viewing and setting queue, scantime and expiry via the API
... any prompting?

[tnkflx]

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?

[kano]

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?

When I get one to work out how to access them
Someone offered to send me one ... soon I hope

I will then make a standalone CM driver that deals with some/all of the extra CM only stuff.

[tnkflx]

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?

When I get one to work out how to access them
Someone offered to send me one ... soon I hope

I will then make a standalone CM driver that deals with some/all of the extra CM only stuff.

My offer for remote access still stands

[kano]

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?

When I get one to work out how to access them
Someone offered to send me one ... soon I hope

I will then make a standalone CM driver that deals with some/all of the extra CM only stuff.

My offer for remote access still stands

For basic support - useful - for ongoing proper support - not much use.
I've already done the basic support, for free, without having a CM1.

CM1's mine (with the Icarus style bitstreams) and can even get the right timing for the different configurations and different FPGA setups (single or pairs - but the code will allow up to 8 )
Oddly - I did all that without even having access to a CM1 - it was all rather logical how it should work so I wrote the code to make it work.
I think it was the idea of Lancelot that made me want to do it - but I don't have one of them either
But even Lancelot mines with the Icarus code.

'When' I get a CM1 I'll then go to the trouble (as I said above) of writing a specific driver for it based on the Icarus code (they will most likely share code) ... until then, it works, it mines, it's good enough.
(and no I'm not looking for ways to spend my free time on something like that without a CM1 )

... that's the polite version

[iopq]

I switched from 2.5.0 to 2.7.5 and now my dynamic intensity is only 4  it used to oscillate between 4 and 5 in 2.5.0 which is obviously higher

any way to specify "dynamic/aggressive" or something so it raises intensity a lot when nothing is happening (when I'm just starting at the screen) but drops it just as quickly when I watch a video or something like that?

[kano]

I switched from 2.5.0 to 2.7.5 and now my dynamic intensity is only 4   it used to oscillate between 4 and 5 in 2.5.0 which is obviously higher

any way to specify "dynamic/aggressive" or something so it raises intensity a lot when nothing is happening (when I'm just starting at the screen) but drops it just as quickly when I watch a video or something like that?

That's a ckolivas question.
I've never gone near that part of the code - and he's been trying to fix it for a while ...
But ... 4 vs 5 - um - not really that big a deal?

[os2sam]

I switched from 2.5.0 to 2.7.5 and now my dynamic intensity is only 4   it used to oscillate between 4 and 5 in 2.5.0 which is obviously higher

any way to specify "dynamic/aggressive" or something so it raises intensity a lot when nothing is happening (when I'm just starting at the screen) but drops it just as quickly when I watch a video or something like that?

That's a ckolivas question.
I've never gone near that part of the code - and he's been trying to fix it for a while ...
But ... 4 vs 5 - um - not really that big a deal?

Have you tried tweaking dynamic with this?

--gpu-dyninterval <arg> Set the refresh interval in ms for GPUs using dynamic intensity (default: 7)

Sam

[iopq]

I switched from 2.5.0 to 2.7.5 and now my dynamic intensity is only 4   it used to oscillate between 4 and 5 in 2.5.0 which is obviously higher

any way to specify "dynamic/aggressive" or something so it raises intensity a lot when nothing is happening (when I'm just starting at the screen) but drops it just as quickly when I watch a video or something like that?

That's a ckolivas question.
I've never gone near that part of the code - and he's been trying to fix it for a while ...
But ... 4 vs 5 - um - not really that big a deal?

yeah, but I REALLY would want it to be 7 when I'm away from the computer instead
since I'm running p2pool it's on a single thread so the difference in performance is ~15mhash (5%) between 4 and 7

and I can't even tell the difference when just typing right now, but if I watch a video on 7 everything will be sluggish

[Krak]

yeah, but I REALLY would want it to be 7 when I'm away from the computer instead
since I'm running p2pool it's on a single thread so the difference in performance is ~15mhash (5%) between 4 and 7

and I can't even tell the difference when just typing right now, but if I watch a video on 7 everything will be sluggish

I've always found that if you increase the intensity of your display GPU above 6, it starts throttling any other GPUs in your system. So I just leave mine at 6 and it's pretty usable.

[crazyates]

and I can't even tell the difference when just typing right now, but if I watch a video on 7 everything will be sluggish

What card are you using? I got a 7970 on my main computer, and even with I:9, I can watch movies with no issues.

[mdude77]

and I can't even tell the difference when just typing right now, but if I watch a video on 7 everything will be sluggish

What card are you using? I got a 7970 on my main computer, and even with I:9, I can watch movies with no issues.

It depends on the 7970 apparently.  I have an XFX 7970 that would just about anything while mining at I:9.  But I have a Diamond 7970 that freezes if I use it on I:9.

M

[Viceroy]

I have mined for a while and I just downloaded and tried CGMiner for the first time in more than a year.  WOW.  That's all I can say.  Ok, I'll say more... amazing, holy cow, omg, try this thing.  Fast... informative... I hear my fans spinning up....  two seconds to set up, I forgot the port number, added port number, they didn't ask me for port number, I digress ... presto.

Impressive, keep up the good work.  Now I try the linux port...

Not good news.  I get a segmentation fault.

I am running  2.6.18-308.13.1.el5 #1 SMP fully updated
Downloaded and installed AMD SDK 2.7 (wasn't working with 2.4 either)
I get the same core dump that I read about earlier in this thread:


 [2012-09-14 11:52:01] Started cgminer 2.7.5
 [2012-09-14 11:52:01] Loaded configuration file miner.conf
 [2012-09-14 11:52:01] CL Platform 0 vendor: Advanced Micro Devices, Inc.
 [2012-09-14 11:52:01] CL Platform 0 name: AMD Accelerated Parallel Processing
 [2012-09-14 11:52:01] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
 [2012-09-14 11:52:01] Platform 0 devices: 4
 [2012-09-14 11:52:01]  0       Barts
 [2012-09-14 11:52:01]  1       Barts
 [2012-09-14 11:52:01]  2       Barts
 [2012-09-14 11:52:01]  3       Barts
 [2012-09-14 11:52:01] Probing for an alive pool
 [2012-09-14 11:52:01] Testing pool http://pit.deepbit.net:8332
 [2012-09-14 11:52:11] Pool 0 http://pit.deepbit.net:8332 active
 [2012-09-14 11:52:11] Init GPU thread 0 GPU 0 virtual GPU 0
 [2012-09-14 11:52:11] CL Platform vendor: Advanced Micro Devices, Inc.
 [2012-09-14 11:52:11] CL Platform name: AMD Accelerated Parallel Processing
 [2012-09-14 11:52:11] CL Platform version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
 [2012-09-14 11:52:11] List of devices:
 [2012-09-14 11:52:11]  0       Barts
 [2012-09-14 11:52:11]  1       Barts
 [2012-09-14 11:52:11]  2       Barts
 [2012-09-14 11:52:11]  3       Barts
 [2012-09-14 11:52:11] Selected 0: Barts
 [2012-09-14 11:52:11] Long-polling activated for http://pit.deepbit.net:8332/listenChannelSegmentation fault

This also fails with a core dump:   cgminer -k poclbm --benchmark

I did not see a solution in the thread but will continue to look...

fwiw:

python opencl.py
[12:17:35] Python OpenCL Info v0.1
[12:17:35] Python Version: 2.7.1 64bit
[12:17:35] PyOpenCL Path: /usr/local/lib/python2.7/site-packages/pyopencl-2012.1-py2.7-linux-x86_64.egg/pyopencl
[12:17:35] Boost Python Version: Not Found
[12:17:35] PyOpenCL Version: 2012.1
[12:17:35] Listing platforms and devices:
[12:17:35]
[12:17:35] [cl:0] AMD Accelerated Parallel Processing
[12:17:35]        [cl:0:0] Barts
[12:17:35]        [cl:0:1] Barts
[12:17:35]        [cl:0:2] Barts
[12:17:35]        [cl:0:3] Barts
[12:17:35]        [cl:0:4] AMD Sempron(tm) 140 Processor
[12:17:35]
[12:17:35] This program will exit in 300 seconds...