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

[pekatete]

...
I know I said that was the last one, but the API still returns "broken" JSON when queried with two commands on the same line. Easy enough to fix by adding a comma between any curly braces backing onto each other .....

What command did you send it so I can test it?

If you send json as multiple commands with + between them they become an array of replies

 {"command":"cmd1+cmd2"}
replies with
 {"cmd1":[{ ... reply1 ... }],"cmd2":[{ ... reply2 ... }]}

where { ... reply1 ... } is what you'd get from {"command":"cmd1"}

Edit: reading your comment again - you can't send 2 commands - only one per API access (and then the API socket closes)
You can join them, as I've mentioned above, with a +, to get an array of answers in one command (but they can only be "report" commands)
... as in https://github.com/ckolivas/cgminer/blob/master/API-README

Command sent was stats+summary JSON encoded (i.e I use the .NET JavaScriptSerializer to serialize a dictionary of string, string to JSON then use the serialized object / string to poll the API. As you mention above, it SHOULD respond with the two responses separated by a comma, but it does not put the comma there.

Additionally (and I have not checked this properly yet), normally the API will terminate a response for a single command with a null at the end, it may be that the API also includes a null at the end of the first command response in a two command poll which will cause loops looking for a terminating null to bail out early on the first null.

[kano]

It's some bug in your code, json implementation or .NET
The output format is as I stated, there are no closing } followed directly by an opening {

The API puts a null at the end of the full reply (not in the middle) on purpose.
It's a socket level optimisation.
It is guaranteed to be the only null and it clearly terminates the socket message.
Various code in various places had random handling to determine an end of a socket message.
There is no such confusion with the API socket.
Once you get the null, you know you have all the data and do not need to look for/wait for anything else.
Until you get the null, you know you need to keep reading.
Thus only in the very rare case of a transmission error/failure do you ever wait on the socket and get a timeout.

You can test what the reply is directly on linux:
echo '{"command":"summary+stats"}' | ncat -4 MinerIPAddress 4028

Edit: note: it's not 2 responses seperated by a comma, it's a json list
If you are getting 2 {} responses then you must be making 2 connections and sending 2 {command} requests

[pekatete]

It's some bug in your code, json implementation or .NET
The output format is as I stated, there are no closing } followed directly by an opening {

Turns out I was looking at the API output from another S3 that has not been updated with the latest cgminer .... I have checked on the updated one and it returns unbroken json (so not a bug in my code and certainly not in .NET!)

The API puts a null at the end of the full reply (not in the middle) on purpose.
It's a socket level optimisation.
It is guaranteed to be the only null and it clearly terminates the socket message.

Like I said, I had not tested that (but I know if it does it'd would cause the issue I mentioned), and have yet to confirm either way.

[Mikestang]

Just updated my S3+, couple issues:

1)  Under API allow, if I use W:[my local ip address], then CryptoGlance reports the S3+, but the web page doesn't show any stats under Miner Status.  If I use W:127.0.0.1, then it shows stats under Miner Status, but CryptoGlance shows the S3+ as dead.

2)  Old version my unit hashed at 500GH/s, now I don't see over 420.

Going to have to revert versions...

[kano]

Just updated my S3+, couple issues:

1)  Under API allow, if I use W:[my local ip address], then CryptoGlance reports the S3+, but the web page doesn't show any stats under Miner Status.  If I use W:127.0.0.1, then it shows stats under Miner Status, but CryptoGlance shows the S3+ as dead.

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

If you had it before as W:0/0 anyone on the planet could change your miner to mine for them if they had network access and found it ... e.g. your neighbours if you have Wifi and they can hack into it
I also have no idea what Bitmain did to the API - but it SHOULD ONLY give access to what you tell it to have access as how I designed and wrote the API and api-allow

2)  Old version my unit hashed at 500GH/s, now I don't see over 420.

Going to have to revert versions...

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)

[kano]

It's some bug in your code, json implementation or .NET
The output format is as I stated, there are no closing } followed directly by an opening {

Turns out I was looking at the API output from another S3 that has not been updated with the latest cgminer .... I have checked on the updated one and it returns unbroken json (so not a bug in my code and certainly not in .NET!)

...

Bitmain has old versions of their fork of cgminer in their miners ... all the more reason to update to our master cgminer

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

[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!