OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[seriouscoin]

Guys, can you guys explain to me why CGminer use lots of CPU power while mining with BFL ASICs compared to BFGminer?

I'm using RPi as a host and the difference is absurd.

60GHs SC with BFG miner uses ~5% while CGminer uses 20%

Anyone please test to confirm this. I have tested with different rigs and setup. Same result.

[1714294744]

1714294744

[1714294744]

1714294744

[-ck]

Guys, can you guys explain to me why CGminer use lots of CPU power while mining with BFL ASICs compared to BFGminer?

I'm using RPi as a host and the difference is absurd.

60GHs SC with BFG miner uses ~5% while CGminer uses 20%

Anyone please test to confirm this. I have tested with different rigs and setup. Same result.

2 things.

In literally the very previous message to the one you just posted you'll see that I've committed changes that decrease CPU usage. Low power devices running asic hashrates is new so this issue has only recently showed up, and I've aggressively started optimising that now. The CPU usage is lower now and a new version will be noticeably so on these low power devices.

The second is that because there is no driver between cgminer and the USB device, all the CPU usage that is normally attributed to the driver and/or hidden from the user is now all shown as cgminer CPU time - this won't go away but doesn't mean the system is using more resources, they're just attributed differently.

[atomicchaos]

In literally the very previous message to the one you just posted you'll see that I've committed changes that decrease CPU usage.

Ck- Thanks for the update. I'm thankful you do still support the GPU miners, and a donation is long overdue from me, as I have been using your app a couple months now and it's beyond valuable.


On a side note, this isn't really a bug, but very important to stress, you MUST have the --scrypt statement prior to the --intensity 20 (or anything above 13) with your new version, as you added the intensity lockdown for non-scypt logic. This caused an issue in an app I'm trying out that passed the --scrypt statement at the end, so it wouldn't allow the --intensity of 20, or anything above 13, until I moved the switch before the --intensity statement.

Again, not a bug at all, as you would think --scrypt would come first anyways, but just a heads up in the event other apps might not watch the order in which they pass switches.

A more precise description can be found here: https://bitcointalk.org/index.php?topic=248173.msg2915366#msg2915366

[kano]

If you have been GPU mining, you've always been using his app ... no matter what name it has

[eZc]

I have an Issue with 3.3.2 and 5870 cards. It makes HW errors. (same clk as worked without err 3.3.1)
I am pritty sure that its not a HW issue, since HW err are also when downclk.
I use: TC 5760 I 19 Driver 12.8

[atomicchaos]

Having some very odd issues with the recent version. My "Accepted" count is incrementing by 256 for each block.

[-ck]

Having some very odd issues with the recent version. My "Accepted" count is incrementing by 256 for each block.

Did you read the announce?

https://bitcointalk.org/index.php?topic=28402.msg2899153#msg2899153

[atomicchaos]

Having some very odd issues with the recent version. My "Accepted" count is incrementing by 256 for each block.

Did you read the announce?

https://bitcointalk.org/index.php?topic=28402.msg2899153#msg2899153

I'm sorry, I missed that one. It seemed like an odd change to me, so I just assumed it was taking the wrong value from somewhere. Thanks for pointing it out.


P.S. - Sent a small thanks to your 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq address for all your work on this in the name of GPU miners.

[Turbor]

It seemed like an odd change to me, so I just assumed it was taking the wrong value from somewhere. Thanks for pointing it out.

You are not alone with that. I can't really see the point of changing that but it's cons decision.

[kano]

It seemed like an odd change to me, so I just assumed it was taking the wrong value from somewhere. Thanks for pointing it out.

You are not alone with that. I can't really see the point of changing that but it's cons decision.

I changed it (but we both have made comment about it before in IRC)

There will be difficulty changes while mining
The old A value was simply the number of shares found - but there is no way to calculate what that number actually represents other than 'shares'. On top of that, U was even worse coz that was based on A
If you are still mining at 1diff then the number there wont really matter what it says

[os2sam]

Kano and ckolivas,
Did you guys know that there is a WinXP only version of Zadig?

I setup my XP Pro laptop to be backup to my Win7 mining rig and found that the Zadig in your download directory is incompatible with WinXP and it doesn't do a check to tell you that.  So I found the XP only version and that got me off the races with my backup PC.

I'm wondering if that is part of the trouble some Windoze users are having with the Zadig utility?

The XP Only version can be had from this link

http://sourceforge.net/projects/libwdi/files/zadig/zadig_xp_v2.0.1.160.7z/download

Thanks,
Sam

[kano]

Yep, I use WinXP for my testing (VM and kids computer are WinXP)

[os2sam]

Yep, I use WinXP for my testing (VM and kids computer are WinXP)

It may be helpful to folks to put that in the download directory as well.
Thanks,
Sam

Edit: the Zadig version in the downloads didn't work with Server 2008 32 bit either.  I haven't tried the XP version with it yet to see if that works or not.

[HellDiverUK]

 Windoze users

You have to stop calling Windows that.  It's not funny, it hasn't been in 2 decades.  Grow up.

[os2sam]

 Windoze users

You have to stop calling Windows that.  It's not funny, it hasn't been in 2 decades.  Grow up.

Now that I know it really irritates you, you know it'll never stop

[crazyates]

Windoze users

You have to stop calling Windows that.  It's not funny, it hasn't been in 2 decades.  Grow up.

Now that I know it really irritates you, you know it'll never stop

I still get a slight chuckle every time, so by all means please continue.

[Karin]

I've updated my unofficial Mac binaries for cgminer 3.3.2, website link is in the first post in this thread or simply by going here

http://spaceman.ca/cgminer

I included a new build for Mac OS X 10.5 PPC and updated the launcher, as it was attempting to use OpenCL before (which didn't exist until 10.6+) and crashing on start.

[-ck]

It seemed like an odd change to me, so I just assumed it was taking the wrong value from somewhere. Thanks for pointing it out.

You are not alone with that. I can't really see the point of changing that but it's cons decision.

I'm the opposite. I don't quite see any point whatsoever in showing absolute share count at all any more. The pools report your share count the same relative way. It's just a legacy from when there was only diff1 mining. I'm trying hard to move away from confusing information on the main screen (you can always get whatever information you want from the API).

[-ck]

Kano and ckolivas,
Did you guys know that there is a WinXP only version of Zadig?

I setup my XP Pro laptop to be backup to my Win7 mining rig and found that the Zadig in your download directory is incompatible with WinXP and it doesn't do a check to tell you that.  So I found the XP only version and that got me off the races with my backup PC.

I'm wondering if that is part of the trouble some Windoze users are having with the Zadig utility?

The XP Only version can be had from this link

http://sourceforge.net/projects/libwdi/files/zadig/zadig_xp_v2.0.1.160.7z/download

Thanks,
Sam

Yes I'm aware of it, and I do understand why people stick with XP, but in all honesty I'm still surprised that no one would run a 12 year old PC but they're using a 12 year old unsupported by MS operating system. As I said, I do understand the whole if-it-ain't-broke concept, but it still surprises me...

[-ck]

New release: Version 3.3.3 - 13th August 2013

This release was a concerted effort to decrease CPU usage for mining ASIC hardware on low power machines, especially when used with p2pool.


Human readable changelog:

- Avoid reproducing work as much as possible when generating work on stratum by storing a midstate of sorts on each stratum notification update.
- Cache some of the work to decrease work duplication on GBT.
- Fix a potential bug if a pool uses a nonce2 size bigger than 4 bytes.
- Fix a (very low) potential data corruption on work  generation.
- Add more useful debugging for when low level crashes in semaphore and mutex operations occur.
- Fix the intensity vs --scrypt bug introduced in 3.3.2


Full changelog:

-  Only perform the bin2hex on nonce2 data if it's required for stratum
submission, thereby removing the last conversion of that type from stratum work
generation.
-  Create a work data template when receiving stratum notification, allowing a
simple memcpy of the merkle root avoiding more hex2bin conversions on each work
generation.
-  Export the workpadding char in miner.h
-  Avoid a potential overflow should a pool specify a large nonce2 length with
stratum.
-  Avoid one more hex2bin in gen stratum work.
-  Rename work gbt_coinbase to coinbase to be in line with pool variable name.
-  Perform merkle bin hex2bin on stratum notify to avoid doing it on each work
generation.
-  Reuse just the one pool coinbase variable in stratum, avoiding more string
functions and storage in gen_stratum_work on each work generation.
-  Rename pool gbt_coinbase variable to coinbase to combine it with the stratum
coinbase data.
-  Use a nonce2 offset variable for both gbt and stratum to consolidate
requirements on work generation.
-  Merge pull request #474 from kanoi/master
-  util.c update quit call for new functions
-  use correct define for OSX in util.c
-  miner.h inline semaphores increase information on failure
-  util.c expand quit to show file/func/line
-  Merge remote-tracking branch 'conman/master'
-  Cache as much of the gbt coinbase as possible to avoid doing unnecessary
hex2bin conversion on every work generation with gbt.
-  We should be using a cg_wlock initially in generating stratum and gbt work
before downgrading the lock.
-  Add the ability to downgrade a write variant of the cglocks.
-  Fix --scrypt being required before scrypt intensities on command line or not
working at all via config files.
-  Cache the hex2bin of pool nonce1 in stratum, avoiding hex2bin on each work
generation.
-  Cache the binary generation of coinbase1 and 2 on stratum, avoiding a hex2bin
of coinbase1 and 2 on each work generation.
-  cgsem - increase information on failure