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

[atomicchaos]

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

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!

[1714243800]

1714243800

[1714243800]

1714243800

[1714243800]

1714243800

[1714243800]

1714243800

[Karin]

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)

[kano]

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

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.

[OtaconEmmerich]

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.

Code:

configure: error: Could not find usb library - please install libusb-1.0

I double checked and I have libusb-dev apt'ed and installed far as I know.
Any clue what may be wrong?

[atomicchaos]

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

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.

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!

[os2sam]

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

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

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

[lano1106]

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.

[-ck]

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.

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

[-ck]

First problem found in  --avalon-freq <arg> Set frequency range for avalon-auto, single value or range

with range set from 330-360 this is not working and miner has been sat on 330 for over an hour not increasing on decreasing in speed yet on previous version was working?

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

[kano]

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

[Krak]

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

Damn, no Raspbian binary this time.

[-ck]

First problem found in  --avalon-freq <arg> Set frequency range for avalon-auto, single value or range

with range set from 330-360 this is not working and miner has been sat on 330 for over an hour not increasing on decreasing in speed yet on previous version was working?

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

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

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

[kano]

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

Damn, no Raspbian binary this time.

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.

[bitpop]

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

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

[didjaydisteele]

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.

[kano]

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.

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.

[didjaydisteele]

Got it! Thanks Kano. 

[Roy Badami]

The network difficulty defines how many of these you need to find before you should, on average, find a block

Where does cgminer's reported 'network difficulty' come from - and is it supposed to be the same as Bitcoin's difficulty?  (I find it's not the same - but I guess that may be just down to what the pools report?)

roy

[kano]

The network difficulty defines how many of these you need to find before you should, on average, find a block

Where does cgminer's reported 'network difficulty' come from - and is it supposed to be the same as Bitcoin's difficulty?  (I find it's not the same - but I guess that may be just down to what the pools report?)

roy

It's there in the block header you are hashing.
Block header being hashed is: Type, Prev, Merkl, Time, Bits, Nonce.
Diff = f(Bits)

[-ck]

New version: 3.3.4, 14th August 2013

Hotfix release.


Human readable changelog:

- Fixed the breakage when mining on bitminter.
- Fixed the performance regression on avalons
- Added extra % counts to devs fields in API


Full changelog:

- API/miner.php add some % fields
- Nonce2 stratum submission is not working with nonce2 lengths >4, revert the
buggy __bin2hex function and use bin2hex.
- The write thread in avalon is only ever actually woken up by timeout so remove
the write semaphore and use a simple sleep poll.
- Fix warning.
- Interrupting reads on the avalon to start writes loses data so remove the
cgsem_post in the read code.
- Add room for the null byte at the end of the nonce2 string on stratum share
submission and zero the allocated ram.