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

[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 

[-ck]

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

And I was forming a mexican wave with you.

[X3rxis]

What should i get to control my antminer S3 ? Which setup is the best which homebrew
Re there some famous github links for the first steps? I wanna run my device with a netbook

[-ck]

What should i get to control my antminer S3 ? Which setup is the best which homebrew
Re there some famous github links for the first steps? I wanna run my device with a netbook

The S3 has a very custom USB connection that is likely to only work with the controller that it comes with. I don't think anyone has tried to get it to talk to a separate controller such as a netbook. The only thing offered custom at the moment is a special 4.6.0 binary I built for the S3 which can be copied onto the device. I posted a link on this thread a page ago and on the S3 discussion thread they have extensively discussed its use.

[Ikron]

I have a problem that I just couldnt figure out for months and I decided to post here to get some help.
I'm running cgminer-4.6.0 on a raspbian flashed raspberry pi with two yellowjackets mining on an orico 10 port usb 2.0 hub and I noticed that cgminer does not detect any hardware errors on my miners (I left if mining for a day and hw errors was always 0). Sometimes I get a reset error (it was somewhere on the lines of "attempted reset got err (0): LIBUSB_SUCCESS") which then causes cgminer to replug the miners again. I dont know what is exactly the source of the miners and I do not get any improvement with updating nor setting dwc_otg.speed=1 on the cmdline.txt boot file. Anybody else have the same issue?

[-ck]

I'm running cgminer-4.6.0 on a raspbian flashed raspberry pi with two yellowjackets mining on an orico 10 port usb 2.0 hub and I noticed that cgminer does not detect any hardware errors on my miners (I left if mining for a day and hw errors was always 0). Sometimes I get a reset error (it was somewhere on the lines of "attempted reset got err (0): LIBUSB_SUCCESS") which then causes cgminer to replug the miners again. I dont know what is exactly the source of the miners and I do not get any improvement with updating nor setting dwc_otg.speed=1 on the cmdline.txt boot file. Anybody else have the same issue?

What's a yellowjacket? Also you haven't actually said what the problem is in particular?

[Ikron]

I meant the yellowjacket nanofury nf1s, I had issues where I have the miners disconnect and then replugged back in (I'll see if I can get a screen shot of the error line, right now the line cgminer posts was somewhere about "attempted reset got err (0): LIBUSB_SUCCESS). I also noticed as part of my problem is that cgminer doesn't show any hardware errors at all. After a day of mining the amount of errors it shows was 0.

[-ck]

I meant the yellowjacket nanofury nf1s, I had issues where I have the miners disconnect and then replugged back in (I'll see if I can get a screen shot of the error line, right now the line cgminer posts was somewhere about "attempted reset got err (0): LIBUSB_SUCCESS). I also noticed as part of my problem is that cgminer doesn't show any hardware errors at all. After a day of mining the amount of errors it shows was 0.

Temporary instability would cause the nanofuries to stop working. Cgminer intentionally resets them and hotplugs them again to try to get them going again. Different hardware is more or less susceptible to this happening and I remember having the same issue with NF1s until they eventually died completely and started causing spikes and shorts on my usb hub and I had to throw them out one by one (I now have none). Because the nanofuries use the bitfury chips which have a hardware error rate in their design of about 15% it makes it difficult to gleam any useful information from the hardware error rate so I never bothered to even count them, hence it will always read zero for that particular device.

[Ikron]

Ah, alright, thanks for the explanation. 

[J4bberwock]

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.

I'm working on a hack of the S1 to use the hashing boards without the proprietary control unit.
Actually, using either an older CGminer or the one for U1/U2, I can have the board hashing, but at 1/4 of max speed expected.
Looks like all chips are working (hot), but I'm only getting 1/4 of results.

Edit:
I assume it's because U1/U2 are using single chain and S1 multichain

Using a newer cgminer build (starting in june or july), my interface with CP2102 is recognized as a LIX and not hashing at all.
I'm not a coder, but could you point me at what to look for the 1/4 speed issue?

Edit:
Would it work if we were using the U1/U2 Icarus code to recognize the unit, and then sending multiple chains data?

Changing the Vid/pid to match my cp2102 and compiling with bitmain support didn't help.

here is what I'm getting when changing the vendor and product id from usbutils to match m cp2102 and compiling only with enable-ants1

 USB scan devices: checking for ANT devices
 [2014-09-18 01:33:31] ANT looking for and found ANT 10c4:ea60
 [2014-09-18 01:33:31] USB lock BitmainAntS1 1-5
 [2014-09-18 01:33:31] RES: BitmainAntS1 (1:5) lock=1
 [2014-09-18 01:33:31] USB res lock BitmainAntS1 1-5
 [2014-09-18 01:33:31] RES: BitmainAntS1 (1:5) lock ok=1
 [2014-09-18 01:33:31] USB unlock BitmainAntS1 1-5
 [2014-09-18 01:33:31] RES: BitmainAntS1 (1:5) lock=0
 [2014-09-18 01:33:31] ANT looking for ANT 10c4:ea60 but found 0424:ec00 instead
 [2014-09-18 01:33:31] USB res unlock BitmainAntS1 1-5
 [2014-09-18 01:33:31] ANT looking for ANT 10c4:ea60 but found 0424:9512 instead
 [2014-09-18 01:33:31] ANT looking for ANT 10c4:ea60 but found 1d6b:0002 instead
 [2014-09-18 01:33:33] Discarded work
 [2014-09-18 01:33:33] Selecting pool 0 for work

Listing known devices returns this

Bus 1 Device 5 ID: 10c4:ea60 Silicon Labs CP2102 USB to UART Bridge Controller inactive
1 total known USB device
Hotplug interval:5
0 USB devices, 0 enabled, 0 disabled, 0 zombie

[Roy Badami]

Another Monarch problem.  I've been testing the thermal throttling, and it seems not to work.

If I set --bflsc-overheat to a low value then cgminer logs a message saying that the cutoff temperature has been reached and it's stopping work.  But it doesn't seem to actually throttle...

EDIT: Meaning, it carried on hashing at full speed (and temperature continues rising above the overheat cutoff)

roy

[-ck]

Another Monarch problem.  I've been testing the thermal throttling, and it seems not to work.

If I set --bflsc-overheat to a low value then cgminer logs a message saying that the cutoff temperature has been reached and it's stopping work.  But it doesn't seem to actually throttle...

EDIT: Meaning, it carried on hashing at full speed (and temperature continues rising above the overheat cutoff)

I'll look into it, along with the product string.