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

I have two asus 5770's running on stock Ubuntu 11.04.  aticonfig can read the gpu temps just fine, but these stats don't appear in cgminer.  I've tried numerous versions of cgminer, AMD sdk's, all with the same results.  

https://img.skitch.com/20120429-tgisxymgwsgdj83egw2xr7yue2.jpg

https://img.skitch.com/20120429-8rxk84cg6k3gxr4mb2d933kjpt.jpg

Anyone have any ideas what's causing this?

someone help me via pm!!! i tried to update my video drivers and i eneded up installing sdk 2.6, So i followed some advanced removal steps that i stated for me to delete some /windows/inf .inf files, And when i went to install sdk 2.4 It was fine, But when trying to install the display drivers, I ALWAYS get ".inf file not found blah blah cannot install"

I've even tried a system restore, And that device manager install thing doesnt work!, Please help me!, My hashing power and main computer are practically gone!!!

Any1 can tell me haw to use zteX board? i`m getting error -3 in the beggining. i got 15y board.

Hmm... Problem's gone now. Nevermind then, sorry for bothering you. I think it has to do with my installation of ntpd while using cgminer.

What build options did you use or

What is the output of one of:
1) java API config
or
2) echo -n config | nc -4 127.0.0.1 4028 ; echo

If you are windows and 1) doesn't work or you have problems getting either to work just ask

That is not a dumb question at all and in fact you are right in thinking there may be an advantage, but it is complicated.

The reason comes down to what happens at longpoll time. A longpoll occurs when the block on the network has changed. This is the time you are most likely to submit stale shares because you are working on the old block still when the new block is already spreading throughout the network. Furthermore, once the longpoll hits, you have to throw out all work and ask your pool(s) for more work so it is the time you are most likely to have a drop in hashrate while waiting for the new work (this is why the older releases of cgminer used to say waiting for fresh work).

Now because cgminer checks longpolls from *any* pool you are connected to now, it can tell when the block changes on the network often faster than your primary pool finds out because you may be connected to the pool which discovered the block as well. So cgminer then knows to stop working on anything from that old block in anticipation that it will be wasted work. However until your primary pool discovers that the block has changed, you cannot actually get useful work from it. The beauty of longpoll, though, is that it is actually giving cgminer work as well, so you will be getting work from the backup pools to fill in the trough period until your primary pool finds out the block has changed. For this to be useful, though, you do actually have to be happy for the backup pools to get some of your shares over time, and therefore enough shares have to accumulate to eventually give you a payout from them. If you enable the --failover-only option, you lose this benefit because not only will cgminer stop working on the old block before your primary pool discovers the block has changed, but you won't even accept any work your primary pool gives you until then, so it will dip in hashrate for longer.

There is also one other potential use that I'm not sure if I should point out or not

If you see this:

You now have a way of knowing which pool is LIKELY (though not surely) to have found that block if you have most of the major pools in your set up. This means you now have a way to *cough* choose who to hop to, if you're so inclined...

You must be referring to the individual GPU line then as it still shows two decimal places.  I thought you were referring to the "U" output in the top right...

I am using 2.3.6... I just recently cloned it from the git repo and built it. The number's at 128.89 shares/min now.

Ah my bad 

Con - should have quoted in my last post...

The fact he mentions 37.14 displayed he is NOT using 2.3.6 and should update...

1 decimal is fine for U as you said...

Curious. What possible useful information does .01 hashes/minute resolution give you? Variance of share luck alone is usually in the +/-10% range, and the 2nd decimal place was only ever there for CPU miners to see something besides zero.

Sorry if this is a dumb question ckolivas:

Is there any advantage to having cgminer listen on multiple large pools for LP's even if you have no intention if mining there? For example:

Pool 0 - The real desired pool
Pool 1 -  Large pool number one
Pool 2 - Large pool number two
Pool 3 - Large pool number three

Not using 2.3.6 then as the U now shows just 1 place after the decimal...

There seems to be a problem with the share/time counts, as I only have a small 220 mhash/s and cgminer's showing me a constantly growing 37.14 shares per minute.

In 2.3.3 and 2.3.4 my window would expand down to the bottom of my screen or there abouts. I was able to see a lot of the share returns and stales and long polls etc. In 3.3.5 and 3.3.6 it is back to the screen I was used to in previous versions where I have about 4 lines showing. Kind of like the window expanding down if I could have that back it would be very helpful.

Thanks.

NEW RELEASE - VERSION 2.3.6, 29 APRIL 2012

This is a hotfix release around 2.3.5 so anyone on 2.3.5 I suggest you upgrade as soon as possible.

Human readable changelog

Important: --submit-stale option no longer exists. I have replaced it with --no-submit-stale and made it submit stale shares by default now. The reason for this change is that with the new longpoll code in cgminer, it can detect block changes if you have backup pools almost always faster than the primary pool can detect the block change (unless the primary pool found the block). This means the primary pool is still accepting shares for the old block, so it won't consider them stale yet.

I've further revised the networking code to be able to cope with multigigahash machines that can overwhelm the one upstream and one downstream connection that was introduced into 2.3.5. Now it tries to get the best of all worlds. It does this by keeping one connection open for up and one for down and reuses that at all times, but, when it detects a backlog of share submission or getworks will occur, it starts recruiting extra connections. Thus it will be as nice as it can be to networks, but get nasty if it needs to.

Two crashes were fixed: One was that hot-adding of pools was broken in 2.3.5. The second crash would very rarely occur across a longpoll when many pools were set up.

The double longpoll message from the same pool should be fixed.

Slight changes to make the screen output even neater.

Full changelog
- Shorten stale share messages slightly.
- Protect the freeing of current_hash under mutex_lock to prevent racing on it
when set_curblock is hit concurrently.
- Change default behaviour to submitting stale, removing the --submit-stale
option and adding a --no-submit-stale option.
- Make sure to start the getwork and submit threads when a pool is added on the
fly. This fixes a crash when a pool is added to running cgminer and then
switched to.
- Faster hardware can easily outstrip the speed we can get work and submit
shares when using only one connection per pool.
- Test the queued list to see if any get/submits are already queued and if they
are, start recruiting extra connections by generating new threads.
- This allows us to reuse network connections at low loads but recuit new open
connections as they're needed, so that cgminer can scale to hardware of any
size.

On one of my rigs, I suddenly had a lot of instability with 2.3.5 that resulted in GPUs getting SICK very quickly and often cgminer locking up completely and becoming unkillable. (even with kill -9).  I reverted to 2.3.4 and have been running smoothly for 3 hours so far. 

I haven't been able to pinpoint the problem.  Other rigs are fine (although all of the rigs are slightly different linux installs, so it's hard to know if it is a hardware difference or an OS difference or what). 

No, the sick rate should not be changed by this code update. The symptoms usually happen on machines with >2GH connected to GPUMAX. What happens is that it starts submitting lots of stale shares and then eventually submits nothing but rejects because the network simply can't keep up at the other end.

Is this by chance making cards 'sick' more than normal ?

I have been seeing alot of sick cards today since I upgraded from 2.3.3 to 2.3.5.

Also....
What happened to 'B-F-Jesus-Miner' ? Is everything back on track for a single iteration/unforked CGMiner ?

Wow pretty niche bug.  Impressive to tack it down that quick.