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

[ancow]

You should probably search the thread on the difference between simple failover and --failover-only; I'll just quickly mention that simple failover gets work from backup pools when the queue runs low where --failover-only only gets work from backup pools when the primary pool fails. This means that --failover-only will probably stop mining for a short time when your primary pool goes down.

[1715051615]

1715051615

[1715051615]

1715051615

[1715051615]

1715051615

[1715051615]

1715051615

[1715051615]

1715051615

[stevegee58]

I've heard some complaints on abcpool's thread about getting messages "pool not providing work fast enough".  I've seen this error myself occasionally.  I figured maybe abcpool is slower than btcguild so I set up an experiment:

I shortened my list from 4 to 2 so now it's abcpool and btcguild and made abcpool the primary.  I seem to be mining on both roughly equally.
I switched the pools so that btcguild is primary and re-ran.  Same result: roughly equal mining on both pools.

[os2sam]

any magnitude rig will be kept solidly busy

What is a "magnitude rig"?

New pool strategy: Balance.
--balance           Change multipool strategy from failover to even share balance
This is to differentiate itself from the existing pool strategy, Load balance:
--load-balance      Change multipool strategy from failover to efficiency based balance

Now I finally know what load balance means and understand why I never got balanced shares across pools/servers.  Thanks for the clarification.

the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy.

What exactly is "rolltime"?

Thanks,
Sam

[ancow]

I shortened my list from 4 to 2 so now it's abcpool and btcguild and made abcpool the primary.  I seem to be mining on both roughly equally.
I switched the pools so that btcguild is primary and re-ran.  Same result: roughly equal mining on both pools.

On my setup (debian testing, cgminer compiled from git) my primary pool gets ~9/10 shares and the rest are distributed among the backup pools. This is while the heat is making the router I'm connected to act up, so the network is in generally bad shape from my point of view. IOW, even though some of the getworks get dropped, only about 10% of the shares go to backup pools.
It might be a good idea to investigate whether your setup isn't somehow problematic...

[TheHarbinger]

Still getting intensity pegging down to -10 on dynamic threads on win 7 x64.  At the same time, when it drops to -10, cgminer starts eating up a whole core of CPU power.  

This change happened sometime after 2.6.1.  Probably related to to the change in how cgminer handles dynamic intensity that was in 2.6.5, not 100% sure though since my update path was 2.6.1, 2.6.5, 2.7.0.  First saw it in 2.6.5.  Does not happen in 2.6.1.

Any GPU set to dynamic intensity will eventually peg to -10.  Sometimes very shortly after starting, sometimes after running for a while.  I have not yet been able to figure out what the trigger is.

Tested with a clean copy of 2.7.0 with no prefs file after a cold system reboot.

[farfie]

What is a "magnitude rig"?

He means any magnitude (power) of rig (any device which mines bitcoins in our case) will be kept busy with work. Trying to reduce time with no work in other words.

[mdude77]

New release - 2.7.0, August 18th 2012

First time I've upgraded since 2.5.4 I think.

Everything is working as advertised.

Three things I noticed that I thought I'd mention:

- On both my miners, one with 4 GPUs, and one with 3, initially on startup the highest number one (lowest on the list) shows a massive amount of work done compared to the others, like 10x as much.  They eventually balance out, but on startup it is unbalanced.

- Failover is working much better.  I run two copies of p2pool on two different machines for backup purposes.  The backup would almost always get a very small amount of work from the miners.  Now the backup is getting zero, like its supposed to.

- Just for fun I tried changing the intensity to dynamic.  I normally run it at 8 for my 7970s.  Every GPU I tried it on, cgminer would change it to 7 and it wouldn't move from there.  Wouldn't say D, it would say 7.  I ended up changing them all to 9, which before caused problems, but now it works and increases output.  10 just jacks up CPU usage with no perceptible increase in hash rate.

As usual, great work.  I just send 2 long over due coins your way..

Regards,

M.

[Zenitur]

Error when CGMINER compiling. Versions 2.3.4-2.3.6. Versions 2.3.1-2.3.3 compiles fine.

...

Thanks for fix of my bug in Cgminer 2.4.0! Forgot to tell this before.

[kano]

...

the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy.

What exactly is "rolltime"?

Thanks,
Sam

The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bitcointalk.org/index.php?topic=89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

[crazyates]

...

the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy.

What exactly is "rolltime"?

Thanks,
Sam

The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bitcointalk.org/index.php?topic=89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

Very interesting. Thank you for explaining that!

[-ck]

New release - 2.7.0, August 18th 2012

First time I've upgraded since 2.5.4 I think.

Everything is working as advertised.

Three things I noticed that I thought I'd mention:

- On both my miners, one with 4 GPUs, and one with 3, initially on startup the highest number one (lowest on the list) shows a massive amount of work done compared to the others, like 10x as much.  They eventually balance out, but on startup it is unbalanced.

- Failover is working much better.  I run two copies of p2pool on two different machines for backup purposes.  The backup would almost always get a very small amount of work from the miners.  Now the backup is getting zero, like its supposed to.

- Just for fun I tried changing the intensity to dynamic.  I normally run it at 8 for my 7970s.  Every GPU I tried it on, cgminer would change it to 7 and it wouldn't move from there.  Wouldn't say D, it would say 7.  I ended up changing them all to 9, which before caused problems, but now it works and increases output.  10 just jacks up CPU usage with no perceptible increase in hash rate.

As usual, great work.  I just send 2 long over due coins your way..

Thanks for feedback and much more for the donation

Startup GPU difference is just luck variance showing up. Perfectly normal.

Glad to hear failover works better.

Dynamic will show the "chosen" current intensity, which for an awesome 7970 works out to about 7. Perfectly normal. (shame it only works properly on linux it seems).

[farfie]

The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bitcointalk.org/index.php?topic=89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

Sort of related, I had a different question - is it possible for you guys to do the opposite of how you will grab long poll from a different pool that you have set up if the primary pool does not support it, so that you could add a local bitcoin client to check for blocks that could possibly find a new one before long poll does?

There's no way I'd be the first to think of this, so I just assumed it's not doable, or perhaps not worth doing? Just curious I guess.

edit: typo

[kano]

...
Sort of related, I had a different question - is it possible for you guys to do the opposite of how you will grab long poll from a different pool that you have set up if the primary pool does not support it, so that you could add a local bitcoin client to check for blocks that could possibly find a new one before long poll does?

There's no way I'd be the first to think of this, so I just assumed it's not doable, or perhaps not worth doing? Just curious I guess.

edit: typo

Bitcoind doesn't have LP in it.
It does have an option to run a command on a block change that you can configure yourself.

I have thought of this before with the API - being able to send a message to the API when a block change occurs, however there is one more thing in an LP that would be missing:
The LP includes work on the new block.

Without this work, the LP is simply telling cgminer to go and do a request for work and thus there is the network delay of waiting for work from the pool.

I will skip certain specific details, to protect the innocent , but this process would probably be worse than waiting for the LP

... except when LP's are slow ... which has been happening more frequently in the last few months ... but only if the pool would actually return work during it's LP phase (which wouldn't make much sense since it will already be trying to send you work)

However, this could also lead to stalling the miner due to requesting work from the pool and waiting for it, but then simply getting a piece of work for the same 'previous' block if the pool doesn't already know about the new block.

LP design sux and always has since Deepbit came up with the idea (as I have mentioned before as well) - it needs to be faster (e.g. a simple UDP packet TO the miner might perform a lot better)

[gyverlb]

Looks like ck.kolivas.org is unreachable :

Code:

$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org

[-ck]

Looks like ck.kolivas.org is unreachable :

Code:

$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org

Server being relocated.

[OgNasty]

I am occasionally running into a lot of stale shares that are causing high numbers of rejects on certain pools.  Mining with a BFL Single farm.  It would be great if the load-balance option automatically switched away from any pool that was getting stale shares until the next block.

[-ck]

I am occasionally running into a lot of stale shares that are causing high numbers of rejects on certain pools.  Mining with a BFL Single farm.  It would be great if the load-balance option automatically switched away from any pool that was getting stale shares until the next block.

If a pool screws up somehow (and the proxy pools are the ones most likely to) and starts rejected *all* your shares, cgminer will disable it after 3 minutes and only re-enable it when it starts accepting shares again already.

[-ck]

Looks like ck.kolivas.org is unreachable :

Code:

$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org

Server being relocated.

Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...

[Luke-Jr]

I looked into the "Switch User" hang reported originally in CGMiner.

It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.

Thanks,

Luke

[cablepair]

Looks like ck.kolivas.org is unreachable :

Code:

$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org

Server being relocated.

Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...

ckvoilvas

I highly recommend you move your hosting to BTCWebHost.com, we are the oldest and most trusted Bitcoin accepting hosting provider in the world. You will never have to worry about anything like this happening again and best of all you can pay in Bitcoin.

-Tom
BTCWebHost.com
Bitcoinwebhost.com
Bitcoinwebhosting.com
BitcoinVPS.com