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

Pool management (enable/disable) is now in 2.3.0 and "addpool" is up for a pull request:
https://github.com/ckolivas/cgminer/pull/137
So that may be there some time too if ckolivas is happy with the code change.
"delete" (as mentioned before) can be implemented by using "disable" (so you don't lose your pool stats) which has almost the same effect except you don't gain a new empty pool slot of the current maximum of 32 pools

Edit: addpool is in 2.3.1 (API says version 1.3 - version goes up when new commands added to an official release)

Hmmmm, I seem to be finding it to be quitting after a few hours :/
I'm not logging anything, so maybe I'll add that and see what happens.

LOL if this hasn't been a polarising release, nothing has. This is one of the reasons it got a minor version upgrade.

Thousands of hours of coding can't guarantee that I can work around every combination of AMD fail that's possible, and trust me, there are more than anyone can imagine. I'll get there in the end...

I don't agree with the poster above.. For me 2.3.0-1 has best performance since a long time.
Using the automatic settings (Diablo kernel) I am winning 10-20MHash per card.
Good work!! 

@bitlane:
Try specifying "-k phatk" to get the old performance back.
(Also, the ability to read back 2-3 pages might be considered a prerequisite to using a forum...)

WOW....I mean, W T F ?

I just upgraded 5 rigs from 2.2.7 to 2.3.0 and lost speed across the board.

Not that I don't want to read 216 pages to find my answer, but I have NEVER had this problem and upgrade to the latest version every time it's uploaded (Win 7 x64).

All my 5xxx cards are running Cat12.1/2.1 SDK, my 6xxx cards are running Cat12.1/2.4 SDK (CONFIRMED). All cards run (and always have run) static I=8.

What just happened ?

ie. None of my cards will maintain 99% load, all 80%-ish....WTF ?....All 5830's = 10+ MH/s slower, U=less also. Overall speed/U = much slower/less, 6xxx series cards are jumping around (LOAD) and are running like ass.
**6950's (12.1/2.4 SDK) lost 80 MH/s each .......5830's (12.1/2.1 SDK) lost 15 MH/s each .......6870's (12.1/2.4 SDK) lost 40+ MH/s each.... Compared to SAME EVERYTHING using 2.2.7 package and FRESH/NEW BINS.....

Can anyone elaborate ?

I deleted EVERYTHING, created ALL NEW BINS. All I saved were my BAT files, that I was FORCED TO ADD IP Range to for my monitoring/control app  

Drivers/SDKs were reinstalled last week when I decided to optimize everything and go to get rid of my CPU bug(s) by using 12.1 CAT.

The above results were with cgminer-2.3.0-1-win32.zip.
I am going back to 2.2.7

Yes, I wanted to rush out the new package to stop people from downloading the original one ASAP so I didn't even change the version number on the kernel which is bad of me I know.

ck, was the change in 2.3.0-1 for phatk?  I assumed it was, but noticed the kernel version number didn't change (unless I eyed it wrong), if my observation is correct, then anyone who downloaded 2.3.0 and then 2.3.0-1 would not get a new kernel if the 2.3.0(not-1) kernel was there already with the same name.

Thanks much appreciated. 

All good, you're on 2.5. You probably got the dud kernel in the first packaged release which is why I upgraded to 2.3.0-1

I'll probably release a 2.3.1 pretty soon today, reverting a few of the kernel changes that were dubious and based on what diablo and others said. I should have trusted myself 

ckolivas,

tomorrow I'll test it,

this is what cgminer -n says right now:

Make sure you're using the slightly upgrade 2.3.0-1

If you still have a hashrate drop like that then you're doing the SDK2.6 dance. cgminer -n will tell me what openCL you're using.

cgminer + diablo + p2pool = awesome  

oh, and also ANUBIS, that just makes everything pretty =)

Finally have all the control (fan, clock, etc) without losing any performance or having to fiddle with SDK versions.

Donation sent, keep up the good work.

Are you specifiying any -k switch? You could try -k phatk, -k poclbm, -k diakgcn or -k diablo ... perhaps one of em gives good perfrmance, until Con fixes the current glitch, which seems to come from a rather small change in all kernels.

Dia

Enabling / disabling pools via the API... how do we know the current state?
Presumably, status=alive tells us if we can communicate with the pool, and not that it enabled.

My 5830 doesn't appear to have dropped at all.  If it did, it dropped 5 MH/s from 318 to 313, but my U looks really good for now, so I doubt it was 318 before (but that's only on 380 shares, so U doesn't mean much yet, as was just discussed).  I am running 2.3.0-1 with phatk (default for cypress) -w256 -v2.  You may not be having SDK 2.6 issues, but I wish cgminer could tell which SDK a kernel was compiled with since said issues seemingly haven't gone away yet.

I've just tested 2.3.0 on a dual underclocked/undervolted 5870s rig and I went from 370 down to 330 MH/s per card.

This is with -g 1 --submit-stale -I 6

spiccioli

Can BFL (or more generically, FPGA) count be added to the API?

Thank yoooooou

The answer I was looking for was add -m32 to CFLAGS, but that's OK, I found it.    Also, after doing that I did have to change LFLAGS to point at the 32bit version of the SDK, and this still wouldn't have worked if I didn't have all of the 32-bit libraries installed as well, so I guess the answer you should have given me was "Cross compiling isn't supported in my configure script, but you can try adding -m32 to CFLAGS, YMMV."

Let me put it simpler.  Your wrong.  


Couple points:

1) If a pool going haywire retroactively changes your avg since start well you got a lot bigger problems.  The second number is hashrate since start it is # of hashes / elapsed time.  So after 20-30 min in it shouldn't change significantly within a few seconds.

2) That has nothing to do with intensity.  If you change intensity it will change mhashes.  It will also change shares BUT shares rate ("U:") has roughly 4 magnitudes more variance for a given time period.

So looking at share rate in the short term may mean you are simply looking at noise.

For example
start cgminer -let it run 2 minutes check U rate.
now stop cgminer
fart, yes far.
start cgminer -let it run 2 minutes check U rate.

Tada farting must affect share rate. It is entirely possible the two values will differ by 20% or more.  Farting (or lack of farting) boosts share rates 20%!  

So you seeing a major change in share rate doesn't mean anything unless you are waiting a very very very long time.  Share rate (U) really only stabilizes after 10K or so shares.  I would say 20K to 50K would be better.  So unless you are setting intensity and waiting half a day to make sure the results are valid using share rate in the short term is useless.

Of course none of this has anything to do with your original claim.
If you change intensity you should see a change in MH/s.  Period.  If you aren't then something is wrong.  If a pool goes offline and that retroactively changes your prior MH/s average (yes the second # is the average since starting) then something is wrong.  You shouldn't rely on your conclusions for anything.