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

Ah, in other words RTFM .  I found the section in the readme and I'll give it a whirl tonight.
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.

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:

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.

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

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

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


I'm running with


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.

...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).

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

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

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.

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?

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

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.)

r u on p2pool?

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.

You might want to lay off the caffeine or whatever else your sipping on.

http://allchains.info/ shows 18M in ~5 days.

As os2sam said:
15605632.68129 | Next Diff in 889 blocks | Estimated Change: 20.3644% in 4d 21h 56m 38s

All looks fine to me.

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

So that may confirm it is a TCP thing... (Delivery)... Since stratum is a separate TCP controller. (Eg data not being "packed right, loosing data, or clipping due to "MTU transmission limits reached". Or a missing terminator or terminator that is being "seen" as part of the submitted data, thus, corrupting the valid, making it look invalid.)

However, even pools with stratum are facing this issue. (They are assuming it is the pool-program, but I have confirmed it is a wallet/miner issue, through every single coin, and the difficulty charts confirm it. 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)