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

[Mikestang]

Right so you use both, since you want both to have access ...
W:127.0.0.1,W:[my local ip address]
https://github.com/ckolivas/cgminer/blob/master/API-README#L18

<snip>

Try setting the Advances settings to what they were before and saving them and make sure they are the same.

Edit: you can also see the setting it is running if you look at the API estats command output (in our version, not in the bitmain version)

I should read the read me, shouldn't I?  Thank you, makes sense and now fixed.

I had checked the advance settings and they were the same as pre-update before.  I've reinstalled 4.9.2 and I think I just needed to let it run a bit longer to even out.  Hashing away happily over 500GH/s now, thanks.  Would be great to see if 4.9.2 also fixes why my S3+ would decrease from 500GH to 480, sometimes over the course of 1 day, some times over several.  Fingers crossed it holds steady at 500GH+. 

[1544516176]

1544516176

[1544516176]

1544516176

[kano]

Right so you use both, since you want both to have access ...
W:127.0.0.1,W:[my local ip address]
https://github.com/ckolivas/cgminer/blob/master/API-README#L18

<snip>

Try setting the Advances settings to what they were before and saving them and make sure they are the same.

Edit: you can also see the setting it is running if you look at the API estats command output (in our version, not in the bitmain version)

I should read the read me, shouldn't I?  Thank you, makes sense and now fixed.

I had checked the advance settings and they were the same as pre-update before.  I've reinstalled 4.9.2 and I think I just needed to let it run a bit longer to even out.  Hashing away happily over 500GH/s now, thanks.  Would be great to see if 4.9.2 also fixes why my S3+ would decrease from 500GH to 480, sometimes over the course of 1 day, some times over several.  Fingers crossed it holds steady at 500GH+. 

Yes the hash rate has high variance due to the fact that the device nonces are at close to the pool difficulty.

So e.g. if you have the pool getting 18 shares per minute, cgminer will only see (on average) somewhere between 36 and 18 nonces per minute.
It can take a day (or more) to settle into the expected hash rate.
The share variance in the first 10 minutes can, of course, be very high or very low, and that decides the curve towards the expected, from above or from below.

The very first time I ran the new code on my S3 for an extended run, I got 500GHs for the first hour instead of 440GHs ... yeah even I had to think a few times about what was going on. My first overnight test run got 450GHs. But in both cases if I had left them for a day or two they would have ended up close to 440GHs

[Mikestang]

Yes the hash rate has high variance due to the fact that the device nonces are at close to the pool difficulty.

So e.g. if you have the pool getting 18 shares per minute, cgminer will only see (on average) somewhere between 36 and 18 nonces per minute.
It can take a day (or more) to settle into the expected hash rate.
The share variance in the first 10 minutes can, of course, be very high or very low, and that decides the curve towards the expected, from above or from below.

The very first time I ran the new code on my S3 for an extended run, I got 500GHs for the first hour instead of 440GHs ... yeah even I had to think a few times about what was going on. My first overnight test run got 450GHs. But in both cases if I had left them for a day or two they would have ended up close to 440GHs

12 hours and running just fine, thanks!



The 5s hash rate swings pretty wildly, I've seen it as high as 1.1TH, heh.

[kano]

...

12 hours and running just fine, thanks!

http://i61.tinypic.com/11t3dky.jpg

The 5s hash rate swings pretty wildly, I've seen it as high as 1.1TH, heh.

I'm not sure how accurately the Bitmain driver handles the work difficulty from the pool.
I do it as follow:
https://github.com/ckolivas/cgminer/blob/master/driver-bitmain.c#L592

Thus the nonce finding variance of the Ant is close to the share finding variance - which reduces internal IO from the Ant chip also.
The Ants can do work difficulty at a power of 2 - 1, 2, 4, 8, 16, 32, 64 ,128, 256, 512, 1024, 2048, 4096 (I stop at 4096 so direct solo gives results)
So if the pool difficulty is e.g. 300 the ant will mine internally at 256 difficulty and since the hash rate is based on nonces found, the hash rate's variance will be the equivalent of mining on a pool at 256 difficulty so will be noticeable.
Bitmain's driver does this also, but I'm not sure how accurately - it may be the same or lower for them.

[Mikestang]

I'm not sure how accurately the Bitmain driver handles the work difficulty from the pool.
I do it as follow:
https://github.com/ckolivas/cgminer/blob/master/driver-bitmain.c#L592

Thus the nonce finding variance of the Ant is close to the share finding variance - which reduces internal IO from the Ant chip also.
The Ants can do work difficulty at a power of 2 - 1, 2, 4, 8, 16, 32, 64 ,128, 256, 512, 1024, 2048, 4096 (I stop at 4096 so direct solo gives results)
So if the pool difficulty is e.g. 300 the ant will mine internally at 256 difficulty and since the hash rate is based on nonces found, the hash rate's variance will be the equivalent of mining on a pool at 256 difficulty so will be noticeable.
Bitmain's driver does this also, but I'm not sure how accurately - it may be the same or lower for them.

I do not understand the code, but I think I follow the rest of what you are saying.

One question remains to me, is my machine actually hashing faster, as reported, for the 1-2 days after a restart, or is the elevated rate merely a result of the difficulty/nonce reason above?  If it is actually hashing faster then I should be restarting it every day or two, the difference is like a free usb stick or 3.

Thanks again.

[kano]

I'm not sure how accurately the Bitmain driver handles the work difficulty from the pool.
I do it as follow:
https://github.com/ckolivas/cgminer/blob/master/driver-bitmain.c#L592

Thus the nonce finding variance of the Ant is close to the share finding variance - which reduces internal IO from the Ant chip also.
The Ants can do work difficulty at a power of 2 - 1, 2, 4, 8, 16, 32, 64 ,128, 256, 512, 1024, 2048, 4096 (I stop at 4096 so direct solo gives results)
So if the pool difficulty is e.g. 300 the ant will mine internally at 256 difficulty and since the hash rate is based on nonces found, the hash rate's variance will be the equivalent of mining on a pool at 256 difficulty so will be noticeable.
Bitmain's driver does this also, but I'm not sure how accurately - it may be the same or lower for them.

I do not understand the code, but I think I follow the rest of what you are saying.

One question remains to me, is my machine actually hashing faster, as reported, for the 1-2 days after a restart, or is the elevated rate merely a result of the difficulty/nonce reason above?  If it is actually hashing faster then I should be restarting it every day or two, the difference is like a free usb stick or 3.

Thanks again.

If it's consistent, then it is hashing faster.

Where it starts, depends on the luck in the early time after the start ... up to an hour or so ... then it will gradually average out to the expected rate.
If you are lucky at the start it can be quite high, I've had my S3 mine at around 500GHs for an hour - luck/variance - but eventually it settles down and heads towards 440.

Think of it like block finding.
A pool can get lucky and find lots of blocks fast and get unlucky and have long dry spells of no blocks.
Over time the expected average of a pool is 100% diff (less orphan rate)

WIth the S3, it's on a much smaller scale, but the same idea.
Over a days or two it will certainly approach the average expected hash rate, but when you first start it up the variance can seem quite high.
This is, again, due to the fact that it is returning a LOT fewer nonces.
If it is internally mining at 256 diff, then it will have only 1/256th of the amount of results - so it's sort of like saying it will take 256 times longer to average out - well it's not 256, but the idea is the same. That's variance.

It's not affecting the number of shares you are submitting to the pool.

[Mikestang]

If it's consistent, then it is hashing faster.

Where it starts, depends on the luck in the early time after the start ... up to an hour or so ... then it will gradually average out to the expected rate.
If you are lucky at the start it can be quite high, I've had my S3 mine at around 500GHs for an hour - luck/variance - but eventually it settles down and heads towards 440.

Yes, it consistently hashes faster for one to several days after a restart.  With my overclock settings I should expect it to hash at 500GH/s.  After a day or several days, however, this machine will slowly ratchet down to about 480GH/s.  I like to restart it between 485-490 to keep that extra hash on my side.

I reset it last night and took a screen cap this morning to show it holding 500+ over night, I noticed the 5s hash rate was doing it's crazy swings again so I screen capped it high and low.  Variance I expect, especially right at start up as you mentioned, but a swing of order of magnitude 10X is pretty substantial, wouldn't you say?  Especially after running for over 9 hours.

[toptek]

I know this has been asked before but i never saw a answer  any place, I wasn't the one that asked it before but am now I upgraded a s1 to S3 how do i make fan 2 show the speed . it shows everything else but that even with the new update . again  i know its been asked but i have yet to see any good answer why or how to and this is the first time i have come out and  asked it .


Just peaced to gather a S3 from parts i bought i had laying around for fun it does the same thing . is it because of the controller to power board for the S1 to  S3 .

I found a Full S3 controller i have coming some one sold me if that's it , ( The controller from S1 to S3 ) .  i may buy one more full controller off the guy.

[Mikestang]

The fan display is something from the hardware, not software.  It's probably like you seem to have already guessed, it's on the control board somewhere and that somewhere exists on the S3 board but not the S1.

AFAIK no one has ever determined how to get S1 hardware to show the second fan speed in the gui.

[pekatete]

You'll probably have to swap the PWM and tachometer terminals on the fan if it is not showing speeds on the second fan.

[kano]

If it's consistent, then it is hashing faster.

Where it starts, depends on the luck in the early time after the start ... up to an hour or so ... then it will gradually average out to the expected rate.
If you are lucky at the start it can be quite high, I've had my S3 mine at around 500GHs for an hour - luck/variance - but eventually it settles down and heads towards 440.

Yes, it consistently hashes faster for one to several days after a restart.  With my overclock settings I should expect it to hash at 500GH/s.  After a day or several days, however, this machine will slowly ratchet down to about 480GH/s.  I like to restart it between 485-490 to keep that extra hash on my side.

I reset it last night and took a screen cap this morning to show it holding 500+ over night, I noticed the 5s hash rate was doing it's crazy swings again so I screen capped it high and low.  Variance I expect, especially right at start up as you mentioned, but a swing of order of magnitude 10X is pretty substantial, wouldn't you say?  Especially after running for over 9 hours.

http://i62.tinypic.com/dgj5t1.jpg

http://i62.tinypic.com/2910pqf.jpg

Well when the pool is expecting a share on average every ~3s and the the internal work is returning nonces at most twice as often as that and at least the same as that - yep 10x is not all that outrageous

You are looking at the 5s number which is borderline random because of how close it is to the average work replies.

[Mikestang]

You are looking at the 5s number which is borderline random because of how close it is to the average work replies.

Right, and generally what I see reported at 5s doesn't get me excited.  I only mentioned it in the recent posts because I'd never seen it report back as high (or low) as it has been since updating to 4.9.2.

For clarification, my other comments re:500GH and dying down to 480GH after 1-5 days is not looking at the 5s number, obviously, but at the average for the entire uptime.  20 hours since last restart and average hash rate is holding at 506GH/s, all systems go.

[kano]

I've put an updated AntS3 update archive in my binaries git hub of latest 4.9.2 cgminer.
For details and installing: https://github.com/kanoi/cgminer-binaries/tree/master/AntS3

It's an update to the previous AntS3 release I did:

Code:

2015-Jul-7 Update cgminer-ants3-4.9.2-94e04f6-2.tgz
---------------------------------------------------
Update the cgminer init.d script to run ntpd a few times trying to set the date

Add more frequencies to the Web Advanced Settings tab
Warning, the higher frequencies marked with a warning can risk damage

Tested and running on my pool of course

[jonnybravo0311]

Downloaded and installed on my S3s.  Thanks again for your work, kano!

[Mikestang]

I've put an updated AntS3 update archive in my binaries git hub of latest 4.9.2 cgminer.
For details and installing: https://github.com/kanoi/cgminer-binaries/tree/master/AntS3

It's an update to the previous AntS3 release I did:

Code:

2015-Jul-7 Update cgminer-ants3-4.9.2-94e04f6-2.tgz
---------------------------------------------------
Update the cgminer init.d script to run ntpd a few times trying to set the date

Add more frequencies to the Web Advanced Settings tab
Warning, the higher frequencies marked with a warning can risk damage

Tested and running on my pool of course

Lovely, will update the next time my S3+ needs a reboot, thanks again!

[vayvanne]

I am getting regularly

Code:

SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
attempted reset got err:(0) LIBUSB_SUCCESS

on latest cgminer-4.9.2-windows running on winusb on antminer U2
what does it mean? is it critical for solo mining scenario?

[kano]

I am getting regularly

Code:

SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
attempted reset got err:(0) LIBUSB_SUCCESS

on latest cgminer-4.9.2-windows running on winusb on antminer U2
what does it mean? is it critical for solo mining scenario?

If it is a "U2" then the problem is one of:
Bad USB cable
Bad USB hub
Connected to USB3 port - try a USB2 port
Failed/overheating U2

[vayvanne]

I am getting regularly

Code:

SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
attempted reset got err:(0) LIBUSB_SUCCESS

on latest cgminer-4.9.2-windows running on winusb on antminer U2
what does it mean? is it critical for solo mining scenario?

If it is a "U2" then the problem is one of:
Bad USB cable
Bad USB hub
Connected to USB3 port - try a USB2 port
Failed/overheating U2

Yes, it is U2 (ANT USB 1.2). U2 is downclocked to 200 MHz. Seems the error is because of Logitech USB cable.
Do I loose shares or other data because of error? Are consequences recoverable?

[btcash]

I was always wondering, do you get free samples or donations from the manufature? Doesn't seem fait that they make millions while using your software for free.

[kano]

I was always wondering, do you get free samples or donations from the manufature? Doesn't seem fait that they make millions while using your software for free.

Firstly I've worked a little different to other devs ... the below refers to me only

Well my first AntS1 I bought but Bitmain let me in the 1st batch.
My first AntS2 someone else bought for me (not part of Bitmain)
But bitmain have supplied AntS1, AntS3, AntS5 (currently dead), 2xU3 (that's why I know they are so crap), U1s and U2s

Nowhere along the U1/U2/U3 path have they taken any notice of:
https://bitcointalk.org/index.php?topic=294499.0
Though they definitely knew about that post

I have bought some hardware over the years ... paid 128BTC for my first BFL fpga
At the time that was well priced and I got it in 1 week, not from BFL, unlike everyone else who spent months after paying waiting for them.

I've never been too concerned about the value of the hardware vs the work I've done, until recently.
Over the past year or so it's been all about manufacturers selling hardware to business and the bitcoin community has been pretty much left behind in the dust ... or buying hardware that they'll definitely lose BTC on - so yeah I've not been liking working at slave labour rates so been expecting them to cough up some BTC - also since the hardware is mostly worthless in anything but large quatities running on cheap power in a data center somewhere, it's sometimes a loss for me to get the hardware for dev purposes at home ...