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

[Count_Frackula]

ckolivas, any idea why the new firmware & cgminer version on the s3 would stop access via the API?

I don't have an s3 yet, mine will be here soon though, they have been shipped from china... but in the meantime users of my app are saying when they upgrade firmware and install newest version of cgminer app doesn't have access to api. they've said they still have api access enabled.

when I wrote the app I used the API specs that were in github. it worked before the update.

i'll be able to test when my s3 come but thought maybe someone knew off that top of their head

Working fine for me.

[1537870514]

1537870514

[1537870514]

1537870514

[1537870514]

1537870514

[1537870514]

1537870514

[spiceminer15]

ckolivas, any idea why the new firmware & cgminer version on the s3 would stop access via the API?

I don't have an s3 yet, mine will be here soon though, they have been shipped from china... but in the meantime users of my app are saying when they upgrade firmware and install newest version of cgminer app doesn't have access to api. they've said they still have api access enabled.

when I wrote the app I used the API specs that were in github. it worked before the update.

i'll be able to test when my s3 come but thought maybe someone knew off that top of their head

Working fine for me.

ok. I might be end user error. I didn't think the API would change all of a sudden

[Roy Badami]

Not immediately detecting my Monarchs.

Am I right in thinking that all I should need is --enable-bflsc at build time (and nothing special at run time)?

[Roy Badami]

Not immediately detecting my Monarchs.

Am I right in thinking that all I should need is --enable-bflsc at build time (and nothing special at run time)?

Ah, it appears that production Monarchs (or at least these two) have iProduct set to "BitFORCE SHA256".  A quick edit of usbutils.c and we're hashing (albeit with a warning at startup about an unknown firmware version).

Note that this iProduct string seems to be the same as the old BFL FPGAs.  I've no idea whether this matters - although I'm not compiling the old bitforce driver so it clearly doesn't matter to me.

[kano]

ckolivas, any idea why the new firmware & cgminer version on the s3 would stop access via the API?

I don't have an s3 yet, mine will be here soon though, they have been shipped from china... but in the meantime users of my app are saying when they upgrade firmware and install newest version of cgminer app doesn't have access to api. they've said they still have api access enabled.

when I wrote the app I used the API specs that were in github. it worked before the update.

i'll be able to test when my s3 come but thought maybe someone knew off that top of their head

Working fine for me.

ok. I might be end user error. I didn't think the API would change all of a sudden

S3 disables write access to the API and ignores the _aa setting.
I'm not sure which versions do this setting or if it is all of them.
I've had 3 different versions (my first S3 controller board went strange and Bitmain replaced it quickly for me) so I'm not sure.

In /etc/init.d/cgminer mine had:

PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-network --bitmain-checkn2diff --bitmain-hwerror --queue 4096"

Instead I change it to:

PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-allow $_aa --bitmain-checkn2diff --bitmain-hwerror --queue 1024"

(though 1024 can probably be lower - I've not checked what it should be)

[kano]

Not immediately detecting my Monarchs.

Am I right in thinking that all I should need is --enable-bflsc at build time (and nothing special at run time)?

Ah, it appears that production Monarchs (or at least these two) have iProduct set to "BitFORCE SHA256".  A quick edit of usbutils.c and we're hashing (albeit with a warning at startup about an unknown firmware version).

Note that this iProduct string seems to be the same as the old BFL FPGAs.  I've no idea whether this matters - although I'm not compiling the old bitforce driver so it clearly doesn't matter to me.

I wonder if that is true of all the new ones
Maybe BFL doesn't like cgminer working with it - though they indirectly paid for the driver ...
My original moth has been mining fine at ~250W, ~330GH/s at the pool, for over 2 months now

[Roy Badami]

I wonder if that is true of all the new ones
Maybe BFL doesn't like cgminer working with it - though they indirectly paid for the driver ...
My original moth has been mining fine at ~250W, ~330GH/s at the pool, for over 2 months now

I would assume it must be true of at least all the ones shipping right now.  Seems unlikely that mine are special in some way.

BTW, is there/will there be any access to underclocking/undervolting?  I'm pretty sure BFL promised this would be possible...

roy

[-ck]

I wonder if that is true of all the new ones
Maybe BFL doesn't like cgminer working with it - though they indirectly paid for the driver ...
My original moth has been mining fine at ~250W, ~330GH/s at the pool, for over 2 months now

I would assume it must be true of at least all the ones shipping right now.  Seems unlikely that mine are special in some way.

BTW, is there/will there be any access to underclocking/undervolting?  I'm pretty sure BFL promised this would be possible...

Just like last time, the cgminer development team is mostly in the dark and treated as 3rd class citizens by BFL so we have no idea when they change firmwares (like you experienced by them changing the ID string) or add features or whatever. Infuriating, but then our complaints are minor compared to customers.

[TrevorS]

Could someone please explain the practical difference between Cgminer "balanced" (shares) Vs "load balanced" (quota) pool selections.  What are the advantages and disadvantages of one Vs the other?  I'm finding it too obtuse !  Thanks in advance for your assistance !

[rav3n_pl]

One is counting shares you return, second is counting getworks you take.

[wolf_miner]

Hi, using --load-balance strategy is possible to split the complessive hashrate at 2 user (33% USER1/ 66% USER2) on the same pool (POOL_ABC)?

"pools" : [
        {
                "quota"  : "1;POOL_ABC:3333",
                "user" : "USER1",
                "pass" : "123"
        },
        {
                "quota" : "2;POOL_ABC:3333",
                "user" : "USER2",
                "pass" : "123"
        }
]

Thanks in advance W_M

[rav3n_pl]

Hack will be add one user twice

[-ck]

Hi, using --load-balance strategy is possible to split the complessive hashrate at 2 user (33% USER1/ 66% USER2) on the same pool (POOL_ABC)?

"pools" : [
        {
                "quota"  : "1;POOL_ABC:3333",
                "user" : "USER1",
                "pass" : "123"
        },
        {
                "quota" : "2;POOL_ABC:3333",
                "user" : "USER2",
                "pass" : "123"
        }
]

Thanks in advance W_M

Yes that will work fine.

[konradp]

I'm not sure where you're seeing these messages. There hasn't been any GPU code in mainline cgminer for over a year and I'm not supporting anything but the current version.

Thanks @ckolivas.

This is the output of cgminer.

I use it to mine on testnet. There are 4 radeon 79xx gpu cards, and according to cgminer stats it does ~2.5gh/s - I was hoping to mine something, especially that current testnet difficulty == 1.0, but it doesn't work, hence I posted this warning(?) messages.

Which version? 

It's 3.5.0, I just need to mine with gpu on testnet, that is why I use an old version.

[spiceminer15]

I think I found an error in cgminer version "3.12.0" this is the version bitmaintech is shipping with batch 8 antminer s3. might be on newer batches as well...

the json returned from the "stats" command is invalid.

this is the json returned.

Code:

{\"STATUS\":[{\"STATUS\":\"S\",\"When\":1410555313,\"Code\":70,\"Msg\":\"CGMiner stats\",\"Description\":\"cgminer 3.12.0\"}],\"STATS\":[{\"CGMiner\":\"3.12.0\",\"Miner\":\"7.0.0.3\",\"CompileTime\":\"Tue Aug 26 10:43:10 CST 2014\",\"Type\":\"S3\"}{\"STATS\":0,\"ID\":\"BMM0\",\"Elapsed\":149,\"Calls\":0,\"Wait\":0.000000,\"Max\":0.000000,\"Min\":99999999.000000,\"GHS 5s\":459.00,\"GHS av\":469.49,\"baud\":115200,\"miner_count\":2,\"asic_count\":8,\"timeout\":18,\"frequency\":\"225\",\"voltage\":5,\"hwv1\":7,\"hwv2\":0,\"hwv3\":0,\"hwv4\":3,\"fan_num\":2,\"fan1\":2520,\"fan2\":2280,\"fan3\":0,\"fan4\":0,\"fan5\":0,\"fan6\":0,\"fan7\":0,\"fan8\":0,\"fan9\":0,\"fan10\":0,\"fan11\":0,\"fan12\":0,\"fan13\":0,\"fan14\":0,\"fan15\":0,\"fan16\":0,\"temp_num\":2,\"temp1\":43,\"temp2\":41,\"temp3\":0,\"temp4\":0,\"temp5\":0,\"temp6\":0,\"temp7\":0,\"temp8\":0,\"temp9\":0,\"temp10\":0,\"temp11\":0,\"temp12\":0,\"temp13\":0,\"temp14\":0,\"temp15\":0,\"temp16\":0,\"temp_avg\":42,\"temp_max\":44,\"Device Hardware%\":0.0000,\"no_matching_work\":0,\"chain_acn1\":16,\"chain_acn2\":16,\"chain_acn3\":0,\"chain_acn4\":0,\"chain_acn5\":0,\"chain_acn6\":0,\"chain_acn7\":0,\"chain_acn8\":0,\"chain_acn9\":65535,\"chain_acn10\":0,\"chain_acn11\":0,\"chain_acn12\":0,\"chain_acn13\":0,\"chain_acn14\":0,\"chain_acn15\":0,\"chain_acn16\":0,\"chain_acs1\":\"oooooooo oooooooo \",\"chain_acs2\":\"oooooooo oooooooo \",\"chain_acs3\":\"\",\"chain_acs4\":\"\",\"chain_acs5\":\"\",\"chain_acs6\":\"\",\"chain_acs7\":\"\",\"chain_acs8\":\"\",\"chain_acs9\":\"\",\"chain_acs10\":\"\",\"chain_acs11\":\"\",\"chain_acs12\":\"\",\"chain_acs13\":\"\",\"chain_acs14\":\"\",\"chain_acs15\":\"\",\"chain_acs16\":\"\",\"USB Pipe\":\"0\"}],\"id\":1}

the error is here:

\"STATS\":[{\"CGMiner\":\"3.12.0\",\"Miner\":\"7.0.0.3\",\"CompileTime\":\"Tue Aug 26 10:43:10 CST 2014\",\"Type\":\"S3\"}{\"STATS\":0,

its missing a comma between }{ in this part: \"S3\"}{\"STATS\":0

adding the comma makes it valid.

i'll add a work around in my app.

[-ck]

I think I found an error in cgminer version "3.12.0" this is the version bitmaintech is shipping with batch 8 antminer s3. might be on newer batches as well...

the json returned from the "stats" command is invalid.

Bitmain hacked the api output themselves to their custom output. We'll have a look but I suspect it's just due to their forked modified api output.

[spiceminer15]

I think I found an error in cgminer version "3.12.0" this is the version bitmaintech is shipping with batch 8 antminer s3. might be on newer batches as well...

the json returned from the "stats" command is invalid.

Bitmain hacked the api output themselves to their custom output. We'll have a look but I suspect it's just due to their forked modified api output.

nice, its also not backwards compatible with older versions  

[nwoolls]

I think I found an error in cgminer version "3.12.0" this is the version bitmaintech is shipping with batch 8 antminer s3. might be on newer batches as well...

the json returned from the "stats" command is invalid.

Bitmain hacked the api output themselves to their custom output. We'll have a look but I suspect it's just due to their forked modified api output.

I'm having a similar issue with BTC Garden ASICs and whatever they've done to CGMiner. I've tried several times to get info from them without any response.

Basically, their ASICs respond to the DEVS RPC API call by saying "no devices".

[-ck]

I think I found an error in cgminer version "3.12.0" this is the version bitmaintech is shipping with batch 8 antminer s3. might be on newer batches as well...

the json returned from the "stats" command is invalid.

Bitmain hacked the api output themselves to their custom output. We'll have a look but I suspect it's just due to their forked modified api output.

I'm having a similar issue with BTC Garden ASICs and whatever they've done to CGMiner. I've tried several times to get info from them without any response.

Basically, their ASICs respond to the DEVS RPC API call by saying "no devices".

We're the upstream code, the onus is not on us to keep forks in line with our code. Owners of the hardware should be polling the manufacturers to maintain both GPL and API compatibility with cgminer and pushing their code upstream. Bitmain have at least offered their code, whereas most forks have not. Some forks' code is unwanted or unusable too of course, but at the very least they should adhere to the license conditions of the code they're using.

[nwoolls]

I think I found an error in cgminer version "3.12.0" this is the version bitmaintech is shipping with batch 8 antminer s3. might be on newer batches as well...

the json returned from the "stats" command is invalid.

Bitmain hacked the api output themselves to their custom output. We'll have a look but I suspect it's just due to their forked modified api output.

I'm having a similar issue with BTC Garden ASICs and whatever they've done to CGMiner. I've tried several times to get info from them without any response.

Basically, their ASICs respond to the DEVS RPC API call by saying "no devices".

We're the upstream code, the onus is not on us to keep forks in line with our code. Owners of the hardware should be polling the manufacturers to maintain both GPL and API compatibility with cgminer and pushing their code upstream. Bitmain have at least offered their code, whereas most forks have not. Some forks' code is unwanted or unusable too of course, but at the very least they should adhere to the license conditions of the code they're using.

Absolutely - I wasn't looking for support rather complaining about the same issue