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

You can both read up here and make a judgement:

http://forum.bitcoin.org/index.php?topic=1721.msg350636#msg350636
http://forum.bitcoin.org/index.php?topic=1721.msg353888#msg353888
http://forum.bitcoin.org/index.php?topic=1721.msg358529#msg358529

ATM there's no right or wrong (imo), either way, like the first post said, it works.

Quick bugfix release version 1.2.6:

Source
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.6-1.tar.bz2

(windows build soon hopefully)

- Put a current system status line beneath the total work status line
- Fix a counting error that would prevent cgminer from correctly detecting
situations where getwork was failing - this would cause stalls sometimes
unrecoverably.
- Limit the maximum number of requests that can be put into the queue which
otherwise could get arbitrarily long during a network outage and increase rejects.
- Only count getworks that are real queue requests.
- Allow queued to be zero again since you can now see the queued versus staged value and tune it better. This can also decrease stales.


New status line has the following:
TQ: 2  ST: 2  LS: 0  SS: 0  DW: 0  LW: 0  LO: 0  RF: 0  I: 2

from README:
TQ is Total Queued work items.
ST is STaged work items (ready to use).
LS is Longpoll Staged work items (mandatory new work)
DW is Discarded Work items (work from block no longer valid to work on)
LW is Locally generated Work items (during slow server providing work)
LO is Local generation Occasions (server slow to provide work)
RF is Remote Fail occasions (server slow to accept work)
I is current Intensity (changes in dynamic mode).

If you find the STaged value is often at zero despite your TQ being high then your server may be slow at providing work and you can use this to tune the number of work items in the queue with -Q. It should always be great than 0 if TQ is greater than 0.

This version is slightly faster on average thanks to not slowing down as often during the getworks

Searched out more discussions on other threads and it was decided this was incorrect. I'm leaving it as is with POST after taking it under advisement from other people since I have no actual opinion on the matter.

7 theads per gpu is really not going to help you. Stick with the default of 2. Plus try some other values, like not setting -w or set it to 128 or set intensity to no higher than 8.

Perhaps you did not read that i said CPU miner. For the CPU miner to scan ALL the 4 billion nonces, even 10 minutes are not enough

A kid goes to the doctor and says to the doctor, "Hey Doc, I get a little light headed when I've been hanging upside down from the monkey bars for too long."  The doctor replies, "Then don't hang upside down from the monkey bars for so long."
There's a message here.

Honestly, why would anyone use a scantime of over a minute?  Over 30 seconds doesn't really make a lot of sense in my opinion.  15 seconds is better.  Longpolling is best.  Perhaps an error saying 'Error: User is wasting time computing blocks that were solved 30 seconds ago' might suffice?

Which exactly?

Is that a technical term?

I noticed a bug in the CPU miner which was not in the previous versions. If i set the scantime to very high(above 60) eventually the cpu miner runs out of nonces and shit start to happen.

ckolivas when you get some time please post an windows compiled version too as i don't have mingw on this computer and because of some problems i can't install it now.

Sure! Thanks for your effort.

But still it produces a lot of rejections... 

This is just a reminder

Try -v 2 as well. Since it may pick v 4. But you really should be on -w 128 for a 6850 I think. I lose 5mh/s going from 128 to 256 on a 6870.

I'm disappointed to report,losing like 20mh on 6850. Maybe CGMINER is not configured optimally? This is what i'm using as of the moment. -w 256 -g 7 --intensity 9

New release version.

Source only at the moment:
http://ck.kolivas.org/apps/cgminer-1.2.5.tar.bz2

New features:
- I removed the -n option being no dynamic and left it how it was as number of devices
- Setting an intensity now of any value automatically disables the dynamic feature. It was basically completely overrided if dynamic was enabled, so these are now mutually exclusive features.
- I've added signal handling to try and clean up at the end and return the shell/console neatly if you press ctrl-c. I believe you need to use ctrl-break on windows still (when the binary comes out).
- There is a new option:
 --text-only|-T      Disable ncurses formatted screen output
- I've made it so that the watchdog thread only restarts threads if they're inactive in the setting of normal network conditions and will not try to restart them if the network connectivity is down.
- cgminer now tests on startup that it can connect at least once with the url and credentials to not try and reconnect indefinitely.
- There is no "fake work" at startup now with one hard lot of work handed to the gpu mining thread which should prevent the false positive hardware errors reported.
- CPU mining has been fixed, it was not resetting back properly on getting a new work item.
- The status window in curses mode will update more reliably and do less work now.
- Modifications to build on mingw32 for windows and now to build on osx courtesy of Ycros
- A status summary is now printed on exiting cgminer. It looks like this:

---
Summary of runtime statistics:

Started at [2011-07-15 01:05:28]
Runtime: 0 hrs : 12 mins : 13 secs
Average hashrate: 178.4 Megahash/s
Queued work requests: 33
Share submissions: 28
Accepted shares: 24
Rejected shares: 4
Reject ratio: 14.3
Hardware errors: 0
Efficiency (accepted / queued): 73%
Utility (accepted shares / min): 1.97/min

Discarded work due to new blocks: 4
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 0
Work items generated locally: 0
Submitting work remotely delay occasions: 0
New blocks detected on network: 2

Summary of per device statistics:

 GPU 0: [178.4 Mh/s] [Q:33  A:24  R:4  HW:0  E:73%  U:2.04/m]


... I think I need a little break now

No, this is what the curses UI looks like

Ah, it works if I leave off -n. But I can only run 1 instance in linux, 2 doesn't seem to work.

Without -n I'm about 7-8 mhash behind hashkill on my dedicated miner and 20-25 on my workstation

what exactly have you done? I had also issues on 64 bit natty, but now it works....

I don't know exactly why, but that made it. I re- ./configured and "make"ed again and now it works.

Thanks fot the help. Now i will do a bit of testing and optimizing to look what the miner can do in comparison to phoenix. But what is weird: the CPU usage of my triple Core CPU is about 30% on each core. While using 4 Instances of Phoenix, i used only 3 to 4 % of each core. So the XPU usage is quite higher with the cgminer. Any theories on that?


EDIT:
==> SOLVED:I forgot the -n flag. Now the CPU usage is around 2% for each core.

Trying to install on Natty 64bit.

I can build both tarball and git versions, but neither works.

The 1.2.4 tarball just says: Segmentation fault
The git repo says: 2 GPUs Detected. Then back to shell

trying against 2.4sdk, 11.6 catalyst. Dual 5830s.

I have no problems running hashkill, phoenix or poclbm on this box.