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

Gotta love google translate

Let see if I understood the question ....

A 1diff share is fixed, independent of the network difficulty.
You should find on average 1x1diff share per 2^32 hashes done - average, after finding a few million of them

The network difficulty defines how many of these you need to find before you should, on average, find a block
Of course you have to find thousands of blocks to expect to be close to the average.

There are difficulties changes be mining while the old value was only without found number of shares -, but isn't what number this really the shares than other calculated to this.
More worse than without found based on it, but still, if the mining was after the number not really the matter of what they say.

hope ck releases a single firmware and maybe updates jalapeno to 1.2.6

https://blockchain.info/tx/52485d6a05fdaa54d6c6bd73906a840590503bfb078cb1bacc77c6e0f76df5bb

I've a 2nd RPi in transit (that I'll leave running Raspbian)
Once I get that I'll build both each time (and a 3.3.3a Raspbian) - just annoying to shut it down, switch, reboot, build, shutdown, switch, reboot, mine ...
... since I know the other one is due here soon.

I've uploaded a new firmware. Should fix this.

http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/

Damn, no Raspbian binary this time.

FYI I put the 3.3.3a binaries and sources etc into my cgminer-binaries git as usual ... but about 2 hours ago.
Yes I'm skimping on the post this time

There's a regression where auto doesn't go quite as fast as it used to, I'm working on a fix now.

Ah yes I see what's wrong there. I've committed a fix to git for this.

Hi,

I'm having this message continually since I upgraded to 3.3.3

 [2013-08-12 23:49:01] Rejected 9f13b83d Diff 1/1 AMU 3 pool 0 (Extranonce2_size violated)

will roll back to 3.2 to see if it fix the problem.

EDIT: The problem seems to only happen with bitminter. I have switch to slush pool and all is fine.
EDIT2: Yep. The incompatibility has been introduced by 3.3.3. I have come back to 3.3.2 and it started to work again.

I run PC's allot older than 12 years old, not to mention Operating Systems, hence my profile pic.

Many of the customers I deal with are still using WinXP & Server 2K3 so I have several machines with those OS's on hand.  That's often the way of Vertical Market software.

Besides there's about a year of M$ support left on XP.

The thing that surprised me is that Server 2K8 gave the same error as XP when I ran the Zadig I got from your site.
Sam

I understand I wasn't using it as intended, and obviously what you guys have changed is more towards the intended purpose, I was only sharing how I look at things in it, and agree, I'll need to upgrade my thinking about it.

Thanks for taking the time to explain!

Finally got my OTG cable for my Tablet, I got a LinuxVM for it and installed ubuntu and I cloned cgminer from git and double checked all my dependencies. Everything seemed fine till I got to ./configure I get this error.
I double checked and I have libusb-dev apt'ed and installed far as I know.
Any clue what may be wrong?

Sorry, that just means you are misunderstanding what the old A means.
Since you can submit 2 (or more) shares with 2 (or more) different difficulties, there is no clear meaning to a share count other than the number of times you have sent something to the pool - where 'something' is not necessarily the same each time.

Some pools start you submitting shares at 1 difficulty and thus if you have 100GH/s you'll get a rash of shares to start up.
Then when the pool switches you to 100 difficulty, your share count will clearly show how meaningless the old A is now with higher variable difficulty - i.e. if the pool took 10s to switch the difficulty to 100, the old A could show over 250 in the first 10 seconds and then it would slowly count up by 1 every couple of seconds after that - so at say 20 seconds it could have said A:255 and 100 diff at the top ... yep means nothing.

Unofficial Mac binaries updated to 3.3.3 at http://spaceman.ca/cgminer.

(if you'd prefer I not post here after every release, just let me know)

It's hard to argue with the person who gives us so much, so just take this as another viewpoint. I use the Accepted value as an indicator of the miner work effort, and while it might not logcally relate anymore to the original intention, it now means I have to divide by difficulty to see the exact absolute count. I suppose it's just a matter of getting used to the change, especially seeing a large rejected number, although the percentage stays the same. 

I'm sure I'm not using the counter in its original intention, but it just seems so much easier to read with an absolute value that is smaller than the current changed number.

Again, that said, I'll defer to the expert opinion around here from the person kind enough to provide us with a great tool and many updates. Thanks to all those that support this effort!

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

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...

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).

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.