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

[kano]

Well if sockets are actually working (the link there is about how to enable them when they aren't working) then it's a problem with the socket connecting to the target.

So it's a firewall/port forwarding problem if sockets are installed properly and enabled in PHP
(they are on by default usually in linux, but not always in windows)

That's what I figured.  I will update this thread if I ever find a solution. I am trying out some experiments from the php.net website.

If you 'roll' on over to FreeNode #cgminer it's usually easy to sort out where the problem is.

[1715262972]

1715262972

[1715262972]

1715262972

[rav3n_pl]

Any ideas about how to fix "hanging" on windows when ADL is enabled?
cgminer frozen after about 3-4hrs of mining yesterday :/ I`m not getting it, it always happen when I`m away form pc and user is switched to login screen.

I`m using now startup batch:

Code:

cgminer --shares 1
cgminer --no-adl 

1st instance is setting up clocks and exit after one share, 2nd one is mining.

[-ck]

User switching on windows does mystical voodoo the adl library doesn't like.

[sharky112065]

is there any chance of a GUI to be made for this to make miners and configs a lot simpler etc like over clocking settings miner settings then add in and done makes it up

Most likely not.  You can use the menu's within Cgminer to set those settings and then save a conf file. Further startups of Cgminer would use that saved conf file.

[Roland68]

Hi, what would be the parameter syntax in the cgminer.conf file to stop the stratum protocol on btcguils and returning to the old connect way ?

I have 3 PC's ans all 3 are crashing after some time ... at the same time ... (must be stratum/pool related).

thanks for your help.

[rav3n_pl]

User switching on windows does mystical voodoo the adl library doesn't like.

It is impossible to catch that somehow?
Some watchdog on ADL thread to detect and fix when it happen?
ADL thingy is good to disable mining when it is overheating.
It is my desktop pc, so i need to switch user to allow my kids play on theirs accounts...

[-ck]

User switching on windows does mystical voodoo the adl library doesn't like.

It is impossible to catch that somehow?
Some watchdog on ADL thread to detect and fix when it happen?
ADL thingy is good to disable mining when it is overheating.
It is my desktop pc, so i need to switch user to allow my kids play on theirs accounts...

Alas not that I'm aware of.

[-ck]

New version: 2.8.5, 23rd October 2012

Minor bugfix version.


Human readable changelog

More minor stratum fixes hopefully addressing some of the remaining windows crashes. No debugging has been able to capture their actual cause as of yet.
cgminer now tries to actually catch crashes and unless the --no-restart option is given, it will try to restart cleanly. Yes this is a desperate but hopefully quite useful thing to do.
A small delay is added between queues when the network is out to prevent the huge sudden spikes in queued values.
It was possible to run out of work if a stratum pool was going down often and cgminer was resorting to a regular getwork pool.
Build fixes for mingw builds on windows.
Stratum information now in the API.


Full changelog

- Handle crash exceptions by trying to restart cgminer unless the --no-restart
option is used.
- Switch queued count when choosing a different pool from a failed stratum pool
in getwork thread.
- Put a mandatory 5s wait between reattempting a getwork on failure to avoid
hammering requests.
- The ATI stream / AMD APP SDK environment variables appear to only interfere
with win32 builds so bypass them.
- Make sure to check pool stratum curl exists under lock before attempting any
recv to not risk dereferencing upon attempting to reinitiate stratum.
- Avoid redefining macros and align to 4 byte boundaries.
- API - add Stratum information to pools
- update FPGA-README for MMQ

[kano]

cut/paste ...

2.8.5
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.8.5a
https://github.com/kanoi/cgminer/downloads
(it also works on Fedora 16 and 17)

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make

[mdude77]

I'm still using 2.8.4.  Yesterday I'd swear it restarted itself.  I manually removed all the pools I didn't want using the P command, but they were still in the config file.  A few hours later I noticed my p2pool activity had dropped to zero again, so I checked it.  cgminer was mining away to a pool that wasn't supposed to be there, and a pool I'd added manually was no longer there!  I'm 99% positive I didn't restart it, and I don't have any scripts that would restart it if it crashed.  After that I edited the config file to put it the way I wanted...

M

New version: 2.8.5, 23rd October 2012

Minor bugfix version.


Human readable changelog

More minor stratum fixes hopefully addressing some of the remaining windows crashes. No debugging has been able to capture their actual cause as of yet.
cgminer now tries to actually catch crashes and unless the --no-restart option is given, it will try to restart cleanly. Yes this is a desperate but hopefully quite useful thing to do.
A small delay is added between queues when the network is out to prevent the huge sudden spikes in queued values.
It was possible to run out of work if a stratum pool was going down often and cgminer was resorting to a regular getwork pool.
Build fixes for mingw builds on windows.
Stratum information now in the API.


Full changelog

- Handle crash exceptions by trying to restart cgminer unless the --no-restart
option is used.
- Switch queued count when choosing a different pool from a failed stratum pool
in getwork thread.
- Put a mandatory 5s wait between reattempting a getwork on failure to avoid
hammering requests.
- The ATI stream / AMD APP SDK environment variables appear to only interfere
with win32 builds so bypass them.
- Make sure to check pool stratum curl exists under lock before attempting any
recv to not risk dereferencing upon attempting to reinitiate stratum.
- Avoid redefining macros and align to 4 byte boundaries.
- API - add Stratum information to pools
- update FPGA-README for MMQ

[os2sam]

User switching on windows does mystical voodoo the adl library doesn't like.

It is impossible to catch that somehow?
Some watchdog on ADL thread to detect and fix when it happen?
ADL thingy is good to disable mining when it is overheating.
It is my desktop pc, so i need to switch user to allow my kids play on theirs accounts...

I have CGMiner in the startup.  So my kid logs my session out, which shuts down CGMiner, and logs into his which starts CGMiner again.
Sam

[-ck]

I'm still using 2.8.4.  Yesterday I'd swear it restarted itself.  I manually removed all the pools I didn't want using the P command, but they were still in the config file.  A few hours later I noticed my p2pool activity had dropped to zero again, so I checked it.  cgminer was mining away to a pool that wasn't supposed to be there, and a pool I'd added manually was no longer there!  I'm 99% positive I didn't restart it, and I don't have any scripts that would restart it if it crashed.  After that I edited the config file to put it the way I wanted...

There is only one occasion where cgminer restarts itself prior to version 2.8.5: That is when the fanspeed monitoring fails on windows. It used to be the bane of my existence quite a few versions ago where people would either lose their fanspeed monitoring or cgminer would crash. Now it sneakily restarts itself if the ATI driver's fanspeed monitoring stops working so it can get it going again.

[rav3n_pl]

User switching on windows does mystical voodoo the adl library doesn't like.

It is impossible to catch that somehow?
Some watchdog on ADL thread to detect and fix when it happen?
ADL thingy is good to disable mining when it is overheating.
It is my desktop pc, so i need to switch user to allow my kids play on theirs accounts...

I have CGMiner in the startup.  So my kid logs my session out, which shuts down CGMiner, and logs into his which starts CGMiner again.
Sam

I can not log out, because I run linux VM that holds xCoind`s and p2pool
I need switch users.

[ryann]

I notice that i am getting many more rejected shares now that im using 2.8.4 compared to 2.7.5. I usualy get about 10 rejected shares per 20 000 accepted shares. Now with 2.8.4 ive gotten 200

Nothing's changed in management therein, so I can only assume it's coincidence and pool related.

I immediately stopped the 2.8.4 and restarted 2.7.5 and i have no stale shares at all yet. Soemthing is definetly up

Did you move to stratum with 2.8.4?

EDIT: To explain why I ask that, cgminer + stratum gets notification of block changes much faster than ever so it should reduce the number of stales. On the other hand, I have noticed that slush uses that as an excuse to ignore any shares that are returned from the previous block immediately once it has stratum notified you of the new block saying job not recognised, so to me it looks like stales on slush went up, not down, despite the potential advantages. I'm not sure how btcguild fares there.

I signed on 2.8.4 like this 

http://btcguild.com:9332
username  whatever
password   whatever

[-ck]

I notice that i am getting many more rejected shares now that im using 2.8.4 compared to 2.7.5. I usualy get about 10 rejected shares per 20 000 accepted shares. Now with 2.8.4 ive gotten 200

Nothing's changed in management therein, so I can only assume it's coincidence and pool related.

I immediately stopped the 2.8.4 and restarted 2.7.5 and i have no stale shares at all yet. Soemthing is definetly up

Did you move to stratum with 2.8.4?

EDIT: To explain why I ask that, cgminer + stratum gets notification of block changes much faster than ever so it should reduce the number of stales. On the other hand, I have noticed that slush uses that as an excuse to ignore any shares that are returned from the previous block immediately once it has stratum notified you of the new block saying job not recognised, so to me it looks like stales on slush went up, not down, despite the potential advantages. I'm not sure how btcguild fares there.

I signed on 2.8.4 like this 

http://btcguild.com:9332
username  whatever
password   whatever

Yes that will be switching to stratum on startup. For a more objective test, try the latest 2.8.5, run for a while with your regular login details above (that will automatically switch to stratum) and then try running 2.8.5 again but this time add --fix-protocol to your startup. I'm wondering if users are losing out due to the way pools are implementing this and being very restrictive about how and when to accept stales.

[slush]

EDIT: To explain why I ask that, cgminer + stratum gets notification of block changes much faster than ever so it should reduce the number of stales. On the other hand, I have noticed that slush uses that as an excuse to ignore any shares that are returned from the previous block immediately once it has stratum notified you of the new block saying job not recognised, so to me it looks like stales on slush went up, not down, despite the potential advantages. I'm not sure how btcguild fares there.

Eh, I probably don't  understand what you're talking about. Can you explain it a bit? Are you reffering to error message "Job ### not found", instead of "expected" message "stale share"?

[slush]

Yes that will be switching to stratum on startup. For a more objective test, try the latest 2.8.5, run for a while with your regular login details above (that will automatically switch to stratum) and then try running 2.8.5 again but this time add --fix-protocol to your startup. I'm wondering if users are losing out due to the way pools are implementing this and being very restrictive about how and when to accept stales.

There's no special restriction in accepting shares as stale. Share is rejected once another valid bitcoin block appear on the network, so currently sent solution cannot became a valid block anymore. But this is how pools works for two years already and it isn't related to Stratum protocol at all...

Edit: Some pools are "accepting stale shares", but they use it just as their marketing tools, because these shares cannot be used as block candidates. Basically accepting stale shares is robbing optimized miners and giving their reward to sub-optimized or broken miners, which may send a lot of stale shares and they're still credited for them. But AFAIK no current Stratum-powered pool is accepting stale shares...

[kano]

Regarding Stratum Rejected shares:

If you have any network reliability issues you will get rejects due to that.
Reconnects always lose you shares.

Of course a difficulty change loses you shares too - which may happen soon after a reconnect.

In general I find I get about 54% of the Rejects per LP "(stale)" compared to Getwork.
That's a drop from about 0.35% to about 0.19%

These sort of Reject messages really suck also:
 [2012-10-24 00:06:07] Rejected 216df95a Diff 7/1 GPU 0 pool 2 (olddifficulty)
 [2012-10-24 00:06:08] Rejected 5af4e74e Diff 2/1 GPU 0 pool 2 (olddifficulty)

[-ck]

Regarding Stratum Rejected shares:

If you have any network reliability issues you will get rejects due to that.
Reconnects always lose you shares.

Of course a difficulty change loses you shares too - which may happen soon after a reconnect.

In general I find I get about 54% of the Rejects per LP "(stale)" compared to Getwork.
That's a drop from about 0.35% to about 0.19%

These sort of Reject messages really suck also:
 [2012-10-24 00:06:07] Rejected 216df95a Diff 7/1 GPU 0 pool 2 (olddifficulty)
 [2012-10-24 00:06:08] Rejected 5af4e74e Diff 2/1 GPU 0 pool 2 (olddifficulty)

That's interesting and a good point about reconnects. Your rejects went down when you moved to stratum which is the desired effect. With getwork, you are forever grabbing new connections and are allowed to continue working on previous work. However once you have to reconnect with stratum, all your old work is now redundant. So lots of disconnects would be expensive with stratum.

[slush]

If you have any network reliability issues you will get rejects due to that.
Reconnects always lose you shares.

Yes, this is true. I was thinking about some solutions for resuming connections, but it is quite hard architectural issue (any reconnection can land on another backend, due to DNS balancing or HA setup on the server. This is issue even with getwork, but pools are doing some work arounds, but it has another issues (sticky http sessions leads to poorly balanced traffic, for example).

But as I understand, ckolivas referred to something else than reconnections. There's chance that I just don't understand his post.