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

[ISAWHIM]

The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)

The difficulty adjusts every 2,016 blocks.  According to Bitcoin Watch we still have 891 to go.

And it hasn't adjusted since cgminer version 3.2.0 was created, which everyone is now using... Has been more than 5 days... But who cares about BTC, that is for the ASIC manufactures now. You have to look at a graph of difficulty, not just the next target. Compared to the "mined coins" and "network hashing power."

I just downgraded to 3.2.0 on win7-64bit, and it is showing 50% rejects of valids, so it is on par with 3.2.0 and 3.2.1 running on vista-32bit. Thus, it is "partially" a 32/64 bit issue, and something that absolutely changed from 3.1.0 to 3.2.0 and got worse for 64-bit systems on 3.2.1...

Perhaps you "mistakenly" included one of the linux files/code in the compile for windows. (Which would be a slight issue, if it was something like using a linux INT vs a windows INT, or LONG, or something like byte-order... that might be specific to linux. or a terminator chr(13)chr(10) which is a windows only thing, in code {CRLF} not just {CR} or {LF} like linux allows, or a TAB where there should be a SPACE in a quoted comparison, which would not show if the TAB in code was at the SPACE mark. Something small, I am sure... But something from those versions that changed for validity submission/checking, related to sending over HTTP/TCP.)

NOTE: Actual win7-64bit results running cgminer 3.2.0 (the downgrade), best run on "Fastcoins" = 60% valids accepted. (Better, but not the 85% I was getting with cgminer 3.1.0. Way better than the 78% rejects of valids using 3.2.1 on win7-64bit. Vista 32-bit is still at 50% rejects of valids on the downgrade.) Difficulty is 7.56K, which is 0.115333 in scrypt-mining. That is a 12 seconds block target. Retargets about every hour. Good to test on.

If 3.1.0 still worked on any of the wallets, for solo-mining, I would downgrade again... but 3.1.0 is essentially dead in the water for me.

[1714134332]

1714134332

[1714134332]

1714134332

[1714134332]

1714134332

[Mobius]

r u on p2pool?

[ISAWHIM]

r u on p2pool?

I am solo-mining with my army of GPUs. I am not in any pools at the moment... I avoid pools, due to the many "issues" that more-often-than-not, lead to losses. (Some losses are acceptable, but when they constantly "cut your connection", to make you "loose shares", and "estimate poorly", and "drop actual earned shares"... yet they mine themselves too... thus gain both ways. I loose faith. Sadly, it is the smaller pools that get the short end of the stick, trying to help-out those who just can't solo-mine anything.)

All pools as of late, have had the same results. (Not bitcoin pools, because those blocks are so far away, and obviously, low diffs don't even matter to bitcoins. However, shares have seen similar results, if you set shares to 4K-20K... but no-one uses shares that high.)

Easy to see it visually than to try to explain.
http://www.coinwarz.com/cryptocurrency

You can see the results in the graphs here, related to diff issues... diffs should be going up, not down... they do go up, when people stop mining. They stop, because the diff drops, and less coins are produced, due to the above stated issue of "more rejects of valids"... Rejecting 140K submits with diff of 30K, withe no other block in range. Thus, not rejected sue to being "close" or "too late to submit"... Just flat out rejected.

I even have one with a big fat "?" in my list of transactions... lol... even the wallet is not sure what to think of it! (Eg, not rejected, not an orphan, just a "?" not sure what it is. Valid when found, valid when submitted, but "?" in my wallet, and the network, I assume.)

[freshzive]

Weird, I got cgminer3.2.1 to compile the first time in OS X 10.8. Plugged in my USB2 hub with 7 Block erupters and they are mining a way with 0 issues, even without adding --hotplug 0. Rejects are gone that I was seeing with 3.1.1 on Ubuntu as well.

So, it seems whatever was causing my devices to disconnect and become "SICK" on Ubuntu isn't an issue on my mac. Strange.

Glad it's working now though

[Xmansk]

Maybe it is somewhere here in this thread but there are so many posts that i would not find it in a day, so I will just ask.

Why there is so big difference in rejected ratio in CGMiner mining with intensity 13 and with intensity 20? I am mining DigitalCoin (crypt, 20s block time)
When i mine with I 13 my rejection ratio is ~0.5% @ 540kh/s per card.
When i mine with I 20 my rejection ratio is ~7.5% @ 700kh/s per card.

Why is there so big difference? It is caused by CGMiner, by Pool, by connection, ... ? Is there a way to lower rejection ratio with intensity 20?

[-ck]

Maybe it is somewhere here in this thread but there are so many posts that i would not find it in a day, so I will just ask.

Why there is so big difference in rejected ratio in CGMiner mining with intensity 13 and with intensity 20? I am mining DigitalCoin (crypt, 20s block time)
When i mine with I 13 my rejection ratio is ~0.5% @ 540kh/s per card.
When i mine with I 20 my rejection ratio is ~7.5% @ 700kh/s per card.

Why is there so big difference? It is caused by CGMiner, by Pool, by connection, ... ? Is there a way to lower rejection ratio with intensity 20?

At intensity 20 it takes forever for your GPU to return its results, so by the time it has returned them, fast chain changing altcoins are all onto their next block. This also explains why orphans are extremely common with fast block coins and why ultimately, they're crap since such a system provides no extra actual security (or fast confirmations since you can't trust any confirmations), just more chain fights.

[Wisher]

plz, help, how to run the autostart cgminer in ubuntu.

[Xmansk]

Maybe it is somewhere here in this thread but there are so many posts that i would not find it in a day, so I will just ask.

Why there is so big difference in rejected ratio in CGMiner mining with intensity 13 and with intensity 20? I am mining DigitalCoin (crypt, 20s block time)
When i mine with I 13 my rejection ratio is ~0.5% @ 540kh/s per card.
When i mine with I 20 my rejection ratio is ~7.5% @ 700kh/s per card.

Why is there so big difference? It is caused by CGMiner, by Pool, by connection, ... ? Is there a way to lower rejection ratio with intensity 20?

At intensity 20 it takes forever for your GPU to return its results, so by the time it has returned them, fast chain changing altcoins are all onto their next block. This also explains why orphans are extremely common with fast block coins and why ultimately, they're crap since such a system provides no extra actual security (or fast confirmations since you can't trust any confirmations), just more chain fights.

And why it takes forever? Why with I 13 it does not take forever? What is different?

[-ck]

Maybe it is somewhere here in this thread but there are so many posts that i would not find it in a day, so I will just ask.

Why there is so big difference in rejected ratio in CGMiner mining with intensity 13 and with intensity 20? I am mining DigitalCoin (crypt, 20s block time)
When i mine with I 13 my rejection ratio is ~0.5% @ 540kh/s per card.
When i mine with I 20 my rejection ratio is ~7.5% @ 700kh/s per card.

Why is there so big difference? It is caused by CGMiner, by Pool, by connection, ... ? Is there a way to lower rejection ratio with intensity 20?

At intensity 20 it takes forever for your GPU to return its results, so by the time it has returned them, fast chain changing altcoins are all onto their next block. This also explains why orphans are extremely common with fast block coins and why ultimately, they're crap since such a system provides no extra actual security (or fast confirmations since you can't trust any confirmations), just more chain fights.

And why it takes forever? Why with I 13 it does not take forever? What is different?

...you're turning the intensity up meaning your handing the GPU many many times more work. GPUs take work, work on it for a while and return results at the end, they're nothing like CPUs. Going up in intensity you're giving it many many many times more work (it's an exponential function to intensity).

[daemondazz]

Does anything need to be done with 3.1.1 for the USB Erruptor?

Code:

root@bitcoin-miner1:~# cgminer -V
cgminer 3.1.1
root@bitcoin-miner1:~# uname -a
Linux bitcoin-miner1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
root@bitcoin-miner1:~# cgminer -n
 [2013-06-12 20:04:10] CL Platform 0 vendor: Advanced Micro Devices, Inc.
 [2013-06-12 20:04:10] CL Platform 0 name: AMD Accelerated Parallel Processing
 [2013-06-12 20:04:10] CL Platform 0 version: OpenCL 1.2 AMD-APP (1016.4)
 [2013-06-12 20:04:10] Platform 0 devices: 1
 [2013-06-12 20:04:10]  0       Tahiti
 [2013-06-12 20:04:10] GPU 0 AMD Radeon HD 7900 Series  hardware monitoring enabled
 [2013-06-12 20:04:10] 1 GPU devices max detected
 [2013-06-12 20:04:10] USB all: found 6 devices - listing known devices
 [2013-06-12 20:04:10] No known USB devices
root@bitcoin-miner1:~# ls /dev/ttyUSB0
/dev/ttyUSB0

I'm running with

Code:

/usr/local/bin/cgminer --auto-fan --auto-gpu --syslog -T --gpu-engine 1100 --gpu-memdiff -150 -I 10 --icarus-options 115200:1:1 --icarus-timing 3.0=80 -o stratum+tcp://cryptominer.org:9332 -u xxxx -p xxxx

The machine also has a Gigabyte 9750 in it which is merrily hashing away.


EDIT: Nevermind, I missed the "-S /dev/ttyUSB0" - It appears to be working now.

[os2sam]

When I press Q to quit CGMiner 3.2.1 most of the time it crash's.  Once out of 3 or 4 times does it display the summary when pressing Q.

Win7 32bit running cgminer-nogpu.
Thanks,
Sam

[os2sam]

I'm trying to disable two AMU's, out of 4 total, in each CGMiner session.

"-d 0 -d 1 --remove-disabled" in the first session works fine.
"-d 2 -d 3 --remove-disabled" in the second session does not work.

when I run CGMiner-nogpu -n it says "failed to open, err -3"

It appears that you intend for CGMiner to be able to do this and I would like to run two sessions for two different pools.
Thanks,
Sam

[Xmansk]

And why it takes forever? Why with I 13 it does not take forever? What is different?

...you're turning the intensity up meaning your handing the GPU many many times more work. GPUs take work, work on it for a while and return results at the end, they're nothing like CPUs. Going up in intensity you're giving it many many many times more work (it's an exponential function to intensity).

So basically my higher hashrate at intensity 20 is caused because GPU use all availiabe resources to solve work so it solve more work, but it does not do it faster? If so, I should try to find highest possible hashrate at intensity 13.

[os2sam]

And why it takes forever? Why with I 13 it does not take forever? What is different?

...you're turning the intensity up meaning your handing the GPU many many times more work. GPUs take work, work on it for a while and return results at the end, they're nothing like CPUs. Going up in intensity you're giving it many many many times more work (it's an exponential function to intensity).

So basically my higher hashrate at intensity 20 is caused because GPU use all availiabe resources to solve work so it solve more work, but it does not do it faster? If so, I should try to find highest possible hashrate at intensity 13.

You probably should use trial and error find the intensity that gives you the best combination of hash rate, low error rate and best U:/WU:

[-ck]

I'm trying to disable two AMU's, out of 4 total, in each CGMiner session.

"-d 0 -d 1 --remove-disabled" in the first session works fine.
"-d 2 -d 3 --remove-disabled" in the second session does not work.

when I run CGMiner-nogpu -n it says "failed to open, err -3"

It appears that you intend for CGMiner to be able to do this and I would like to run two sessions for two different pools.
Thanks,
Sam

The --usb command gives you finer control over this. The --device command only takes one set of values now (-d 0-1 instead of -d 0 -d 1) and only works for usb devices since version 3.2.1, and it is a coarse command.

[os2sam]

I'm trying to disable two AMU's, out of 4 total, in each CGMiner session.

"-d 0 -d 1 --remove-disabled" in the first session works fine.
"-d 2 -d 3 --remove-disabled" in the second session does not work.

when I run CGMiner-nogpu -n it says "failed to open, err -3"

It appears that you intend for CGMiner to be able to do this and I would like to run two sessions for two different pools.
Thanks,
Sam

The --usb command gives you finer control over this. The --device command only takes one set of values now (-d 0-1 instead of -d 0 -d 1) and only works for usb devices since version 3.2.1, and it is a coarse command.

Ah, in other words RTFM .  I found the section in the readme and I'll give it a whirl tonight.
Thanks,
Sam

[os2sam]

The --usb command gives you finer control over this. The --device command only takes one set of values now (-d 0-1 instead of -d 0 -d 1) and only works for usb devices since version 3.2.1, and it is a coarse command.

I went ahead and tried it now.

"--usb 5:1,5:2" in one instance
"--usb 3:1,3:2" in the other instance

Both hashing away just fine.  Now I can more objectively compare pools.
Thanks,
Sam

[Tamis]

Are there any reasons to update from 3.1.1 to 3.2.1 if you are only using gpus ?

[bitcoindaddy]

The --usb command gives you finer control over this. The --device command only takes one set of values now (-d 0-1 instead of -d 0 -d 1) and only works for usb devices since version 3.2.1, and it is a coarse command.

I went ahead and tried it now.

"--usb 5:1,5:2" in one instance
"--usb 3:1,3:2" in the other instance

Both hashing away just fine.  Now I can more objectively compare pools.
Thanks,
Sam

Is that all that is necessary to run multiple instances or is there other "secret sauce"?  What do  the number mean?

[turtle83]

The --usb command gives you finer control over this. The --device command only takes one set of values now (-d 0-1 instead of -d 0 -d 1) and only works for usb devices since version 3.2.1, and it is a coarse command.

I went ahead and tried it now.

"--usb 5:1,5:2" in one instance
"--usb 3:1,3:2" in the other instance

Both hashing away just fine.  Now I can more objectively compare pools.
Thanks,
Sam

Is that all that is necessary to run multiple instances or is there other "secret sauce"?  What do  the number mean?

i believe the number is bus:device.

so "5:1" means device 1 on bus 5. on linux lsusb shows you the bus and device number for each usb device.