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

I've been running the new version for about 2 hours on p2pool.  Seems about the same performance-wise and running with no hiccups so far.

Performance is remaining stable & no obvious issues so far.

Subjectively, it seems to be doing better using p2pool mixed with others. I'll let it run for several more hours and assess again.

There is no donation pool.
That code was removed a few versions ago.

As per his sig: 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq

Edit: OK I'm slow

Gone, the feature caused too many bugs and wasn't useful enough. You'll have to donate directly...

You guys are my HEROS !
I have been battling this problem for a while now and I am SO happy to see it addressed in this latest release.
As always, you guys rock.

BTW: Where is the donation pool now ?

I don't know what to say. Con, you are a coding MACHINE! So many releases recently with all these many new features. +1 My favorite miner.

New release: Version 2.2.7 - February 20, 2012

- Send out extra longpolls when we have switched pools and the longpoll thread
is still bound to the old one. This is particularly useful with p2pool where
longpolls do not correlate with main bitcoin block change and would have led to
high reject rates on failover.
- Store whether a work item is the result of a longpoll or not in struct work
and use it to help determine block changes directly from the work longpoll bool.
- Keep track of when a longpoll has been sent for a pool and if the current pool
is requesting work but has not sent a longpoll request, convert one of the work
items to a longpoll
- Store the longpoll url in the pool struct and update it from the pool_active
test in case it changes. This is to allow further changes to longpoll management
on switching pools.
- Re-check for a longpoll supporting pool every 30 seconds if none is found
initially.
- Report threads as busy waiting on getwork on startup to avoid them being
flagged sick on startup during slow networking.
- Allow devices that are disabled due to overheating to be flagged as recovering
instead of disabling them and re-enable them if they're below ideal temperatures
and --no-restart has not been set.
- Tahiti prefers worksize 64 with poclbm.
- No need to expressly retain the opencl program now that the zero binary issue
is fixed. This actually fixes cgminer to work with the latest SDK included with
the ATI catalyst driver 12.2.
- Show error code on any opencl failure status.
- Add detection for version 898.1 SDK as well but only give SDK 2.6 warning once
on startup instead of with each device initialisation.
- Always use a fresh connection for longpoll as prolonged persistent connections
can fail for many reasons.
- Keep track of intended engine clock speed and only adjust up if it's higher
than the last intended speed. This avoids setting the clock speed to one
relative to
- Use gpu-memdiff on startup if an engine clockspeed is set and a memdiff value
is set.
- Revert "Adjust engine speed up according to performance level engine setting,
not the current engine speed." - ineffectual.
- Freeze the queues on all threads that are sent the pause message to prevent
them trying to start up again with saved pings in their queues.
- Updates to diakgcn kernel/
- Consolidate all screen updates to the watchdog thread and touch both windows
before refresh.
- Curses will be disabled in clean_up so don't do it early in kill_work, and
disable_adl so that GPU settings may be restored to normal in case shutting down
curses leads to instability on windows.
- Stop the mining threads before trying to kill them.
- Plain refresh() does not give reliably screen updates so get rid of all uses
of it.
- First release with working diakgcn kernel.

Rassah, 270 MHash/s seems a tad low. May I ask what work size and vector width you are using? Are you running the default 2 threads per GPU?

Another fine-tuning suggestion: a 270 MHash/s card might be better off with intensity 8, the stale rate should drop a bit provided your pool server is fast enough.
Right now, I'm at 0,21% stales at Bitminter which is rather high - usually my stale rate is about 0,1%.

That seems like a low hash rate.  On my 5830 I get 295Mhash at 935 Mhz and 313Mhash or so at 950 Mhz.  What SDK were you using to start with.  I'm using 2.4.
Sam

I have a host with 6970 and 7970.

Until now I have found no way to set GPU clock, mem clock and voltage at the same time.



- cgminers command line flags seem to not work: the power consumption is way too high, also MSI Afterburner shows that mem clock goes up once the miner starts mining.

- MSI Afterburner: I can set GPU clock and voltage, but mem clock can go no lower than 685

- Sapphire Trixx: GPU and mem clock can be set, but voltage is fixed

- ATI tray tools won't run with the 7970.

What to do?

This.  He didn't delete the bins after installing SDK 2.6 thus cgminer uses the cached copy. 

Rassah delete the .bin files (or better move them to another folder for safekeeping), restart cgminer.  It will compile under 2.6 and you will see performance go down.

The bin files are compiled by the video card the first time you run cgminer.  Depending on the previous version of cgminer, there may not have been any kernel changes, and thus no compilation.  That said, most likely you are still running a .bin file from an older SDK and this is why you have not experienced a slowdown, especially since you are using a 58XX.  However, when a new version has kernel changes you will experience that slowdown.  To verify this in the meantime, you can rename the .bin files in your cgminer directory and run it again, you will most likely notice the slowdown and a new bin file.  You can delete the new file and rename the old file to switch back to the faster kernel from the older SDK, and you will know, moving forward, that the newer SDK causes speed problems if you see them with a new update.  If you don't need to prove this to yourself, just check out the date of the bin file and you will see it is older than everything else in the cgminer folder because you are still using an old one.  Note that there may be multiple bin files, in which case the newest one is most likely the one you are using (you can be certain if you haven't run multiple kernels and all others have a lower version number in the file name).

I opened the compressed downloaded file, and copies all the contents into my old cgminer directory, overwriting all files. If the .bin file is part of the download, the yes. If it wasn't, then no. I don't know for sure

Did you delete the .bin inside cgminer's folder?

Just downloaded and installed newest driver, and downloaded and ran newest cgminer. No compiling, since I'm on Windows. Overclocked to 950 Mhz, memory underclocked to 300 Mhz, intensity at 9. Used to average 270 Mhash, and still do. I don't know what kind of bad issues I was supposed to experience, but just letting you know there aren't any issues with mine.

Con, I can confirm 2.2.6 Test works with 898.1 on Windows ... binaries are generated fine!
Did some tests with current diakgcn and it seems performance should not change with latest OpenCL runtime, but perhaps there are new ways to squeeze out a bit more performance .

Edit: Which intensity do you use, when comparing kernel performance?

Dia

It can only tell what version is currently installed, not what the kernel was compiled with.

Rassah: Did you delete the old kernel and let it compile a new one with the new driver?
ckolivas: Is the warning based on the installed versions, or can cgminer tell which version a kernel was compiled on?

Interesting. You're finding 5830 as fast on the new SDK as the old one? What clock speeds and what hashrate? Thanks.

Sapphire 5830 here, using newest drivers. Cgminer works exactly the same as it did on the old driver, hash speed and all (besides the BIG WARNING suggesting I use a previous driver when you start it, anyway)