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

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.

Morning all. There will be another quick release in succession as there is a problem with keeping up with slow responding pools when you have mutli-gigahash machines.

win 7 64 bit (just one 6870) here, 2.3.5, no probs.

re download and install clean (ie new directory)?

OK ...

Why on the final bolded.  The ONLY thing SDK is used for is to compile openCL kernels.  Nothing else. So why would you want to install an SDK you know results in poor performance if/when you ever need to compile kernels again?

To answer your other question yes 2.4 is likely the best.  I haven't seen any performance difference between 2.4 & 2.5 so likely either one works that being said I use 2.4 because it works and there is no reason to mess with what works.

Oh, OK my next suggestions were going to be turn the monitor sideways and squint. 

Not a very productive suggestion, probably.  I have been wondering why CGMiner can't scroll like Phoenix can, probably has something to do with the variable status's at the top of the screen as opposed to the last line at the bottom.
Sam

So would you say that the followng steps would work?
I have cat 12.3 (this is a gaming system) and probobly sdk 2.6 (dont worry about the removal, I've done it before)
so:
Uninstall SDK 2.6...
(Reboot?1)
Install SDK 2.4 (i have 2 6870's so i assume this or 2.1 would be the best)
(Reboot?2)
Compile the .bin
Uninstall SDK 2.4
(Reboot?3)
install SDK most recent
(Reboot?4)
Enjoy!